Jump to content

    

Какой протокол использовать поверх UDP или TCP

12 hours ago, :-) said:

. . . А чем плох непрерывный поток? . . . .

1. Лучше UDP, чем TCP. Хотя и TCP тоже норм.

2. Писать либо свой протокол, либо MQTT.

Да ничем он не плох. Смотря какого вида инф-я по нему прокачивается. Если "квант" данных потока умещается в один пакет - то проблем нет.

Если же поток - это ПОТОК (байтов) - то . . . . .  Получите "Ж".   "Ой, а этот байтик откуда (? куда), . . . Это канал связи глючный,  синхронизацию не держит "   :)

Для использования MQTT Вам потребуется евойный сервер, например mosquitto  (он есть как для Linux, так и в виде приложения на Win).

И Ваше 2-точечное соединение превращается в цепочку из 3 точек. Ну, это как вместо того, чтобы переложить данные с одного стола на другой (UDP, 2 point)

Вы "заводите" стол с секретуткой, и на этом столе есть 2 папки - одна для "поставщика", другая - для подписчик(ов). Секретутка никуда не ходит. Ее задача - переложить данные из "входящей" папки в "исходящую".

Так что не теряйте время, см. сокеты, UDP - датаграммы для процессора и для PC. Для компилятора PC никаких дополн. библиотек не надо - сокеты давно в "базовом" наборе. Примеров тоже море, в качестве "стартового" посмотрите исходник утилиты ping (раньше они шли в качестве стандартного примера).

Если C#  - то наверняка тоже есть компоненты для сетевой работы. Но в этом я пас.

 

 

Share this post


Link to post
Share on other sites

Протестил lwIP на MIMXRT1064 600 МГц с помощью iperf PC client
На BM с -O3 в TCM получается не более 70 Мбайт/сек

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

Share this post


Link to post
Share on other sites
2 hours ago, AlexandrY said:

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

или мост USB-fifo с параллельной (8 или 16) шиной без всяких Ethernet.

Share this post


Link to post
Share on other sites
20 часов назад, k155la3 сказал:

За целостность информации отвечает Ethernet и IP/UDP, поэтому даже генерировать - проверять CRC не надо. 

 

Пожалуйста, не вводите людей в заблуждение, IP / UDP не обеспечивают полноценного reliability. Для IPv4 даже UDP checksum - опция.

Даже если ОС или приложение реализует механизм проверки checksum - не прошедшие проверку пакеты будут просто отброшены (без повторной передачи).

А в случае высоких нагрузок (80 MBit/s как раз такой случай) и слабого железа, скажется отсутствие network congestion у UDP.

Потери пакетов превысят все разумные пределы. 

Вот почитайте на досуге - https://habr.com/ru/post/250227/

2 часа назад, AlexandrY сказал:

Протестил lwIP на MIMXRT1064 600 МГц с помощью iperf PC client
На BM с -O3 в TCM получается не более 70 Мбайт/сек

Что и требовалось доказать.

123.jpg

Share this post


Link to post
Share on other sites
2 minutes ago, psyhologic said:

Что и требовалось доказать.

Сорри, ошибся. 

70 Мбит/сек (не мегабайт!) - это скорость приема по TCP микроконтроллером.
А скорость передачи по TCP у меня получилась 95 Мбит/сек.  Но у меня 100Base-T под рукой только. 
Так что можем обсуждать дальше. 

Так кто там предложит парсер JSON под ARM Cortex, чтоб он отъел не больше 10% производительности TCP стека?    
И желательно с пруфами. 

Share this post


Link to post
Share on other sites
12 минут назад, AlexandrY сказал:

Сорри, ошибся. 

70 Мбит/сек (не мегабайт!) - это скорость приема по TCP микроконтроллером.
А скорость передачи по TCP у меня получилась 95 Мбит/сек.  Но у меня 100Base-T под рукой только. 
Так что можем обсуждать дальше. 

