Посоветуйте микроконтроллер, для IP (UDP) filtering Опции

[A. Fig Lee]

В общем, в одной ethernet сети по производственной необходимости оказалось наше устройство на STM32F107 и
много других, которые шлют UDP broadcast.
Так как это ethernet broadcast, приходится принимать все пакеты, потом сбрасывать, когда ясно что не нам.
В итоге периодически затыкается контроллер, так как есть и другие задачи.

Хочу разбить на 2: один микроконтроллер с ethernet будет фильтровать IP пакеты, другой делать другие задачи.
Как бы его и так хватает, это чисто раутер с 802.15.4 250 килобит на IP.
Если бы не затыкался. Какой взять не очень большой микроконтроллер с ethernet?
Хорошо бы еще канал пошире для обмена с другим микроконтролером, но это вряд ли.
Наверное, обычный SPI.

Думал поставить Wiz5100 для фильтра бродкаст пакетов, но он же, наверное, пропустит UDP бродкаст пакет?

[doom13]

Что это за устройства такие, что broadcast-ами загадили всю сеть? И кто это придумал слать UDP с broadcast MAC-адресом?

[Golikov A.]

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

[doom13]

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

Для этого используется IP multicast (для передачи сообщения нескольким адресатам). MAC-адрес в этом случае формируется по определённым правилам, а тут описано по каким.

Broadcast MAC-адрес используется только в ARP-запросах, но они-то точно не должны вешать сеть.

[Golikov A.]

правильнее сказать должен быть использован....

[doom13]

В общем, использование для отправки какой-либо информации UDP с broadcast MAC-адресом - неправильное решение, поэтому и вопрос был - почему так сделано. При таком подходе и большом потоке данных можно заглушить половину устройств в сети, что и имеем. Ни один MAC-контроллер не умеет фильтровать пакеты с broadcast MAC-адресами, а вот при использовании multicast есть такое понятие как hash table. Данная hash table и используется MAC-контроллером для пропуска необходимых multicast MAC-адресов (тех что в ней прописаны) и фильтрации всех остальных.

[A. Fig Lee]

В общем, использование для отправки какой-либо информации UDP с broadcast MAC-адресом - неправильное решение, поэтому и вопрос был - почему так сделано. При таком подходе и большом потоке данных можно заглушить половину устройств в сети, что и имеем. Ни один MAC-контроллер не умеет фильтровать пакеты с broadcast MAC-адресами, а вот при использовании multicast есть такое понятие как hash table. Данная hash table и используется MAC-контроллером для пропуска необходимых multicast MAC-адресов (тех что в ней прописаны) и фильтрации всех остальных.

"В жизни все не так как на самом деле"

Спасибо, интересная теория. Моя задача не найти "кто прав, кто виноват", а придумать решение.
Имеем устройства, без которых нам не жить, и которые посылают именно UDP broadcast с MAC broadcast.
Это данность.

[scifi]

Так как это ethernet broadcast, приходится принимать все пакеты, потом сбрасывать, когда ясно что не нам.
В итоге периодически затыкается контроллер, так как есть и другие задачи.

Не верю, что это нельзя решить в прошивке. Верю, что может не хватить знаний/опыта/времени, и второй МК как костыль тогда вполне годное решение при условии, что уж для него знания/опыт/время есть. А вот это как раз не просматривается.
Может быть, тупо приладить дешёвый домашний маршрутизатор и настроить его на фильтрование?

[A. Fig Lee]

Не верю, что это нельзя решить в прошивке. Верю, что может не хватить знаний/опыта/времени, и второй МК как костыль тогда вполне годное решение при условии, что уж для него знания/опыт/время есть. А вот это как раз не просматривается.
Может быть, тупо приладить дешёвый домашний маршрутизатор и настроить его на фильтрование?

В какой "прошивке"? Можно решить. И решается. Но времени больше ни на что не остается.
100 байтовый пакет занимает 10 микросекунд обработка. За столько же приходит следующий.

[Golikov A.]

