Дано:
DevBoard, которая формирует UDP пакеты размерностью Data=1024. DevBoard соединен с ПК кроссовым кабелем напрямую. На ПК установлена ОС Linux и по сокетам идет прием UDP пакетов. В каждом пакете идет номер с инкрементом, тем самым можно отслеживать потерю пакетов.
Цель - добиться максимальной пропускной способности при 100% доставки пакетов.

Как видно потери возникают при 100Мбит/линке, когда загрузка сети близется к 100%.
А 1G линк не дает скорости более 12%, далее начинают терятся покеты.

Вопросы
1. Где происходит потеря пакетов ?
2. Как повысить надежность доставки пакетов ?
3. Может ли размер пакета влиять на надежность доставки ? Возможно стоит уменьшить до 128 или 256

UDP не гарантирует доставку. UDP гарантирует, что пакет будет передан. т.е. уйдёт. всё. Изначально ставить не выполнимую цель = мягко говоря не корректно.
это типа раз...
где происходит потеря? либо помеха, либо не успевает приёмник.
надёжность повысить? кхм... выкинуть льюникс, написать свою заточку. два девайса и кабель в свинцовые наряды и прочую мурню...и всё равно это не 100% по определению...
размер пакета может влиять на оптимальность обработки на приёмной стороне. т.е. если вы заглянете в код приёмника на предмет "А какой тебе лучше размер скормить зараза?" то Вы ответите на свой вопрос сами.
по поводу размеров - тут думаю будет просче тупо прогнать разные тесты, которые смогут дать средний по больнице результат...который можно принять за основу - дескать этот размер получше...


мне кажется, что Вы заходите немного не с той стороны.
вот эти вещи разные:
а) пропускная способность
б) надёжность доставки

если Вам актуально надёжность доставки - то тогда протокол не подходит.
если пропускная способность - то тут надо считать и смотреть на возможности канала, приёмника, оси...

где то так
(круглый)

помеха исключена. ошибки были бы тогда при малой загрузке сети.
Почти уверен ,что не успевает ОС считать данные.
Но здесь непонятка. На сетевую карточку приходят пакеты , куда она их девает ? Хранит в своих фифошках или отсылает в ОЗУ ?


думаю на скоростях до 1Гбит/с эти два пункта можно совместить.

может быть
- драйвер сетевой карты (а если запуститься под Win ?)
- настройки сетевой карты (кол-во дескрипторов, буфер приема, частота прерываний)
- разница в клоках DevBrd и чипа сетевой карты
- софт приемника не успевает обрабатывать заголовки пакетов (скипает счетчики)

готовлю тест.


попробую


хм...а как это может влиять на потери ?



тоже возможно, но как повысить скорость обработки ? отказаться от стандартной ОС и переходить на RTOS?



насколько я представляю состояние дел, UDP действительно не гарантирует доставку пакета, но потери происходят при слишком сильной развлетвленной сети. Тут же КРОСС кабель, т.е фактически теряются IP пакеты.

пропуск-вставка лишнего бита в чипе приемника, если тактирующие генераторы имеют номиналы, отличающиеся на проценты. Соотв. произойдет отбрасывание пакета UDP.
для начала нужно выяснить, где ошибка. Для этого надо обрабатывать данные после их накопления в большом буфере ОЗУ, а не в процессе приема. И писать чем-то проверенным, например, wireshark

на скоростях близких 100 мбит/c он еще как теряет пакеты, а на 1 Гб/с так вобще надо в тачку 16 гб ОЗУ и SSD raid, так что забудьте.

подтверждаю. wireshark прилично вешает машину, когда поток даже на 100Мбит/линк более 50%. При этом кол-во потерянных пакетов от 3%.


так то оно так, но как это сделать под ОС ?
И еще раз повторю вопрос. На сетевую карточку приходят пакеты , куда она их девает ? Хранит в своих фифошках или отсылает в ОЗУ ? Если в ОЗУ, то по какому адрессу и кто задает размер буфера?

есть мнение, что просто Вы не умеете его готовить. Коллеги, сидящие рядом, подтверждают полноту и целостность приема при записи в ОЗУ (почти 1 Гб/с) и на HDD не SSD raid (около 800 Мб/с).
может дело в конфигурации железа, версиях софта ?

Пришел кадр Ethernet, картой обработался и положился во внутренний буфер карты. После заполнения внутреннего буфера до определенного уровня карта выставляет запрос на прерывание, ОС реагирует, настраивает DMA, и данные из внутреннего буфера передаются в системное ОЗУ ПК. Ну а дальше софт стека протоколов разбирает кадры.

Вот мои соображения:

