scifi 1 December 9, 2013 Posted December 9, 2013 · Report post очень не хочется...но возможно это будет самый простой вариант. Да, забыл: весьма вероятно, что драйвер тупо игнорирует ошибку и не передаёт код наверх. Часто эти драйверы пишут левой ногой. Так что попробуйте в нём разобраться. Quote Share this post Link to post Share on other sites More sharing options...
Real_Bastard 0 December 9, 2013 Posted December 9, 2013 · Report post весьма вероятно, что драйвер тупо игнорирует ошибку и не передаёт код наверх. Часто эти драйверы пишут левой ногой. Так что попробуйте в нём разобраться. ОНО самое!!! Функция 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 Мбит\сек. Quote Share this post Link to post Share on other sites More sharing options...
SergeyVas 1 December 12, 2013 Posted December 12, 2013 · Report post Если это видео может как то сжимать его перед отправкой. Quote Share this post Link to post Share on other sites More sharing options...
Real_Bastard 0 December 13, 2013 Posted December 13, 2013 · Report post Если это видео может как то сжимать его перед отправкой. Да не. С исправленным драйвером вроде все ОК. около 90Мбит\с выдает без потерь. Quote Share this post Link to post Share on other sites More sharing options...
TU-104 0 April 14, 2016 Posted April 14, 2016 (edited) · Report post Неправда. Я специально проследил порядок выполнения udp_send(). Он ведёт прямиком к netif->linkoutput, то есть непосредственно к функции отправки пакета драйвером. Естественно, при условии, что arp уже сделал свои дела. Понятно, что драйвер может буферизировать пакеты перед отправкой, но не обязательно. У меня, к примеру, не буферизирует, а сразу отправляет. а всё-таки, только так? Вызвать udp_send и проверять по коду ошибки? Может, есть какой-то флаг готовности? Посмотрел свой low_level_output, проверка есть: пытается распихать в пакет по буферам DMA и при невозможности возвращает ошибку. Конкретно в моём примере выделено 4 буфера размером 1524 байта. Значит, больше никак не узнать, только проверять есть ли место. Может кто разбирался, еще вопросик: эти 4 буфера под 4 ЛЮБЫХ пакета? 4 пакета по 1500 байт, или 4 пакета по 100 байт... Edited April 14, 2016 by TU-104 Quote Share this post Link to post Share on other sites More sharing options...
kolobok0 5 April 14, 2016 Posted April 14, 2016 · Report post а всё-таки, только так?... эти 4 буфера под 4 ЛЮБЫХ пакета? 4 пакета по 1500 байт, или 4 пакета по 100 байт... согласно RFC функция передачи юдп гарантирует отправку. Т.е. если вам вернули код ошибки ОК - то пакет гарантировано дошёл до трансформатора Вашего передатчика. Так по стандарту. Буфера - тут такое дело. По идее размеры резервирования прописываются в конфигураторе(как тут уже прозвучало). Т.е. зарезервируете 4 по 1000 = будет всего 4 кила. С буферами в основном засада на приёме. Выделять память в драйвере - накладно очень. Но можно а) использовать заголовки ПДП старые б) делать резервирование таких блоков - для драйвера. (круглый) Quote Share this post Link to post Share on other sites More sharing options...
scifi 1 April 14, 2016 Posted April 14, 2016 · Report post согласно RFC функция передачи юдп гарантирует отправку. Т.е. если вам вернули код ошибки ОК - то пакет гарантировано дошёл до трансформатора Вашего передатчика. Так по стандарту. Ну-ну. Осталось понять, читал ли аффтар кода эти стандарты. Угадайте, каковы шансы? Quote Share this post Link to post Share on other sites More sharing options...
kolobok0 5 April 14, 2016 Posted April 14, 2016 · Report post ..Осталось понять... когда писал - хотел дать мысль, что реализация реализацией, но существует стандарт пользовательского(с точки зрения стэка) интерфейса. А прочтёт если захочет по уму, от печки. ну где то так (круглый) ЗЫ Элемент иронии если только чуть-чуть :) Quote Share this post Link to post Share on other sites More sharing options...
TU-104 0 April 15, 2016 Posted April 15, 2016 · Report post согласно RFC функция передачи юдп гарантирует отправку. Т.е. если вам вернули код ошибки ОК - то пакет гарантировано дошёл до трансформатора Вашего передатчика. Так по стандарту. Неее, никто такой гарантии не даст, что прям до трансформатора дошло. В примере lwip stm32 - дошло да DMA и всё, а там в MII. А там еще физика.... Буфера - тут такое дело. По идее размеры резервирования прописываются в конфигураторе(как тут уже прозвучало). Т.е. зарезервируете 4 по 1000 = будет всего 4 кила. Поотправлял пакеты, похоже, что там(всё в том же примере драйвера) на 4 кадра зарезервировано(не важно какого размера кадр). С буферами в основном засада на приёме. Выделять память в драйвере - накладно очень. Но можно а) использовать заголовки ПДП старые б) делать резервирование таких блоков - для драйвера. А что такое ПДП? На приёме в драйвере аналогично организовано 4 буфера, каждый на 1 кадр, максимальный размер ~1500. Quote Share this post Link to post Share on other sites More sharing options...
kolobok0 5 April 15, 2016 Posted April 15, 2016 (edited) · Report post ... дошло да DMA и всё, а там в MII. А там еще физика.... ...похоже, что там(всё в том же примере драйвера)...что такое ПДП? ...организовано 4 буфера... речь идёт о стандарте. т.е. если управление вернулось в вызываемую программу - значит ушло гарантированно. либо ошибка на возврате. перепишите "драйвер" (с учётом возврата ошибки и синхронизации вызова. если считаете, что вероятность сбоя высока), делоф то... DMA = пдп (простите, старый советский слэнг в крови) :) если присмотритесь как устроено(STM32F4xx), то там выделяются заголовки описательные(которые ставятся в очередь dma) и сами буфера выделенные под это дело. причём на приёме автоматически разруливается наполнение этих входных буферов поставленных в кольцо. И Вы при анализе выбираете только те, которые обозначены как уже отработанные. По коду ошибки и состоянию флагов Вы имеете цепочку пакетов с полезными данными(либо один пакет - не суть). Вам требуется заменить эти буфера - вот именно в этом месте Вам необходимо решать следующие задачи - тупо копировать данные, либо уменьшать объём буферов на приёме, либо заменять на новые освободившиеся блоки памяти под буфера. Лично сам тупо заменяю блоки памяти. А беру их из специальной очереди для драйвера. Заполненные буфера - так и уходят на верхний уровень. т.е. нет операций копирования совсем. А заголовки так и остаются стоять в кольце (после обработки естественно флаги им выставляем правильные). как то так - давно рисовал, по памяти сейчас изложил. (круглый) Edited April 15, 2016 by kolobok0 Quote Share this post Link to post Share on other sites More sharing options...