Ну все верно. Не хватает ресурсов на работу, потому что задолбили пакетами - ставь выделенный обработчик. А поставить 2 одинаковых проца - дорого? Зачем элементную базу то плодить?

Можно кстати красиво решить: Ставьте в сеть 2 ваших устройства, на первом, что делает дело, выключайте UDP вообще, на втором создавайте TCP соединение с первым, и пусть он пакеты фильтрует, и те что к устройству по ТСР отдает первому, тот обрабатывает и возвращает обратно. Тогда даже плату переразводить не надо, просто 2 штуки поставить.

[SM]

А, просто, поставить более мощный процессор? Не с 72 МГЦ, а, например, с 720 МГЦ ? Или свет клином именно на этом сошелся?

[doom13]

"В жизни все не так как на самом деле"

Спасибо, интересная теория. Моя задача не найти "кто прав, кто виноват", а придумать решение.
Имеем устройства, без которых нам не жить, и которые посылают именно UDP broadcast с MAC broadcast.
Это данность.

То была не теория, а элементарные правила, как должна осушествляться передача одной информации несколькии адресатам при использовании ethernet. Раз уж так сделано, то решение - только более мощный процессор, т.к. если бы использовались пакеты с multicast, их можно было бы фильтровать на уровне MAC железно, Вам же придётся задействовать ресурс процессора.

[kolobok0]

...приходится принимать все пакеты, потом сбрасывать, когда ясно что не нам....

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

в тех стеках что общедоступны, обычно не оптимально по скорости код написан.
так-же важен размер памяти под кванты приёма пдп. если длина мусорных пакетов 100 байт, то делать больше 150-200 байт входные буфера не правильно.
так-же присмотритесь к обработчикам копирования, перемещения, выделение, освобождение и прочих по работе с памятью...

[WitFed]