Так кто там предложит парсер JSON под ARM Cortex, чтоб он отъел не больше 10% производительности TCP стека?    
И желательно с пруфами. 

Здесь ещё множество подводных камней скрыто.

В случае TCP они разруливаются на уровне самого протокола.

Например, TCP остановит передачу, пока получатель не обработает предидущую порцию данных и не пришлёт ACK.

Даже если "квантировать" UDP payload (как было предложено выше), чтобы уместить его в один UDP пакет.

Где гарантии того, что пока получатель будет парсить / обрабатывать payload на слабом железе, не прилетят ещё 1000 UDP пакетов,

из которых 500 попадут в буферы ОС, а остальные будут просто отброшены. 

Это допустимо в некоторых архитектурных сценариях - ММО сервера, видео поток, etc ... 

Share this post


Link to post
Share on other sites
1 minute ago, psyhologic said:

Даже если "квантировать" UDP payload (как было предложено выше), чтобы уместить его в один UDP пакет.

А кто тут обсуждает UDP? 
UDP по любому требует еще какого-то протокола сверху.
TC же интересуется конечным прикладным протоколом. 

И ответ в том, что интересоваться надо на его месте не протоколом, а фреймворком. Потому что их готовых навалом. 

Share this post


Link to post
Share on other sites
Только что, AlexandrY сказал:

А кто тут обсуждает UDP? 
UDP по любому требует еще какого-то протокола сверху.
TC же интересуется конечным прикладным протоколом. 

И ответ в том, что интересоваться надо на его месте не протоколом, а фреймворком. Потому что их готовых навалом. 

ИМХО не стоит изобретать велосипеды, час программиста стоит ~35$

Надо менять архитектуру, ужимать поток до вменяемого и использовать стандартные / общепринятые протоколы типа MQTT.

У нас, "славян" прямо беда какая-то с излишней самодеятельностью / изобретательностью, которая потом часто выливается в "горе от ума" ...

Share this post


Link to post
Share on other sites
1 hour ago, psyhologic said:

Надо менять архитектуру, ужимать поток до вменяемого и использовать стандартные / общепринятые протоколы типа MQTT.

Я не понял, вроде сошлись, что  MQTT не прикладной протокол, сверху также что-то надо лепить как и для UDP.
Так к чему его поминать?
Час же  программиста стоит ~35$ ! :biggrin:

Share this post


Link to post
Share on other sites
5 hours ago, psyhologic said:

Пожалуйста, не вводите людей в заблуждение, IP / UDP не обеспечивают полноценного reliability. Для IPv4 даже UDP checksum - опция.

Даже если ОС или приложение реализует механизм проверки checksum - не прошедшие проверку пакеты будут просто отброшены (без повторной передачи).

А в случае высоких нагрузок (80 MBit/s как раз такой случай) и слабого железа, скажется отсутствие network congestion у UDP.

 

Не знаю, что такое reliability, я против него "ничего не имею". Но нагло предполагаю что для задачи ТС ОНО и ненадо. А опция потому, что это  уже обеспечивается аппаратно, на уровне фреймов физ. уровня, Ethernet CRC32 (или что там сейчас на гигабит, не заю). Соответственно, гонять дополнительные CRC по сети становится "наблюдением за наблюдающим". На прикладном уровне - пожалуйста, проверяйте сколькоугодно, если времени не жалко.

Какое "слабое железо" ?  Перечитайте внимательно ТУТ, речь идет о соединении ПК и контроллера с Ethernet напрямую или через коммутатор.

Какие "Потери пакетов . . . " ? Где ? в куске провода от ПК до контроллера или в свиче ?

Все "потери" при таком соединении - в кривом софте или неправильно выбранном тех. решении, когда кнопочки в 3D, а "не работает, наверное свич глючный".

 

Share this post


Link to post
Share on other sites
On 2/3/2019 at 5:54 PM, AlexandrY said:

И ответ в том, что интересоваться надо на его месте не протоколом, а фреймворком. Потому что их готовых навалом. 

