Не знаю - весь тред не читал, но из первого сообщения ТС это не следует.


Не знаю как так можно занять Cortex, чтобы он не успевал не свои кадры отсеивать.. %-)
Сейчас как раз занимаюсь Ethernet в устройстве на LPC1768 (100МГц). Оно включено тоже в корпоративную сеть с неск. сотнями устройств.
Если включить встроенный снифер, то получаю непрерывный большой поток широковещательных (и не только) ARP-, IP/UDP-кадров,
и некоторых других типов кадров.
Загрузка CPU при этом (в целом, там почти ничего нет только uCOS крутится, да снифер инфу о потоке в UART выводит) составляет 0.8 ... 1.0 %.
И где я не прав?
И то это у меня драйвер проверяет каждый пакет, а не только свои (валидность заголовков Ethernet/ARP/IP/TCP/..., контрольные суммы считает).
А если отбрасывать сразу не свои по какому-то признаку, то загрузки тут вообще практически никакой не должно быть.
Если, как пишет ТС, кадры идут с периодом 10мкс, и работает Ethernet-DMA, то на все действия в ISR Ehternet хватит с лихвой ~100тактов.


Это Вы так поняли. И это совсем не следует из вопроса ТС.
Вменяемые чужие устройства даже в большой сети, не генерят столько широковещательного траффика.
Я прямо сейчас смотрю в лог сниффера, который выводит моё устройство на LPC1768 находящееся в достаточно большой корпоративной сети.

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


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


Это не оправдывает использование broadcast для передачи широкополосного потока данных.
Для целей "как узнать IP и MAC одновременно" можете его и использовать, тут и не будет противоречия при построении сети ethernet.
На сколько помню, Вы всегда были за надёжность и качество устройств. Ваши слова из одной темы:

Очень подходит для оценки устройств, что заглушили модуль автора топика


Это утверждение, что можно?
Расскажите пожалуйста, каким образом (без использования софта) Вы фильтруете broadcast? Вы, видимо, изобрели какой-то свой MAC-контроллер который внедряете в какие-то свои процессоры?
Расскажите, может приобретём парочку для тестов


Про ШИМ я спрашивал в другой теме (она, кстати, не закрыта), и Вы там ничего дельного посоветовать не смогли и умыли руки. Если знаете возможные причины проблемы обсуждаемой в той теме - добро пожаловать, буду благодарен за полезные советы.

Ну вы сравнили.
uCOS это совсем другое дело!
Это самый быстрый и правильный стек из всех доступных для мелких контроллеров.

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

Нет, Вы не поняли
Только ОС - uCOS. Стек к сожалению свой, не uCOS-кий.


Сниффер у меня - это часть моего ПО на LPC, которая выводит в лог поток всех кадров, которые лезут с RMII.

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



Немного не системно. Снифер должен быть независим от TCP стека, а то как-то резко падает доверие.

У меня все входящие кадры проходят через сниффер и только после него попадают в штатный обработчик.
Если-б что-то терялось и не отображалось в сниффере, оно-бы и до штатного обработчика не доходило.
А я уже не раз проверял работу ПО передачей большого многомегабайтного потока (через TCP-сокет) - ничего не теряется.
И стек построен на callback-вызовах - если-бы были пропуски из-за переполнения приёмной очереди, то загрузка у CPU была-бы близка к 100%.
А она даже при тестовом TCP-потоке (по двум сокетам одновременно) максимум до 7% доходит.

Расскажите мне тогда Ваш анекдот про broadcast и то, как его фильтровать, тоже хочу посмеяться

Я считаю по другому.
Возмем реалистичный 70 Mbit поток по Ethernet. Это 8 Мбат в сек данных.
Писать вам такой поток некуда.
Внешней памяти нет. На SD такую скорость не разовьете, а если б развили то 100% загрузки CPU точно было бы.
Даже на внутренней шине пересылка такого поток заняла бы гораздо больше 7%.

Вообще все это подозрительно.

Загрузку может неправильно определяете?

вот что пишет ТС в 1 сообщении



я понял что другие "не наши". По ходу он это уточнил, да они действительно не их.





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

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

Есть среда - надо в ней жить, а не менять. Пробовать менять можно, но это процесс долгий, и полон чертиков в коробочках....


И ваще во всем виновата операционка я уверен, это она все ресурсы скушала...





снова невнимательно читаете. Идея была заглушить UDP вообще. Для этого и надо 2 устройства. Одно полное живет в сети отвечает на все вопросы ARP и так далее, и жует входной поток. Из него выдирает те сообщения что нужно и по ТСР на четки IP передает их, так же получает ответы и шлет в сеть. Второе устройство с урезанным езернет функционалом, без UDP ваще, все пакеты UDP просто игнорирует, и принимает только ТСР от первого устройства. В экстрим режиме, даже не ТСР а вообще raw ethernet.

Таким образом все UDP пакеты что бродкаст размером 100 байт и идут через 10 мкс, отвергаются значительно быстрее по признаку UDP, чем по разбору содержимого, и высвобождают ресурсы. Вот такое было предложение. Это костыль и заплатка- это не решение. Оно просто позволяет на существующей плате только подправив софт получить готовое устройство и не более того.

Да, должно, но для этого надо потратить время и деньги. И можно говорить о кривости и несовместимости тех остальных девайсов. И если не указать на ошибки, то broadcast так и будет использоваться для передачи огромного потока данных, а другие будут этот поток фильтровать и не расскажут остальным - КАК?!

У меня далеко не 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).

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


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

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

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

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

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

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

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

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

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

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