Лечить, естественно, нужно корень, в меру возможности доступа к его авторам, но пока можно приделать костыли.
(Анекдот на эту тему слышал об эмблеме софтверной компании: сверху перечёркнутый красным жук, в центре велик, внизу грабли, всё на фоне перекрещенных костылей
Если даташиты все есть, в прерывании от Eth можно узнать первые байты пришедшего пакета и выкинуть его, если FF. Без проходов по официальным слоям стека это может занять 1 мкс.
Также вдруг в железке есть свойство запретить к приёму какие-то MAC-адреса совсем, от особо шумящих...
API своё надо прошерстить на предмет как можно более низких запретов.

[doom13]

Лечить, естественно, нужно корень, в меру возможности доступа к его авторам, но пока можно приделать костыли.

Говорят, костыль нужен, как должно быть неважно.

Также вдруг в железке есть свойство запретить к приёму какие-то MAC-адреса совсем, от особо шумящих...

Какие-то запретить можно, но broadcast mac нет, его примут все устройства.

[A. Fig Lee]

Ну все верно. Не хватает ресурсов на работу, потому что задолбили пакетами - ставь выделенный обработчик. А поставить 2 одинаковых проца - дорого? Зачем элементную базу то плодить?

Можно кстати красиво решить: Ставьте в сеть 2 ваших устройства, на первом, что делает дело, выключайте UDP вообще, на втором создавайте TCP соединение с первым, и пусть он пакеты фильтрует, и те что к устройству по ТСР отдает первому, тот обрабатывает и возвращает обратно. Тогда даже плату переразводить не надо, просто 2 штуки поставить.

Да както некузяво. И так 100 ножковый СТМ32 стоит. Еще один 100 ножковый ради ethernet только.
2. Красиво не получится. Как они будут соединятся, в том же сегменте?
Там фишка же в том, что UDP broadcast приходит в пакете ethernet broadcast. То есть 2й, где UDP выключено, все равно будет принимать весь поток так как вунужден принимать ethernet broadcast - вдруг там ARP? и анализировать.

А, просто, поставить более мощный процессор? Не с 72 МГЦ, а, например, с 720 МГЦ ? Или свет клином именно на этом сошелся?

Какой имеено процессор рекомендуете? Все они, как правило, уже более навороченные. Не ставить же А8 для простого раутера?

Для этого используется IP multicast (для передачи сообщения нескольким адресатам). MAC-адрес в этом случае формируется по определённым правилам, а тут описано по каким.

Broadcast MAC-адрес используется только в ARP-запросах, но они-то точно не должны вешать сеть.

Не верю!
Вот документ:
http://tools.ietf.org/html/rfc1122#page-66

When a host sends a datagram to a link-layer broadcast address,
the IP destination address MUST be a legal IP broadcast or IP
multicast address.

Все нормально: UDP бродкасты посылаются с MAC бродкастами

[doom13]

Не верю!

Чему именно не верите, что broadcast не используется для передачи данных, а используется в ограниченном числе протоколов? Тогда Google в помощь.

Все нормально: UDP бродкасты посылаются с MAC бродкастами

Broadcast используется в основном для служебной информации или для передачи другой исключительно узкополосной информации. Если Вы начнёте бомбить данные при помощи broadcast - заглушите все устройства в сети, что и произошло.

[A. Fig Lee]

Чему именно не верите, что broadcast не используется для передачи данных, а используется в ограниченном числе протоколов? Тогда Google в помощь.


Broadcast используется в основном для служебной информации или для передачи другой исключительно узкополосной информации. Если Вы начнёте бомбить данные при помощи broadcast - заглушите все устройства в сети, что и произошло.

При чем здесь "ограниченное число протоколов"? Бродакст используется там, где он оправдан, а не там, где "гугл разрешил".
Не верю тому, что "неправильно посылать UDP broadcast с MAC broadcast".
Все законно.
Бывает, что надо и данные передавать при помощи бродкаст, как видим.
То, что Вам такая ситуация не попадалась, ни о чем не говорит. С опытом прийдет.

[SM]

Какой имеено процессор рекомендуете? Все они, как правило, уже более навороченные. Не ставить же А8 для простого раутера?

Не для роутера, а для всего проекта в целом на одном CPU. Можно и A8, почему нет, если окажется удобно и по цене пройдет. Можно ARM9 какой нибудь. Вообще, для того, чтобы роутер не был узким местом, их обычно делают именно на A8 или сопоставимых MIPS, и при этом часто они все равно узким местом остаются. Можно, кстати, эту часть разгребалки сделать и на FPGA, если там действительно загрузка по самые помидоры.

[A. Fig Lee]

Не для роутера, а для всего проекта в целом на одном CPU. Можно и A8, почему нет, если окажется удобно и по цене пройдет. Можно ARM9 какой нибудь. Вообще, для того, чтобы роутер не был узким местом, их обычно делают именно на A8 или сопоставимых MIPS, и при этом часто они все равно узким местом остаются. Можно, кстати, эту часть разгребалки сделать и на FPGA, если там действительно загрузка по самые помидоры.

Это слишком большие расходы на разработку. Проще поставить 2 контроллера М3 и связать по SPI.
А8 надо операционку и т.д. слишком громоздко.

[doom13]

При чем здесь "ограниченное число протоколов"? Бродакст используется там, где он оправдан, а не там, где "гугл разрешил".

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

Не верю тому, что "неправильно посылать UDP broadcast с MAC broadcast".
Все законно.

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

Бывает, что надо и данные передавать при помощи бродкаст, как видим.
То, что Вам такая ситуация не попадалась, ни о чем не говорит. С опытом прийдет.

Как видим, передача при помощи broadcast добавила Вам лишних проблем, которых могло бы и не быть если разобраться с multicast.
Скорее всего с опытом к Вам придёт понимание того, что в данной ситуации нужно было использовать групповой IP-адрес, а не строить "костыль" для выхода из ситуации.

[A. Fig Lee]

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

Ерунда. У меня используется.

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

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

Как видим, передача при помощи broadcast добавила Вам лишних проблем, которых могло бы и не быть если разобраться с multicast.
Скорее всего с опытом к Вам придёт понимание того, что в данной ситуации нужно было использовать групповой IP-адрес, а не строить "костыль" для выхода из ситуации.

Честно говоря своим нравоучительством начинаете раздражать.
Объясняю для тех, кто не понял: ЭТО НЕ МОЙ КОД, НЕ МОЕ УСТРОЙСТВО, СДЕЛАТЬ ТАМ НИЧЕГО НЕ МОГУ.
ВОПРОС НЕ О ТОМ.

[SM]

А8 надо операционку и т.д. слишком громоздко.

Вовсе не обязательно, код пишется точно так же, как и для M, компилятор тот же, и периферия там очень похожая по сути, регистрам, прерываниям, и т.д., а всякие там механизмы трансляции страниц, защит, и т.п. много-задачно-пользовательскую шнягу, просто не надо включать и трогать, забыть о них, и все. Будет "как-бы М", но А.

[A. Fig Lee]

Вовсе не обязательно, код пишется точно так же, как и для M, компилятор тот же, и периферия там очень похожая по сути, регистрам, прерываниям, и т.д., а всякие там механизмы трансляции страниц, защит, и т.п. много-задачно-пользовательскую шнягу, просто не надо включать и трогать, забыть о них, и все. Будет "как-бы М", но А.

Какой именно контроллер посоветуете для начала "посмотреть"?

[SM]

Какой именно контроллер посоветуете для начала "посмотреть"?

А какая периферия-то нужна, кроме ethernet?

[A. Fig Lee]

А какая периферия-то нужна, кроме ethernet?

Ничего особенного, USB device, I2C, SPI, GPIO с десяток, может немного больше..
Flash и RAM наружной нет.

[doom13]

Ерунда. У меня используется.

Аргумент!!!

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

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

[SM]

Flash и RAM наружной нет.

Я только в TI ориентируюсь, там не знаю таких A, чтобы не надо было им внешней Flash, так что им придется добавить SPI-флешку для хранения в ней кода, и (возможно) SDRAM-ку. Посмотреть бы для начала советовал на всякие там AM1705, AM1808, и т.п., это даже не А, это АРМ-9, но, думаю, должно хватить.

Еще, на сколько я знаю, атмел делает MCU на базе Cortex-A5, и на ARM9 тоже. Всякие там SAMA5, SAM9
Freescale A5 делает.

Если надо 1GbE, то AM335x

[A. Fig Lee]

Я только в TI ориентируюсь, там не знаю таких A, чтобы не надо было им внешней Flash, так что им придется добавить SPI-флешку для хранения в ней кода, и (возможно) SDRAM-ку. Посмотреть бы для начала советовал на всякие там AM1705, AM1808, и т.п., это даже не А, это АРМ-9, но, думаю, должно хватить.

Еще, на сколько я знаю, атмел делает MCU на базе Cortex-A5, и на ARM9 тоже. Всякие там SAMA5, SAM9
Freescale A5 делает.

Если надо 1GbE, то AM335x

Спасибо, гляну..

[doom13]

Спасибо, гляну..

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

[A. Fig Lee]

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

Спасибо.
Я вот думаю, не проще ли взять beaglebone black и добавить к нему cape который бы принимал 802.15.4

"Все уже придумано до нас"

[SM]

Я вот думаю, не проще ли взять beaglebone black и добавить к нему cape который бы принимал 802.15.4
"Все уже придумано до нас"

Это самый простой и быстрый вариант, там уже линукс есть, все поднятно и работает. А под ним все необходимое давно уже написано и отлажено, только, собственно, Ваш софт основной туда перетащить, чтобы он научился из-под линукса с периферией работать как Вам надо.

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

Также можете взять за основу любой готовый модуль на AM3xxx или AM18xx (они обычно в формате SODIMM), удобно для встраивания в свою систему.

[scifi]

В какой "прошивке"? Можно решить. И решается. Но времени больше ни на что не остается.
100 байтовый пакет занимает 10 микросекунд обработка. За столько же приходит следующий.

Не верю. Наверняка можно организовать раннюю фильтрацию кадров, чтобы было не 10 мкс, а 1 мкс, как было уже сказано выше.

[Golikov A.]

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

В моем варианте "красиво" все таки получиться, ваш первый проц все знает про второй проц, и никакие ARP, DHCP и прочее второму принимать не надо, Может вообще на сыром уровне езернет остаться, даже без IP. Сеть подзагадит. но мы же ради "красиво"

А еще из "дельных" советов, может вам взять какую-то LPC с 2 ядрами, типа
http://www.nxp.com/products/microcontrolle...tex_m4/lpc4300/
пусть одно ядро езернет разгребает, и со вторым связь быстрая, которое всю работу будет делать...

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

[A. Fig Lee]

Не верю. Наверняка можно организовать раннюю фильтрацию кадров, чтобы было не 10 мкс, а 1 мкс, как было уже сказано выше.

Можно. Прям в интеррапте поставить "костыли" - сделать раннюю фильтрацию кадров.
Не делаю по 2м причинам:
1) Сейчас собираемся делать версию 2, и есть возможность поменять хард, потом будет сложно. Стараюсь переложить на хард как можно больше,
софт всегда успею пригрузить.
2) Есть мысль в следующих версиях пользовать самому UDP бродкаст для автоматического нахождения своих устройств в сети.
Придется в эти костыли ставить еще костыли, в общем чем дальше, тем страшнее