- Постоянным (!) потоком данных под 100 Mbps можно положить любую ширпотребныю сетевуху.

- Какая сетевая карта используется? Есть подозрение что использование карты на последних сетевых чипах Intel c PCIe и с различными аппаратными ускорениями (хотя бы расчет Ethernet CRC и контрольной суммы UDP) может улучшить ситуацию.

- А если выкинуть ПК и соединить два девайса напрямую? По крайней мере не будет зависимости от ОС.

- Если вдруг есть доступ к чему-нибудь такому: http://www.smartechconsulting.com/SMB-200-...ortable-chassis то все можно протестить досконально

спасибо. примерно так и представлял. Насколько трудоемко и возможно ли будет сделать следующее:
1. Выделить память в ОЗУ
2. Настроить сетевую как master и напрямую слать данные из внутреннего буфера в в выделенную память в ОЗУ.
Насколько я понимаю, нужен новый драйвер для сетевой.



Сетевая интегрированная в чипсет Intel P67. UDP CRC отключена (шлю нули).


В том то и соль, что нужно соеденить устройство и тупой ПК.


к сожалению нету доступа к подобному устройству . чем богаты.... , как говорится

а есть ли смысл попробывать внешную сетевую типа ?
http://www.stikc.com/Intel-PRO-1000-PT-DUA...3959-EXPI9402PT

Ага, надо будет самому драйвер писать.



Думаю, что есть.

попробуйте JumboFrame. У нас тоже UDP со счетчиком длинна пакетов 8К. На хороший комп с WinXP поток в 300 Мбит запросто проходит, а то и больше. Свой драйвер тоже писали, но это уже когда по 10 GbE поток заводили.

Попробуйте два компа по сетке соединить и большие файлы по сети гонять, какая будет скорость? И это при хреновых встроенных сетевухах.
=> Нужен протокол TCP или его аналог.
У нас тоже были проблемы с потерей пакетов под виндой - вылечилось самопальным транспортным протоколом (на полный TCP слишком много ресурсов надо, а ПЛИС не резиновая).


P.S. jumbo фреймы конечно сильно уменьшали потери пакетов, а если мышкой не шевелить и все остальные программы в винде закрыть и не дышать - то работало практически на максимуме скорости. Однако, заказчик сказал что его сетевая инфраструктура не поддерживает jumbo фреймы.

1. Длина пакета 8K у Вас не разбивалась на отдельные пакеты меньшей длины ?
2. Драйвер свой писали, а где брали документацию на контретную сетевую плату ?


повтор пакета в моем случае сложно реализовать, девайс отправил его и забыл. Даже сделав обратную связь с запросом недошедшего пакета, я не смогу его повторно отправить с устройства.


спасибо, посмотрю

Подытожим. Из всего выше сказаного следует, что нужно увеличивать длину пакета. Верно я понимаю ?

верно. еще пробовать на других сетевухах с поддержкой Jumbo

не совсем.
когда то вот так же заблуждался...сделайте элементарный тест..
1) поставте размер блока 500 байт.
2) измерьте скорость конечной обработки потока на фиксированной скорости.
3) увеличите блок данных в два раза.
4) повторите со 2 по 4 пункт..


забегая вперёд скажу, что оптимум по размеру будет тогда, когда
скорость передачи куска = скорости его обработки

если в левой части или в правой будет бОльшее значение - то будет перекос => потери по времени...
если нарисовать график, скорости от объёма то он будет в ввиде перевёрнутой параболы.

или по другому. никогда не думали почему индексные страницы в БД (особенно старых БД) имеют не максимально возможный размер?

тестил в своё время не в данной тематике, но суть та же..

удачи вам
(круглый)
ЗЫ
По теме...
UDP пакет будет резаться на 1500 когда будет проходить свитч или будет передавться форточками. правда давно брал в руки шашку...

хм.. действительно.
Спасибо.


JumboFrame сильно не помог. Отсылаю 8K данных.

Причем заметил, что пропадают пакеты пачками от 4..28

пакеты случаем не фрагментированы ?

нет, wireskark показывает размер 8K

По собственному опыту - именно не справляется сетевуха.
Если нужны скорости много больше ста мегабит, то первое обязательное условие - отказаться от встроенной в чипсет и использовать что-либо нормальное, от Intel например.

Вопросы:
1 Вы что потом с принятым пакетом делаете, просто счётчики сверяете или ещё както обрабатываете?
2 Для работы с сокетами WinPcap пробовали илспользовать?
3 Может у вас просто приемный софт не совсем коректно с сокетами работает?
4 какая конфигурация у приёмной машины?
5 какая загрузка процессора при обработке потока на котором теряются пакеты?

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