Google по фразе " Run-Time Debugging Tool " вывел на FreeMASTER Run-Time Debugging Tool. Ещё посмотрел на ucProbe. Интересные штучки, не знал о таком. В принципе половину задачи они могут помочь решить. Одна из целей действительно посмотреть как что-то крутится в некоторой программе управления в режиме реального времени. И такими штуками это, как будто, красиво получается.

Но есть ещё одна подзадача - это передача тестовых воздействий с ПК в устройство. (Вернее программа на Cortex-a9 должна будет передать данные в память ПЛИС и далее считать результат обработки и сравнить с тем, что должно быть. А всё крутится на Zynq7000). Может, для такого тоже есть что-то готовое? Для изучения и вдохновения...

 

23 hours ago, k155la3 said:

Не знаю, что такое reliability, я против него "ничего не имею". Но нагло предполагаю что для задачи ТС ОНО и ненадо. А опция потому, что это  уже обеспечивается аппаратно, на уровне фреймов физ. уровня, Ethernet CRC32 (или что там сейчас на гигабит, не заю). Соответственно, гонять дополнительные CRC по сети становится "наблюдением за наблюдающим". На прикладном уровне - пожалуйста, проверяйте сколькоугодно, если времени не жалко.

Какое "слабое железо" ?  Перечитайте внимательно ТУТ, речь идет о соединении ПК и контроллера с Ethernet напрямую или через коммутатор.

Какие "Потери пакетов . . . " ? Где ? в куске провода от ПК до контроллера или в свиче ?

Все "потери" при таком соединении - в кривом софте или неправильно выбранном тех. решении, когда кнопочки в 3D, а "не работает, наверное свич глючный".

 

В общем-то тоже придерживаюсь мнения, что потерь быть не должно. Впрочем потеря пакетов допустима и вряд ли сильно помешает. UDP или TCP - это, скорее, для упрощения реализации программы на ПК. (Можно, наверное, и до голых Ethernet-кадров опуститься. В 1,5 кБ должны умещаться отдельные кванты телеметрии).

 

On 2/3/2019 at 6:05 PM, psyhologic said:

ИМХО не стоит изобретать велосипеды, час программиста стоит ~35$

Надо менять архитектуру, ужимать поток до вменяемого и использовать стандартные / общепринятые протоколы типа MQTT.

У нас, "славян" прямо беда какая-то с излишней самодеятельностью / изобретательностью, которая потом часто выливается в "горе от ума" ...

Так вот я и пытаюсь разобраться какие протоколы существуют и их пригодность. MQTT пугает каким-то непонятным слоем брокер. Вроде бы, для моей задачи ненужная штука. Я уже выше приводил пример альтернативного протокола: Constrained Application Protocol. Он поверх UDP реализуется. И не содержит никакого брокера.

 

ЗЫ Вообще, конечно, чувствую, что изобретаю какой-то велосипед...

Share this post


Link to post
Share on other sites
1 hour ago, :-) said:

(1). . .  Одна из целей действительно посмотреть как что-то крутится в некоторой программе управления в режиме реального времени. . . . 

. . . Может, для такого тоже есть что-то готовое? Для изучения и вдохновения...

(2) ЗЫ Вообще, конечно, чувствую, что изобретаю какой-то велосипед...

(1) Если для Вас не очень принципиально использование именно Ethernet - посмотрите USB3 у Cypress - не хуже 1G  :)

Я делал на старом ихнем чипе CY7C68013 устр-во с подобной задачей - контроллера "отстреливал" в fifo образ RAM блоком 64кбайт.

Если Вы "снизойдете" до 12 Мслов/с (8 или 16 разрядов) то можете использовать и его. Недостаток - параллельный интерфейс.

Достоинство - есть готовые недорогие модули. как ТУТ

(2) делая "лисапет" экономим как минимум 200 долл. на ките. Учитывая специфичность задачи и возможность расширения - намного больше.

Если кит за счет фирмы - грех не воспользоваться. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this