[scifi]

А еще из "дельных" советов, может вам взять какую-то LPC с 2 ядрами, типа lpc4300

+1. Там и тактовая 204 МГц против 72 МГц у STM32F107. Может оказаться, что только за счёт тактовой проблема отпадёт.

[A. Fig Lee]

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

В моем варианте "красиво" все таки получиться, ваш первый проц все знает про второй проц, и никакие ARP, DHCP и прочее второму принимать не надо, Может вообще на сыром уровне езернет остаться, даже без IP. Сеть подзагадит. но мы же ради "красиво"

А еще из "дельных" советов, может вам взять какую-то LPC с 2 ядрами, типа
http://www.nxp.com/products/microcontrolle...tex_m4/lpc4300/
пусть одно ядро езернет разгребает, и со вторым связь быстрая, которое всю работу будет делать...

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

Хмм.. Надо будет обдумать, действительно, можно будет запретить бродкасты на 2м, наверное. Спасибо.
А вот я как раз тоже нашел 2х ядерный LPC4337 и его рассматриваю.
На эту замену согласятся проще всего. Радио часть у нас уже разведена, и проходить опять всякие американские FCC сертификации начальство боится как огня.
Так что с биглбон может и невыгореть..
Сегодня последний день, вернусь из отпуска буду 2х ядерный щупать..