Скорее всего не сетевуха не справляется, а CPU/мост не успевает считывать из нее.
У меня стоит чипсет Intel P67 , его блок схема следующая:

MAC контроллер непосредственно подключается к чипсету, как и шина PCIe. MAC подключен по PCIe х1 , т.е макс пропускная близкая к 1G/c. Поэтому брать внешную сетевуху от Intel пока смысла не вижу.


только счетчик сверяю, идеб в первых 4 байтах пакета.


Нет, не пробывал. Сейчас уже отказался от сокетов и использую UdpClient - класс. Его реализация отличается от классических сокетов.


так и есть. Софт не корректный. Как его оптимизировать, сейчас и разбираюсь.


пробывал на двух:
1.Чипсет IntelP67. Встроенная сетевая карточка непосредственно подключается к нему. Озу 4Гбайт. CPU i5. Ubuntu
2. Чипсет Южный мост:Intel® ICH10. Встроенная сетевая. Озу 4Гбайт. CPU Core2Duo E8400. WinXp


ХМ..интересный вопрос. Загрузка постоянная ~10..15% на обоих машинах. Видимых скачков нету.


Вы используете 1G Link ?


аналогичная проблема.

Сами смотрите, проверить это несложно - а часть версий отпадает сразу. Всяко проще чем переписывать софт
Опять-таки из недавнего опыта: входящий UDP-поток в 360 Мбит/сек, при работе со встроенной сетевой картой (какой был чипсет уже и не упомню) периодически менялись местами два пакета - это будет покруче простого пропадания При замене на дискретную серверную сетевушку проблема исчезла.

вещь. я думал местами пакеты могут поменятся только на сильно развлетвленной сети.
спасибо.

протокол UDP не гарантирует очерёдность доставки. так что проблема в понимании используемого инструмента...

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


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


(круглый)

Но факт остается фактом Проблема в интергированной сетевой карте.

Это не проблема, а штатная ситуация, которую вы обязаны обрабатывать.

объясните почему ? у меня кросс кабель с утройства в комп вставлен. Как могут пакеты поменяться местами ?

Мало ли что там в стеке накручено. Или у сетевухи (как у автора выше) какая-ниубдь недокументированная особенность.

я так разумею - особенности реализации стэка. программист использовал это в своих целях в рамках интерфейса - имеет право. если более точнее отвечать на ваш вопрос - там на 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 с кучей опций - занимался этим программист-линуксоид.

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

Позвольте вставить свои пять копеек. Тоже занимался этим делом. Использовал 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 Мбайт в секунду.
У нас (и не только у нас, есть другие люди и на этом форуме) работает.

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

сказки. сутки так пробовали передавать, а неделю ? а на расстояние 10 метров, 20, 30 ?
в определенной конфигурации и на временном интервале и у нас выходило около 120
а нужно, чтоб не было ошибок вообще.
это означает, что без переспроса не обойтись.

Etherner - асинхронный протокол, этим все сказано!
Даже на синхронные протоколы указывают коэффициент ошибок, например E1 не более 1*10-6

Данные идут с АЦП с эфира. Кого переспрашивать Сутки писать и неделю не требуется(кому нужно столько данных). Да и обьем винта тоже прикинте......
Пишем часами со скоростью 102 МБайт/c, ошибок нет вообще. Мы и по USB 2.0 25Мбайт/c тоже непрерывно пишем - вот там секс.
Никаких помех не видел за год работы. Длина кабеля 10 метров. Если длина кабеля будет большая и обнаружим проблемы - напишу . Перейти на оптику элементарно - десятки баксов и расстояние не так важно.

Если не секрет, то расскажите подробнее:
--------------------------------------------------
1. какая ОС используется?
2. обычный ПК или настоящий сервер?
3. Какая сетевая плата и с каким интерфейсом в материнскую плату?
4. Какой размер пакетов UDP?
5. Исполняются ли одновременно какие другие активные приложения, кроме записи на винчестер?
6. Конфигурация винчестеров?

1. какая ОС используется?
windows xp 32, windows xp 64, windows 7 64
2. обычный ПК или настоящий сервер?
и пк (I7)и сервер пробовали(на сервере даже еще другие задачи ходили типа инета)
3. Какая сетевая плата и с каким интерфейсом в материнскую плату?
разные
4. Какой размер пакетов UDP?
7к
5. Исполняются ли одновременно какие другие активные приложения, кроме записи на винчестер?
запись занимает 10-15 % процессорного времени i7 3.2, типично рекомендую все-таки запускать только программу записи.
6. Конфигурация винчестеров?
важное место , разные пробовали ,нужно выше 130 Мбайт/c гарантированно, raid0 или щас corsair flash 3ssd.