Где теряются 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

[kolobok0]

..UDP пакеты размерностью Data=1024...Цель - добиться максимальной пропускной способности при 100% доставки пакетов.
1. Где происходит потеря пакетов ?
2. Как повысить надежность доставки пакетов ?
3. Может ли размер пакета влиять на надежность доставки ? Возможно стоит уменьшить до 128 или 256

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


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

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

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

[Костян]

где происходит потеря? либо помеха, либо не успевает приёмник.

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

вот эти вещи разные:
а) пропускная способность
б) надёжность доставки

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

[Fast]

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

[Костян]

может быть
- драйвер сетевой карты (а если запуститься под Win ?)

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

- настройки сетевой карты (кол-во дескрипторов, буфер приема, частота прерываний)

попробую

- разница в клоках DevBrd и чипа сетевой карты

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

- софт приемника не успевает обрабатывать заголовки пакетов (скипает счетчики)

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

UDP не гарантирует доставку. UDP гарантирует, что пакет будет передан. т.е. уйдёт.

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

[Fast]

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

пропуск-вставка лишнего бита в чипе приемника, если тактирующие генераторы имеют номиналы, отличающиеся на проценты. Соотв. произойдет отбрасывание пакета UDP.

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

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

[MALLOY2]

например, wireshark

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

[Костян]

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

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

для начала нужно выяснить, где ошибка. Для этого надо обрабатывать данные после их накопления в большом буфере ОЗУ

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

[Fast]

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

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

[cioma]

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

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

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

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

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

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

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

[Костян]

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

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

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

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

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

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

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

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

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

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

[cioma]

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

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

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

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

[DuHast]

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

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

[VladimirB]

...
Цель - добиться максимальной пропускной способности при 100% доставки пакетов.
...

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


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

[Костян]

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

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

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

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

попробуйте JumboFrame

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

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

[Fast]

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

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

[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

[troiden]

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

[DuHast]

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

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

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

[Костян]

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

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

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

Вопросы:
1 Вы что потом с принятым пакетом делаете, просто счётчики сверяете или ещё както обрабатываете?

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

2 Для работы с сокетами WinPcap пробовали илспользовать?

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

3 Может у вас просто приемный софт не совсем коректно с сокетами работает?

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

4 какая конфигурация у приёмной машины?

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

5 какая загрузка процессора при обработке потока на котором теряются пакеты?

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

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

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

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

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

[troiden]

Поэтому брать внешную сетевуху от Intel пока смысла не вижу.

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

[Костян]

при работе со встроенной сетевой картой (какой был чипсет уже и не упомню) периодически менялись местами два пакета - это будет покруче простого пропадания

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

[kolobok0]

...UDP-поток...менялись местами два пакета...

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

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


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


(круглый)

[troiden]

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

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

[andrewlekar]

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

[Костян]

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

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

[andrewlekar]

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

[kolobok0]

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

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

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

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

(круглый)

[andrewlekar]

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

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

[Aner]

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

[Костян]

еще момент
1) Какова длина кабеля?

~2m

2) Какой категории кабель?

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

[Костян]

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

[Sergey_Bekrenyov]

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

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

[Костян]

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

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

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

[Sergey_Bekrenyov]

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

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

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

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

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

[Aprox]

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

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

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

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

[Костян]

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

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

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

[Fast]

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

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

[cioma]

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

[Aprox]

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

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

Насчет потерь. В моем случае даже доли процента потерь не допустимы.

Дублируйте пакеты.

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

на протоколе TCP- наверное можно. На UDP- точно нельзя.

[litv]

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

[andrewlekar]

Можно передавать в определенной конфигурации по udp в связке (плис в компьютер) данные без потерь

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

[Fast]

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

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

[vadimp61]

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

[litv]

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

[Aprox]

Данные идут с АЦП с эфира.
Пишем часами со скоростью 102 МБайт/c, ошибок нет вообще.

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

[litv]

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.

[Костян]

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

Это все так :-) Но здесь в теме уже опоминалось, что потери идут на стыке сетевой карты и памяти комьютера, он попросту их не успевает считывать. Т.е UDP тут не причем(вообще говоря по классике, UDP пакеты могут терятся в развлетвленных сетях, а тут ему куда деваться, если он идет всего по одному 3м кросс провододу прямо в комп).
Это подвтержает также тот факт, что передача пакетом с ПК идет не равномерно, в моем случае он 9 пакетом пишет, потом пауза. И т.д.

2 litv
Можно вопрос ?

У Вас были потери пакетов ? или с первого пинка на вашем i7 заработало ? Интересует именно момент считывание ethernet кадров с сетевой, а не запись данных на винт.

[litv]

"Это подвтержает также тот факт, что передача пакетом с ПК идет не равномерно, в моем случае он 9 пакетом пишет, потом пауза. И т.д. "

Ваш случай мне ничего не подтверждает. Вы Стив Джобс или Шеннон? Почему я Вам должен верить?

<-Слышал я этих Beatles. Скрипят, фальшивят, в ноты не попадают.
- Где ты их слышал?
- Да мне Мойша вчера напел.>

Мы сделали за три месяца. А не с какого-то пинка .
Последовательно сначала 100 Мбит, потом 1 Гигабит.
Вначале тоже были потери.

[Костян]

Вы Стив Джобс или Шеннон? Почему я Вам должен верить?

А почему вы Шеннону верите ?

[kolobok0]

...Можно передавать в определенной конфигурации по udp...

дык блин. можно то можно, но вот гарантии на уровне UDP протокол не даёт. Вы можете с этим соглашаться или нет - это уже чисто ваше мнение и с протоколом не имеет вообще ничего общего.

(круглый)

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

по классике UDP (который протокол) есть первично. а реализация вторично. дык вот...если любой программист в рамках протокола может похерить пару пакетов = имеет право. вы хотите тестировать эти условия (при которых пакеты выкидываются)? И не важно что писал программист. свитч, роутер, сетевую карту, драйвер или программку под вынь32...

(круглый)
ЗЫ
То что говорит товарищ выше - это до поры работает... может год, может и все 100. Если ему достаточно такой надёжности - ради бога. но это не 100%

[Aprox]

1. какая ОС используется?
windows xp 32, windows xp 64, windows 7 64

Извините, верится с трудом. Виндовский TCP/IP стек со своими сокетами не в состоянии переваривать сетевые потоки 960 mbps.

[cioma]

Да тут начальные требования надо менять (100% доставка и обработка пакетов). Израильтяне Ethernet в своих танках Merkava используют, если там надежности хватает, то и для этой задачи должно

[Konst_777]

...Вначале тоже были потери.

А можете подробно описать, почему вначале терялись пакеты UDP и, какие меры позволили устранить потерю пакетов?

[andrewlekar]

Израильтяне Ethernet в своих танках Merkava используют

Дураки! Wi-Fi надо было использовать. Представляете, башня отвалилась, а стрелять всё равно может.

[Fast]

Дураки! Wi-Fi надо было использовать. Представляете, башня отвалилась, а стрелять всё равно может.

точно! а если Wi-MAX, то башню вообще можно забрасывать в тыл врага на 10 км