[SM]

Хмм.. Надо будет обдумать, действительно, можно будет запретить бродкасты на 2м, наверное. Спасибо.

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

[Golikov A.]

это как заплатка-костыль к текущему варианту. поставить 2 одинаковые платы и поправить софт. Как боевое решение переход на 2 ядерный, который ТС и смотрит. 4300 - это шустрые, 4000 были 2 ядерные чуть проще, может дешевле, если вдруг...

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

[SM]

это как заплатка-костыль к текущему варианту.

И зачем делать заплатку, когда можно просто умощнить текущий вариант, перейдя на ядро с нужным запасом производительности?

[A. Fig Lee]

И зачем делать заплатку, когда можно просто умощнить текущий вариант, перейдя на ядро с нужным запасом производительности?

Слишком мощный пока пугает, надо добавлять ему флаши и прочее. Будет запасной вариант после LPC4337.
Уже заказал LPC4337

[AlexandrY]

В итоге периодически затыкается контроллер, так как есть и другие задачи.

Значит либо не применяете, либо неправильно применяете RTOS.
И почему у вас MAC не может послать Pause frame если поток слишком плотный?
STM-ы это уже как бы давно могут.

[A. Fig Lee]

Значит либо не применяете, либо неправильно применяете RTOS.
И почему у вас MAC не может послать Pause frame если поток слишком плотный?
STM-ы это уже как бы давно могут.

