я так разумею - особенности реализации стэка. программист использовал это в своих целях в рамках интерфейса - имеет право. если более точнее отвечать на ваш вопрос - там на IP уровне (по протоколу) должны обрабатыватьс не обязательные поля (кстати там есть очень интересные поля - для военного применения ) и в том числе фрагментацию. Если Вы задумаетесь над алгоритмом обработки фрагментации - то в зависимости от размеров памяти вы будете накапливать пакеты некоторое время, перед тем как отдать выше (в случае фрагментации). Не всегда на этом уровне получается красиво. тут главное скорость. отсюда думаю и растут уши... размеры IP пакета могут быть разные. В локальной сети, на столе - это 1500 байт... хотя может и сам UDP уровень реализован не ввиде очереди.

осадок - имеет право, тот кто это реализовывал.

кстати это одна из ошибок - ожидать очерёдность (в UDP). в TCP/IP - там другая бяда - ожидать квантованность )) страдают не многие, а очень многие...

(круглый)

Имеется в виду ожидание данных в виде "пакета"? Да, напарывались на такое.

еще момент
1) Какова длина кабеля?
2) Какой категории кабель?
при этих тестах. Может все банально.

~2m



CAT 5e. К кабелю притензий нету, иначе бы на меньших скоростях были бы ошибки в самом пакете и, как следствие, не совпадал бы CRC для пакетов.

Начал с обратной задачи.
С ПК в девайс данные гнать.
Скорость 100МБ/с при длине пакета 1024, ошибок 0%.
Но заметил, что иногда сетевая действительно вертит порядок пакетов (хотя в снифере все ровно), причем порядок идет следующий: 2,1,4,3,6,5..... .
Но интересный момент, первые 6 пакетов не доходят

Имел небольшой опыт - как под Линухом так и под виндой. На кабеле как правило все отлично, от сетевой карты зависит очень много, как и от драйверов и программы.
Встроенные средства Линуха позволяют протестировать места потерь пакетов очень хорошо. В моем случае была неправильная 1 контрольная сумма на 65536 пакетов и не очнь быстрый винчестер.

Есть такой протокол GigE Vision с загрузкой под 1 Gb/s - рекомендовано использовать именно Интеловские карточки + переписан драйвер для виндоус. В нем кстати реализован механихм перезапросов

Будте добры, огласите название этих средств. netstat ?

Могу ли я контроллировать заполнение буфера сетевой карты ? например при заполнении буфера сетевой карты более 3/4 выдавать прерывание на процессор и формировать конфигурационный пакет, который уменьшит скорость выдачи данных в сеть.

по-моему все-таки tcpdump с кучей опций - занимался этим программист-линуксоид.

К сожалению буфер оттуда не видно и рулить этим процессом со слов программистов не получится. Просто увидите что то ли дроппит езернет фрэймы, то ли дискардит. Точнно уже не помню

Сообщение отредактировал Sergey_Bekrenyov - Nov 23 2011, 16:09

Позвольте вставить свои пять копеек. Тоже занимался этим делом. Использовал jumbo пакеты 8K, которые генерились отдельным девайсом в 1GE кабель CAT- 5 длинной до 15 м. Подключение к ПК через 1GE свитч. ПК - 3,5Ггц 4Гбайт память, сетевая карта от D-Link, OC -Windows XP. Приход пакетов контролировал снифером wireshark, на винчестер их не писал, сразу в память. Докладываю:

-1. Потеря пакетов сильно зависит от наличия других активных приложений. Параллельно открытый браузер, флэш-плеер или антивирус увеличивали потерю пакетов на порядки.

-2. На потерю пакетов также сильно сказывается настройка снифера. В частности, надо специально отключать прорисовку в реальном времени и запись на винчестер, установить ограничение по обьему принятых данных.

-3. Если использовать pcap с записью пакетов напрямую в память, то пакеты практически не теряются даже на очень высоких скоростях потока.

Что имеется ввиду под pcap ? библиотека на плюсах или контретная утилита на этой библиотеке ?

Насчет потерь. В моем случае даже доли процента потерь не допустимы.
Поэтому я для себя так и не ответил на вопрос, можно ли с помощью Ethernet передавать пакеты с 100% доставкой при кросс кабеле?

нельзя. это ж очевидно..

Если не изменяет память, потеря пакетов не запрещена в Ethernet. Либо стандарт вообще дает это на откуп протоколам более высокого уровня. В UDP гарантии доставки нет.

Точно не могу сказать, использовал как готовую откомпилированную dll. Что у нее внутри - сказать затрудняюсь. Выдает пакеты по stream, можно писать на винчестер, можно память. В память естественно быстрее, но опаснее.
Дублируйте пакеты.
на протоколе TCP- наверное можно. На UDP- точно нельзя.

Для всех кто не верит. Можно передавать в определенной конфигурации по udp в связке (плис в компьютер) данные без потерь и записывать на винчестер. до 120 Мбайт в секунду.
У нас (и не только у нас, есть другие люди и на этом форуме) работает.

Перепосылки есть? Если нет, то серьёзная помеха похерит всю вашу передачу.