У меня далеко не 70Мбит.
Скорость ограничивается ПО на компе, которое принимает и передаёт данные. Оно тормозное - устройство периодически успевает заполнить его приёмное окно
и постоянно из-за этого идут приостановки потока на приёмном конце (tcp.window == 0).
Скорость там всего = неск. килобайт/сек.

Читаю внимательно, это Ваша идея была - два устройства, одно глушит UDP с broadcast и т.д., AlexandrY broadcast фильтровать собрался, ну или по крайней мере знает, как это сделать.
Но, видимо, это какая-то государственная тайна, она так и не озвучена.

Вот! Спасибо. Похоже единственный человек, кто понял задачу.



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


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

Спасибо, всегда приятно быть молодым.

Из Ваших слов следует, что Вы сами являетесь стороннником возможности использования broadcast для отправки данных (массивных данных), следовательно сами и создаёте себе проблемы. Была указана грубейшая ошибка с которой многие не согласились, и Вы в их числе. Ну и способы решения предложены так же, но это временное решение. Если то, о чём вы утверждаете, соответствует стандартам, - всегда найдутся "умельцы", которые отправят broadcast-ом ещё больший поток, что тогда будете делать? Придуманное Вами решение уже не будет работать, и тогда....
А может быть уволят тех, кто создал тот мега-девайс , с которым другие нормальные устройства совместно не могут работать.

Да, в Эту Студию бы тех, кто организовали этот бредкастный поток !
Наверняка это наши же собратья, так же плохо учившие матчасть... Но могущие быть пристыженными в отличие от Альтер всяких и быстро повиниться и исправиться


Я бы лично датчик сделал управляемым -- если получает пакет ON с некоего адреса, запоминает его в очередь рассылок и шлёт свои данные на конкретный IP, его все маршрутизаторы отлично больше никому не передадут.
Ну и пакет OFF на всякий случай, вдруг система может выключаться частями...
Или там вся пропускная способность сети (100 байт х 100 000 раз в секунду == 10 000 000 выходит, это 100-Мбитную сеть затопит, на 1Г нормально будет) занята единичными бродкастами, к каждому по отдельности не пролезть уже будет ?
По-любому, такой поток лучше пустить по выделенной линии к конкретному получателю, на отдельный вход, это недорого и упрощает сеть.

Вообще, можно пытаться идти ещё более другим путём -- разделить "извра-сеть" и обычную, в которой есть слабые устройства, одно из которых сейчас 1 раз в день падает, и которое решено заменить костыльным, но тоже как-то странно... Но в наших кругах ЛПРцы часто так себя ведут
Если датчики смогут слать своим потребителям, а "наш" девайс с ними не связан... Ну или связан несильно, да настройкой маршрутизаторов за 3 коп можно всё-таки не пересылать нам эти дурные пакеты...

Пока наш "чёртик" отдыхает, можно предложить ещё один путь -- поисследовать, от чего "затык" в "шумном" подключении. И вообще, что такое есть "затык" ? Зависание ядра, потеря важного пакета, неотработка чего-то вовремя ?
По идее, сеть Eth может терять "лишние" пакеты, которые нет ресурсов обработать, и железо нашего контроллера, если не всё софтом отработано из прошлых данных, просто что-то отбросит, не передав в ОЗУ.
В текущей конфигурации можно нарастить буфера и обрабатывать максимально имеющийся объём полученных данных, если получен один пакет ? После обработки одного можно быстро увидеть, сколько ещё торчит в памяти принятых пакетов, не возвращаясь к обычной работе ? Это должно быть гораздо быстрее, особенно если основная обработка -- проверить первые байты и выбросить.

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

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

Сообщение отредактировал kolobok0 - Sep 23 2014, 07:17

Возможно у Вас где-то кратковременная пиковая загрузка CPU возникает.
Поройте код на предмет более равномерного распределения обработки.


Это называется "flowcontrol".
Но боюсь это справедливо только для конкретных протоколов точка-точка (типа TCP-сокета).
Если-бы такое делать для всех пакетов в сети, то самое медленное устройство будет тормозить всю сеть. А если оно ещё и повиснет...

Вы меня не поняли..речь шла о стандартной библиотеки lwip и в частности об обработчике прерывания пдп от Ethernet-а
никаких затыков на всём многообразии поддерживаемых, данной библиотекой, протоколов не наблюдаю.

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

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

Вернулся из отпуска.
Почитал последние постинги.
"Для тех, кто не слышал, повторяем": основная задача это форвард радио пакетов в ethernet.
Так что на чисто ethernet остается не так много времени.
Это STM32F107 @ 72 MHz.
Да, в прерывании идет копирование пакета.

Получил плату с 2х ядерным кортексом. Буду пробовать.

Ну вот.... А ведь Вас предупреждали...
Если у Вас весь код так построен, то ничего удивительного, что он не успевает UDP-пакеты разгребать...

A как надо? В прерывании производить всю обработку? Или оставить и ждатъ пока следующий пакет затрет предыдущий?
Проблема не в этом. Там без граблей не обойтись. А грабли не наш метод.

Я конечно не знаком с Ethernet-контроллером STM, но в LPC-шном RX-часть Ethernet-контроллера аппаратно поддерживает очередь доступных для заполнения
буферов: ПО заполняет очередь дескрипторами буферов; кадр принимается в очередной буфер; ПО извлекает дескриптор заполненного буфера из очереди;
приём после этого не останаливается и ничего не затирает - он идёт в след. буфер в очереди.
А в это время кадр в принятом буфере обрабатывается (хоть в ISR хоть в фоновом процессе). И эта обработка проводится прямо в этом-же самом буфере без каких-либо копирований.
Приём может приостановиться только после исчерпания всех буферов в очереди доступных. Но это может произойти только если ПО не успевает обработать поток кадров в течение длительного времени.
К кратковременным задержкам в обработке кадров такой алгоритм работы устойчив - этому помогает глубина очереди доступных для заполнения буферов.
И строить обработку нужно с минимумом копирований, раз у вас проблемы с быстродействием.

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