Применяем. Значит, неправильно. А как правильно?
2. Эту опцию не ковырял. А она поможет? Данные то нужные, другой вопрос, что предназначены не мне.
Ну заткну я источник этой опцией, а получатель данных куковать без них будет? Время поступления данных критично.
Пересылать их не нужно, слишком поздно.

[AlexandrY]

Пересылать их не нужно, слишком поздно.

Сомневаюсь что-то. Сеть 100BASE-T не разрабатывалась для реального времени.
Если кто-то ее загрузил под 100% значит заведомо уже работает не в реалтайме и с потерями.

Pause frame работает до первого свитчера. Так, что всю сеть не затормозит.

В RTOS нужно правильно настроить планировщик.
А как именно, не скажу.
Во первых надо знать возможности планировщика, во вторых надо знать весь состав задач и их время выполнения.
А потом уже раскидать по приоритетам и кольцам.

[doom13]

2) Есть мысль в следующих версиях пользовать самому UDP бродкаст для автоматического нахождения своих устройств в сети.

Может я где-то что-то упустил, но я не понимаю какой "UDP бродкаст" Вы хотите использовать для определения устройств в сети. Для определения адресов устройств в сети (сопоставления IP и MAC нужного устройства, формирования ARP-таблицы) используется ARP (запрос-ответ) далее качество приёма-передачи проверяет ICMP. Если пингануть какое-то устройство (какой-то IP), то увидим именно эти протоколы.
Кто такой "UDP broadcast", откуда Вы взяли это понятие?

Хмм.. Надо будет обдумать, действительно, можно будет запретить бродкасты на 2м, наверное. Спасибо.

Каким образом можно запретить бродкасты?


Поясните пожалуйста, что за данные предаются по UDP с использованием broadcast MAC-адреса? Никак не могу понять смысл данного решения? Какие в нём могут быть преимущества и в чём же такая необходимость?

[A. Fig Lee]

Может я где-то что-то упустил, но я не понимаю какой "UDP бродкаст" Вы хотите использовать для определения устройств в сети. Для определения адресов устройств в сети (сопоставления IP и MAC нужного устройства, формирования ARP-таблицы) используется ARP (запрос-ответ) далее качество приёма-передачи проверяет ICMP. Если пингануть какое-то устройство (какой-то IP), то увидим именно эти протоколы.
Кто такой "UDP broadcast", откуда Вы взяли это понятие?

Объясняю. ARP это не то, это когда известен IP и нужно определить MAC. А когда IP неизвестен?
Посылается бродкаст UDP пакет на определенный порт с информацией "я Вася Пупкин, ищу брата Федю, отзовись, мой IP a.b.c.d"
Программа узнает пакет и отвечает по IP.
"Откуда взял", не помню, я уж больше 15и лет со всем этим хозяйством. Да хоть RFC почитайте, я ссылку приводил.
Посмотрите как Apple свои устройства в сети определяет.

Каким образом можно запретить бродкасты?

Поясните пожалуйста, что за данные предаются по UDP с использованием broadcast MAC-адреса? Никак не могу понять смысл данного решения? Какие в нём могут быть преимущества и в чём же такая необходимость?

Виноват, не точен. Можно запретить прием бродкастов/мултикастов на уровне ethernet controllera.

Данные реального времени, идет поток с датчиков. О другой части, кто принимает эти сигналы, они ничего не знают.
Поэтому и UDP broadcast.

[jcxz]

А, просто, поставить более мощный процессор? Не с 72 МГЦ, а, например, с 720 МГЦ ? Или свет клином именно на этом сошелся?

Только вот беда-то - как-же другим устройствам жить??? Которым не посчастливилось оказаться в одной сети с этим говорливым поделием...
Ведь оно завалит теперь всех в сети своими броадкастами...
Если в этой организации в сети имеются и другие изделия на маломощных CPU, их разработчикам тоже прикажете заменять CPU на более мощный чтоб в чужом кале не утонуть?

