Где теряются UDP пакеты? Как повысить надежность доставки ? Опции

[Костян]

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

100Мбит/с линк
80% загрузка - 0% потеря пакетов
90% загр - 0 % потеря пакетов
94% загр - 0,003 % потеря пакетов

1Gбит/с линк
10% загрузка - 0% потеря пакетов
12% загр 0 % потеря пакетов
20% загр - 0,0008%
30% загр - 0,005 %
64% загр - 0,02 %

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

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

[DuHast]

Дано:
DevBoard, которая формирует UDP пакеты размерностью Data=1024.

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

[Костян]

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

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

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

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

попробуйте JumboFrame

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

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

[kolobok0]

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

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


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

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

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

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

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

Сообщение отредактировал kolobok0 - Nov 10 2011, 08:02

[Костян]

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

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


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

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

[Fast]

JumboFrame сильно не помог. Отсылаю 8K данных.
Причем заметил, что пропадают пакеты пачками от 4..28

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

[Костян]

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

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