[scifi 1]

очень не хочется...но возможно это будет самый простой вариант.

Да, забыл: весьма вероятно, что драйвер тупо игнорирует ошибку и не передаёт код наверх. Часто эти драйверы пишут левой ногой. Так что попробуйте в нём разобраться.

[Real_Bastard 0]

весьма вероятно, что драйвер тупо игнорирует ошибку и не передаёт код наверх. Часто эти драйверы пишут левой ногой. Так что попробуйте в нём разобраться.

ОНО самое!!! Функция udp_send утыкается в функцию low_level_output() (порт STM32).

/**

* This function should do the actual transmission of the packet.....

* @return ERR_OK if the packet could be sent

* an err_t value if the packet couldn't be sent

*

* @note Returning ERR_MEM here if a DMA queue of your MAC is full can lead to

* strange results. You might consider waiting for space in the DMA queue

* to become availale since the stack doesn't retry to send a packet

* dropped because of memory failure (except for the TCP timers).

*/

В общем ждать она не ждет, и всегда отсылает ОК.

Увеличил размер буфера до 1200 байт, чтоб мой килобайт влез, и не надо было разбивать его на части. low_level_output() научил для начала возвращать ошибку. Стало почти хорошо. пакеты теряются один раз из 6 000-10 000, но сразу по несколько. Итого на 100МБайт теряется 100-200К. Поток 93 Мбит\сек.

 

[SergeyVas 0]

Если это видео может как то сжимать его перед отправкой.

[Real_Bastard 0]

Если это видео может как то сжимать его перед отправкой.

Да не. С исправленным драйвером вроде все ОК. около 90Мбит\с выдает без потерь.

 

[TU-104 0]

Неправда. Я специально проследил порядок выполнения udp_send(). Он ведёт прямиком к netif->linkoutput, то есть непосредственно к функции отправки пакета драйвером. Естественно, при условии, что arp уже сделал свои дела. Понятно, что драйвер может буферизировать пакеты перед отправкой, но не обязательно. У меня, к примеру, не буферизирует, а сразу отправляет.

а всё-таки, только так? Вызвать udp_send и проверять по коду ошибки? Может, есть какой-то флаг готовности?

Посмотрел свой low_level_output, проверка есть: пытается распихать в пакет по буферам DMA и при невозможности возвращает ошибку. Конкретно в моём примере выделено 4 буфера размером 1524 байта. Значит, больше никак не узнать, только проверять есть ли место.

Может кто разбирался, еще вопросик: эти 4 буфера под 4 ЛЮБЫХ пакета? 4 пакета по 1500 байт, или 4 пакета по 100 байт...

Изменено 14 апреля, 2016 пользователем TU-104

[kolobok0 0]

а всё-таки, только так?... эти 4 буфера под 4 ЛЮБЫХ пакета? 4 пакета по 1500 байт, или 4 пакета по 100 байт...

 

согласно RFC функция передачи юдп гарантирует отправку. Т.е. если вам вернули код ошибки ОК - то пакет гарантировано дошёл до трансформатора

Вашего передатчика. Так по стандарту.

 

Буфера - тут такое дело. По идее размеры резервирования прописываются в конфигураторе(как тут уже прозвучало). Т.е. зарезервируете 4 по 1000 = будет всего 4 кила.

 

С буферами в основном засада на приёме. Выделять память в драйвере - накладно очень. Но можно а) использовать заголовки ПДП старые

б) делать резервирование таких блоков - для драйвера.

 

(круглый)

[scifi 1]

согласно RFC функция передачи юдп гарантирует отправку. Т.е. если вам вернули код ошибки ОК - то пакет гарантировано дошёл до трансформатора

Вашего передатчика. Так по стандарту.

Ну-ну. Осталось понять, читал ли аффтар кода эти стандарты. Угадайте, каковы шансы?

[kolobok0 0]

..Осталось понять...

 

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

А прочтёт если захочет по уму, от печки.

 

ну где то так

(круглый)

ЗЫ

Элемент иронии если только чуть-чуть :)

 

[TU-104 0]

согласно RFC функция передачи юдп гарантирует отправку. Т.е. если вам вернули код ошибки ОК - то пакет гарантировано дошёл до трансформатора

Вашего передатчика. Так по стандарту.

Неее, никто такой гарантии не даст, что прям до трансформатора дошло. В примере lwip stm32 - дошло да DMA и всё, а там в MII. А там еще физика....

 

Буфера - тут такое дело. По идее размеры резервирования прописываются в конфигураторе(как тут уже прозвучало). Т.е. зарезервируете 4 по 1000 = будет всего 4 кила.

Поотправлял пакеты, похоже, что там(всё в том же примере драйвера) на 4 кадра зарезервировано(не важно какого размера кадр).

 

С буферами в основном засада на приёме. Выделять память в драйвере - накладно очень. Но можно а) использовать заголовки ПДП старые

б) делать резервирование таких блоков - для драйвера.

А что такое ПДП? На приёме в драйвере аналогично организовано 4 буфера, каждый на 1 кадр, максимальный размер ~1500.

 

 

 

[kolobok0 0]

... дошло да DMA и всё, а там в MII. А там еще физика....

...похоже, что там(всё в том же примере драйвера)...что такое ПДП? ...организовано 4 буфера...

 

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

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

DMA = пдп (простите, старый советский слэнг в крови) :)

 

если присмотритесь как устроено(STM32F4xx), то там выделяются заголовки описательные(которые ставятся в очередь dma) и сами буфера выделенные под это дело.

причём на приёме автоматически разруливается наполнение этих входных буферов поставленных в кольцо. И Вы при анализе выбираете только те, которые обозначены как

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

заменить эти буфера - вот именно в этом месте Вам необходимо решать следующие задачи - тупо копировать данные, либо уменьшать объём

буферов на приёме, либо заменять на новые освободившиеся блоки памяти под буфера.

Лично сам тупо заменяю блоки памяти. А беру их из специальной очереди для драйвера. Заполненные буфера - так и уходят на верхний уровень.

т.е. нет операций копирования совсем. А заголовки так и остаются стоять в кольце (после обработки естественно флаги им выставляем правильные).

 

как то так - давно рисовал, по памяти сейчас изложил.

(круглый)

Изменено 15 апреля, 2016 пользователем kolobok0