Объясняю. ARP это не то, это когда известен IP и нужно определить MAC. А когда IP неизвестен?

Не обязательно. ARP может использоваться и для других целей.
Например у себя в изделии я использую его для проверки занятости IP-адреса. Это ещё одна возможность ARP.
Достаточно поставить IP-источника = 0.
Не знаю, но наверное можно и адрес назначения поставить в 0, тогда никто случайный на Ваши ARP-кадры не ответит.
А когда IP неизвестен, для этого есть другой протокол: RARP. Почитайте про него.

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

За 15 лет Вы могли-бы найти время и прочитать про ARP/RARP всё

[Golikov A.]

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

Если почитать внимательно, станет понятно следующее
1. Сеть UDP brodcastami грузит не устройство ТС, а внешние устройства, чужие, которые не переделаешь, с этим просто надо жить.
2. Устройство ТС не успевает жевать бродкасты потому что занято другими делами помимо Ethernet

Зачем столько жевать что сделано не верно, если это изменить нельзя? ЧУЖИЕ устройства так сделаны, и в такой сети надо просто выживать.

3. Когда оцениваете 15 летний опыт, хорошо бы затратить хотя бы 15 минут своего времени на разбор задачи.
ARP и RARP дают вторую часть пары IP - MAC, когда известна первая.
То есть зная MAC можно получить IP, зная IP можно получить MAC.

Теперь вопрос к клубу "знатаков" как узнать IP и MAC одновременно?

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

П.С. Сети бывают разные, у нас есть сеть приборов компьютер и несколько девайсов. Она отрезана от внешнего мира, а внутри происходит полная вакханалия, но это сделано осознано, потому что так она лучше масштабируется и управляется. Ее можно было сделать вообще на сыром Ethernet без IP, но это неудобно для компьютера, потому в ней ТСР/IP. Но сеть изначально предполагалась выделенной, чтобы в ней никого другого не было.

Это примерно как вилка на 12 вольтовом приборе, которую можно в 220 запихать. Наличие такой вилки не означает что ее надо пихать в 220, это означает что человек хотел использовать стандартные розетки, в своей 12 вольтовой цепи и все.

[doom13]

Объясняю. ARP это не то, это когда известен IP и нужно определить MAC. А когда IP неизвестен?
Посылается бродкаст UDP пакет на определенный порт с информацией "я Вася Пупкин, ищу брата Федю, отзовись, мой IP a.b.c.d"
Программа узнает пакет и отвечает по IP.
"Откуда взял", не помню, я уж больше 15и лет со всем этим хозяйством. Да хоть RFC почитайте, я ссылку приводил.
Посмотрите как Apple свои устройства в сети определяет.

Вот это (нигде, правда, не встречал) может быть применимо. Тут нет потока данных с broadcast, которые глушат всё остальное. Послали/приняли пару broadcast сообщений и перешли в нормальный режим. Никого не повесили.

Данные реального времени, идет поток с датчиков. О другой части, кто принимает эти сигналы, они ничего не знают.
Поэтому и UDP broadcast.

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

Виноват, не точен. Можно запретить прием бродкастов/мултикастов на уровне ethernet controllera.

Тут ещё раз расскажите, что значит "на уровне ethernet controllera"? На уровне PHY? На уровне MAC?
На сколько известно мне - приём broadcast запретить нельзя!!!

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

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

[AlexandrY]

На сколько известно мне - приём broadcast запретить нельзя!!!

Да ну!

А как вам там с ШИМ-ом получается?
Удалось застабилизировать spread spectrum?

Лучше читайте документацию!

[jcxz]

Если почитать внимательно, станет понятно следующее
1. Сеть UDP brodcastami грузит не устройство ТС, а внешние устройства, чужие, которые не переделаешь, с этим просто надо жить.

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

2. Устройство ТС не успевает жевать бродкасты потому что занято другими делами помимо Ethernet

Не знаю как так можно занять 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 находящееся в достаточно большой корпоративной сети.

[doom13]

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

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

Если почитать внимательно, станет понятно следующее
1. Сеть UDP brodcastami грузит не устройство ТС, а внешние устройства, чужие, которые не переделаешь, с этим просто надо жить.
2. Устройство ТС не успевает жевать бродкасты потому что занято другими делами помимо Ethernet
Зачем столько жевать что сделано не верно, если это изменить нельзя? ЧУЖИЕ устройства так сделаны, и в такой сети надо просто выживать.

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

3. Когда оцениваете 15 летний опыт, хорошо бы затратить хотя бы 15 минут своего времени на разбор задачи.
ARP и RARP дают вторую часть пары IP - MAC, когда известна первая.
То есть зная MAC можно получить IP, зная IP можно получить MAC.
Теперь вопрос к клубу "знатаков" как узнать IP и MAC одновременно?

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

Понаделают таких поделок, а потом у нас ракеты падают, говорят саботаж... Да я согласен - такой подход САБОТАЖ!

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

Да ну!

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

А как вам там с ШИМ-ом получается?
Удалось застабилизировать spread spectrum?

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

[AlexandrY]

Загрузка CPU при этом (в целом, там почти ничего нет только uCOS крутится, да снифер инфу о потоке в UART выводит) составляет 0.8 ... 1.0 %.
И где я не прав?

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

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

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

[jcxz]

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

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

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

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

[AlexandrY]

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

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

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


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

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

[jcxz]

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

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

[doom13]

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

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

[AlexandrY]

Если-б что-то терялось и не отображалось ...
А она даже при тестовом TCP-потоке (по двум сокетам одновременно) максимум до 7% доходит.

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

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

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

[Golikov A.]

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

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

по производственной необходимости оказалось наше устройство на STM32F107 и
много других, которые шлют UDP broadcast

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

Вы всегда были за надёжность и качество устройств

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

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

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

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


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

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

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

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

[doom13]

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

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

На сколько известно мне - приём broadcast запретить нельзя!!!

Да ну!

[jcxz]

Возмем реалистичный 70 Mbit поток по Ethernet. Это 8 Мбат в сек данных.

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

[doom13]

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

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

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

[A. Fig Lee]

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

Если почитать внимательно, станет понятно следующее
1. Сеть UDP brodcastami грузит не устройство ТС, а внешние устройства, чужие, которые не переделаешь, с этим просто надо жить.
2. Устройство ТС не успевает жевать бродкасты потому что занято другими делами помимо Ethernet

Зачем столько жевать что сделано не верно, если это изменить нельзя? ЧУЖИЕ устройства так сделаны, и в такой сети надо просто выживать.

3. Когда оцениваете 15 летний опыт, хорошо бы затратить хотя бы 15 минут своего времени на разбор задачи.
ARP и RARP дают вторую часть пары IP - MAC, когда известна первая.
То есть зная MAC можно получить IP, зная IP можно получить MAC.

Теперь вопрос к клубу "знатаков" как узнать IP и MAC одновременно?

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

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

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

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


Да ну!

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

[doom13]

Молодежь!

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

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

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

[WitFed]

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

Данные реального времени, идет поток с датчиков. О другой части, кто принимает эти сигналы, они ничего не знают. Поэтому и UDP broadcast.

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

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

[WitFed]

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

[kolobok0]

...что такое есть "затык" ? Зависание ядра, потеря важного пакета, неотработка чего-то вовремя ?..

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

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

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

[jcxz]

Мой тоже успевает. Почти. Но гдето раз в сутки в итоге очередь таки заполняется.

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

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

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

[kolobok0]

...Это называется "flowcontrol". ..

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

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

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

[A. Fig Lee]

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

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

[jcxz]

Да, в прерывании идет копирование пакета.

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

[A. Fig Lee]

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

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

[jcxz]

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

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

[kolobok0]

Я конечно не знаком с Ethernet-контроллером STM...

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