Принять и ПАРАЛЛЕЛЬНО распарсить поток 10Гбит/с. Как решаются такие задачи? Опции

[Студент заборстр...]

Поясню.
По езернету принимаем данные об состоянии 1000 ОДИНАКОВЫХ распределенных устройств на скорости 10 Гбит/с по оптоволокну, обрабатываем и формируем "ответку". Которую тоже передаем по оптоволоку на 10Гбит/с
Т.к. устройства одинаковые, то алгоритм работы и логика обработки дампа от каждого устройства одинакова.

Отсюда возникает желание обрабатывать все дампы ПАРАЛЛЕЛЬНО.

Отсюда в голове появляется слово "ПЛИС".

Но возникает вопрос "Как?"

Я вижу это так. Есть память. Допустим 1 Мегабайт.
В эту память пишем принятые дампы из принятых пакетов, из неё же грузим данные в пакеты.
Тут пока ничего не обычного.

Необычное начинается тут:
Память должна быть разбита на 1000 сегментов и доступ к каждому сегменту должен быть возможен НЕЗАВИСИМО от других
ПЛИСина должна читать из 1000 дампов/сегментов ОДНОВРЕМЕННО и обрабатывать 1000 потоков параллельно и потом формированные данные 1000 потоков параллельно: каждый узел обработки пишет, читает собрабатывает свой дамп.

Пруфит? Увеличение скорости реакции в 1000 раз по сравнению с последовательной обработкой на MCU


Я объяснил несколько шероховато, поскольку не специалист по ПЛИС.

Меня интересует это реализуемо на ПЛИС.
И есть ли такая память, которая позволяет использовать её одновременно как единый блок и как совокупность дампов с независимым доступом к каждому дампу?

Т.е. при сериализации/десериализации память используется как неделимый блок.
А при обработке данных в памяти она должна использоваться ПЛИСиной как набор из 1000 независимых дампов с независимым доступом.

Такое есть в природе?

Или описанные мной задачи решаются как-то иначе?

Просто обычный MCU даже i7 не успеет обработать поток 10Гбит/сек (а есть мысли сделать даже 100Гб/с).
Нужно как-то распараллеливать обработку

А как?

Сообщение отредактировал Студент заборстроительного - Dec 23 2017, 11:07

[Inanity]

Студент заборстроительного...
1. Что значит 10Gb? Если это просто скорость линка, то можно на 10Gb 1 килобайт принять, 3 часа обрабатывать и снова на тех же 10Gb передать. Т.е. линк получается 10Gb, а эффективная пропускная способность 1килобайт в 3 часа. Чувствуете разницу? Если нет, то проконсультируйтесь с человеком из вашей команды, который понимает, что происходит.

2. Предположим, что вы определили, что на линке 10Gb к вам приходит поток данных в 500Мбайт/сек (для примера). Для решения задачи нужно понимать суть алгоритма обработки. А именно, каковы требования по памяти, какова глубина конвейера. Исходя из этих данных уже более-менее можно будет прикинуть по ресурсам можно ли это сделать на ПЛИС, какие потребуются ресурсы, чтобы обработка на ПЛИС не стала "горлышком от бутылки" в потоке данных.

Уже третья страница пошла, а вы никак не можете толком сформулировать задачу.

[Студент заборстр...]

Студент заборстроительного...
1. Что значит 10Gb? Если это просто скорость линка, то можно на 10Gb 1 килобайт принять, 3 часа обрабатывать и снова на тех же 10Gb передать. Т.е. линк получается 10Gb, а эффективная пропускная способность 1килобайт в 3 часа. Чувствуете разницу? Если нет, то проконсультируйтесь с человеком из вашей команды, который понимает, что происходит.

Вы думаете я совсем дурак?
Вы думаете, что я просто так написал, что даже i7 захлебнётся от такого потока?

Ещё раз.
Допустим данные вы нарезаете блоками по 46 байт в кадры.
Эти кадры передаёте по линку 10Gb/s.
И скорость поступления кадров будет 10Gb/"размер кадра" (разделить).
...
С вашей задачей ситуация аналогичная.
Скорость 10Gb/s - это скорость бит в линии.
Но общаетесь то вы кадрами. И обрабатывать должны кадры.

Откуда у вас 1000 потоков взялось ?

А почему 46, а не 1500?
Так что "КПД" канала у меня более 90%
А про 1000 потоков уже объяснял, что данные представляют собой данные 1000 ОДИНАКОВЫХ устройств, которые нужно обрабатывать ОДИНАКОВО

Сообщение отредактировал Студент заборстроительного - Dec 29 2017, 18:55

[krux]

Вы думаете я совсем дурак?

ничего личного, но начинает складываться такое мнение, да.

[Студент заборстр...]

ничего личного, но начинает складываться такое мнение, да.

Я же писал, что я нуб в ПЛИС. Никогда с ними дело не имел. Поэтому и тему создал, чтобы у спецов спросить, можно ли такое реализовать на ПЛИС. А Вы хамить.

Без разницы какой длины кадр.

Только при минимальной длине пакета "КПД" канал 4%, а при максимальной - 90%.
А Вы говорите "какая разница"

Вы принимаете 1GB в секунду, нужно его обработать и отправить обратно.
На работу с одним байтом можно выделить не более 1нс, с пакетом - N*1нс

Ну по самым грубым прикидками где-то так.
А я прикидывал так.
Каждое удаленное устройство описывается дампом в 64 байта.
Всего устройств - 1000.
Значит данные всех устройств занимают 64 000 байт
Скорость порядка 1 000 000 000 байт/сек
Значит скорость обновления инфы 64 000/1 000 000 000 = 64 мкс

Т.е. в дампы каждого из 1000 устройств каждые 64 мкс поступает очередная порция инфы объемом 64 байта
При обработке инфы полученной от устройства нужно анализировать не только последний 64-х байтный блок, но и 9 предыдущих.

Таким образом ты за 64 мкс должен обработать блок длиной 640 байт.
Казалось бы не много.
Но если обработку вести последовательно для всех 1000 устройств, то ты должен тратить на обработку 640-ка байтного блока: 64мкс/1000=64нс

Таким образом в среднем на обработку 1 байта нужно тратить не более 0,1 нс, а не 1 нс, как Вы посчитали.

А реально для улучшения точности и адекватности результатов нужно КАЖДЫЙ РАЗ анализировать не 10, а 100 последних блоков, плюс сравнить результаты с результатами других устройств.

Таким образом за 64 мкс ты будешь должен для каждого устройства перелопатить не 640 байт, а, как примеру 64 кбайта. Тогда чтобы успеть обработать данные всех 1000 устройств получается, что 1 байт ты должен обрабатывать за 0,001нс
А если сеть будет расти и будет не 1000 устройств, а 10000?
И сеть будет не 10G, а 100G?

Тогда я байт ты должен обрабатывать за 0,0001 нс

Даже при тактовой 5ГГц получается, что за 1/2000 такта нужно обработать 64 кбайта.
А даже при ширине шины 256 бит только чтобы прочесть 64 кбайт данных из ОЗУ потребуется минимум 2000 тактов

Сообщение отредактировал Студент заборстроительного - Dec 30 2017, 07:51

[Mad_max]

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

У вас на входе поток данных, каждые 6.4нс вы принимаете 8 байт данных по 10G.
Вы говорите, что блок обработчик данных имеет пропускную способность 10Мбит/c.
Посмотрите на зависимость данных в вашем алгоритме, можно ли обработку разложить
на N стадий последовательно идущих друг за другом. Если это так, то можно сделать
pipeline который будет работать на частоте потока данных 156Мгц.
Преимущество pipeline в том, что на каждом такте потребляется одна порция данных и
воспроизводиться одна порция данных. Работа идет на максимальной пропускной способности сети.
В таком случае, не надо ни чего параллелить, один инстанс ядра.

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

[Студент заборстр...]

Mad_max
Можно конечно поизвращаться с оптимизацией данного конкретного алгоритма.
А если придется изменить алгоритм - мне заново перепроектировать систему?
Это никуда не годиться
Я хотел бы получить УНИВЕРСАЛЬНУЮ "зубодробилку", работающую в 1000 потоков параллельно

Сообщение отредактировал Студент заборстроительного - Dec 30 2017, 09:45

[iosifk]

Mad_max
Можно конечно поизвращаться с оптимизацией данного конкретного алгоритма.
А если придется изменить алгоритм - мне заново перепроектировать систему?
Это никуда не годиться
Я хотел бы получить УНИВЕРСАЛЬНУЮ "зубодробилку", работающую в 1000 потоков параллельно

немного про оптимизацию...
До сих пор не сказано о том, как работают датчики.
Если имеется в виду большой физический объект, то обычно в разных ветвях алгоритма информация от датчиков имеет разное значение. Например выпущены ли шасси имеет смысл проверять только при взлете... Поэтому сомнительно, что все 1000 датчиков имеют равное значение по требуемому быстродествию... А это значит, что датчики можно разделить по группам и опрашивать с разной периодичностью...
Далее. Не сказано о взаимосвязи датчиков. Не бывает, чтобы алгоритм в одной какой-то ветви требовал полностью информацию обо всех 1000 датчиков. А это значит, что физически схему контроля датчиков можно разнести по разным физическим устройствам обработки. Ну, естественно, что часть датчиков будет обмолачиваться разными устройствами....
Ну и наконец, при таком большом количестве датчиков и большой "завязке" между ними в алгоритме, наверняка потребуется все разделить на две части. Одна будет только снимать информацию с объекта, а другая - ее обрабатывать...

[Студент заборстр...]

немного про оптимизацию...
До сих пор не сказано о том, как работают датчики.
Если имеется в виду большой физический объект, то обычно в разных ветвях алгоритма информация от датчиков имеет разное значение. Например выпущены ли шасси имеет смысл проверять только при взлете... Поэтому сомнительно, что все 1000 датчиков имеют равное значение по требуемому быстродествию... А это значит, что датчики можно разделить по группам и опрашивать с разной периодичностью...
Далее. Не сказано о взаимосвязи датчиков. Не бывает, чтобы алгоритм в одной какой-то ветви требовал полностью информацию обо всех 1000 датчиков. А это значит, что физически схему контроля датчиков можно разнести по разным физическим устройствам обработки. Ну, естественно, что часть датчиков будет обмолачиваться разными устройствами....
Ну и наконец, при таком большом количестве датчиков и большой "завязке" между ними в алгоритме, наверняка потребуется все разделить на две части. Одна будет только снимать информацию с объекта, а другая - ее обрабатывать...

Вот опять.
Мне в очередной раз предлагают подумать над тем как НЕ обрабатывать поток 10G в 1000 потоков..
Как используя разные грязные хаки, привязанные к данному конкретному случаю уменьшить объём вычислений в разы или даже на порядки.
А у меня задача сделать УНИВЕРСАЛЬНУЮ "числодробилку" без привязки как какому-то конкретному случаю. Без разных хаков, работающих только при определенных условиях.
Мне нужно, чтобы "числодробилка" могла использоваться в ЛЮБЫХ случаях, а не только в каких-то конкретных

А Вы, уважаемый, игнорируете просьбы предоставить более подробное описание ! Хотя это нужно было делать в первую очередь ! И это нужно Вам, а не нам...

Ну вот Вам картинка, как примерно должно всё выглядеть:


Сообщение отредактировал Студент заборстроительного - Dec 30 2017, 11:16

[RobFPGA]

Приветствую!

Вот опять.
...
А у меня задача сделать УНИВЕРСАЛЬНУЮ "числодробилку" без привязки как какому-то конкретному случаю. Без разных хаков, работающих только при определенных условиях.
Мне нужно, чтобы "числодробилка" могла использоваться в ЛЮБЫХ случаях, а не только в каких-то конкретных
...

В таком виде Ваша задача НЕ имеет ИНЖЕНЕРНОГО решения. Можно только фантазировать на тему ".. какой универсально длинный забор можно зафигачить чтобы огородить все ...".У Вас к сожалению полного понимания задачи пока не видно отсюда и метания от "кольцевой сетки микроконтроллеров" до "1000 устройств на 10G".
Обрабатывать realtime потоки >1 GByte/s сейчас не сложно ЕСЛИ четко ставить задачу что и как. Я делал несколько систем с потоковой обработкой 4-9 GByte/s и в каждом случае выбор железа делался только после анализа и оптимизации КОНКРЕТНЫХ алгоритмов.
А у Вас то

Т.к. устройства одинаковые, то алгоритм работы и логика обработки дампа от каждого устройства одинакова.

А через некоторое время уже другое

А реально для улучшения точности и адекватности результатов нужно КАЖДЫЙ РАЗ анализировать не 10, а 100 последних блоков, плюс сравнить результаты с результатами других устройств.

И если Вы не понимаете ОГРОМНУЮ разницу между двумя этими вариантами то реальной системы Вы так и не построите.
Поэтому начните с одной дощечки забора - опишите алгоритм обработки данных одного устройства с учетом всех требований и подумайте как и на чем можно его реализовать.

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

Удачи! Rob.

[Студент заборстр...]

В таком виде Ваша задача НЕ имеет ИНЖЕНЕРНОГО решения.

А в таком?

опишите алгоритм обработки данных одного устройства

Зачем?
Вы хотите взяться его реализовать?
Зачем Вы постоянно хотите увести тему в несущественные детали?

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

Я уже несколько страниц пытаюсь добиться от господ ПЛИСоведов ответа на один простой вопрос: можно ли в ОДНОЙ (!!!) ПЛИС создать 1000 схемных узлов так, чтобы, они читал/писали данные из общей оперативной памяти ОДНОВРЕМЕННО/ПАРАЛЛЕЛЬНО?

Всё.

[Александр77]

Зачем?
...
Зачем Вы постоянно хотите увести тему в несущественные детали?

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

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

Общим ответом в поставленном вопросе будет ссылка на сайты плисопроизводителей с указанием "ищите плис у которой будет не меньше 1000 блоков памяти (очень грубо смотрите по числу умножителей в плис)". Что касается тех деталей - чуть выше написал.

Я уже несколько страниц пытаюсь добиться от господ ПЛИСоведов ответа на один простой вопрос: можно ли в ОДНОЙ (!!!) ПЛИС создать 1000 схемных узлов так, чтобы, они читал/писали данные из общей оперативной памяти ОДНОВРЕМЕННО/ПАРАЛЛЕЛЬНО?

А есть ли вообще устройства, способные одновременно по одному каналу (шине данных) прочитать 1000 ячеек памяти с разными адресами? Если не ошибаюсь, то их нет, следовательно Вашу задачу, в такой постановке, не решить.

[iosifk]

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

А есть ли вообще устройства, способные одновременно по одному каналу (шине данных) прочитать 1000 ячеек памяти с разными адресами? Если не ошибаюсь, то их нет, следовательно Вашу задачу, в такой постановке, не решить.

Мне кажется, что прикол вообще не в этом.
представим себе физический объект с 1000 датчиков. Объект может быть 2-х типов.
1. Что-то вроде стенда для испытаний чего-то быстро-меняющегося, например плазмы... Тогда надо просто достаточно быстро записать данные по 1000 каналам в 1000 компьютеров и только потом их обрабатывать...
2. Речь идет об Объекте Управления. Которым надо рулить в реальном времени. Но тогда задается основной вопрос не о времени доставки сообщений, а о времени реагирования. И далее встанет вопрос об алгоритме управления и об исполнительных механизмах. Реальные механизмы - это доли секунд. К чему тогда разговоры о "нс"? А как ТС хочет реализовать алгоритм управления, если он заявляет, что устройство должно быть "универсальным" и не зависеть от "проекта"??? На аппаратной реализации языка Си??? Или еще каким либо образом.
3. А если это быстрое устройство, облепленное умными датчиками? А кто будет проводить согласование временных меток от датчиков? Ведь как не подстраивай часы в датчиках за "нс" они расползутся...
4. Теперь вопрос о сети... 1000 датчиков они где расположены? В прямой видимости? Или через свитчи? А свитчи тоже исказят время, если временной метки нет в пакете... Ну и так далее.

Вообще все это похоже на лохотрон. Ну скучно перед праздником... Вот и тема появилась потрепаться.... 1000 датчиков из памяти читать одновременно... Смешно и грустно...

[Студент заборстр...]

Мне кажется, что прикол вообще не в этом.
представим себе физический объект с 1000 датчиков. Объект может быть 2-х типов.
1. Что-то вроде стенда для испытаний чего-то быстро-меняющегося, например плазмы... Тогда надо просто достаточно быстро записать данные по 1000 каналам в 1000 компьютеров и только потом их обрабатывать...
2. Речь идет об Объекте Управления. Которым надо рулить в реальном времени. Но тогда задается основной вопрос не о времени доставки сообщений, а о времени реагирования. И далее встанет вопрос об алгоритме управления и об исполнительных механизмах. Реальные механизмы - это доли секунд. К чему тогда разговоры о "нс"? А как ТС хочет реализовать алгоритм управления, если он заявляет, что устройство должно быть "универсальным" и не зависеть от "проекта"??? На аппаратной реализации языка Си??? Или еще каким либо образом.
3. А если это быстрое устройство, облепленное умными датчиками? А кто будет проводить согласование временных меток от датчиков? Ведь как не подстраивай часы в датчиках за "нс" они расползутся...

Вы зря стараетесь меня "выудить" у меня детали ноу-хау нашей системы управления и "развести", чтобы я забесплатно устроил Вам ликбез по современным АСУТП. Хотя у меня ест чем возразить и дополнить по каждому из перечисленных Вами пунктов. Но я "калач тёртый". И на "слабо рассказать?" не ведусь

И повторяю Вас. Не надо пытаться научить меня как избежать необходимости принимать и обрабатывать в реалтайме поток 10G.
Я про эти способы прекрасно в курсе.

Поэтому давайте вернемся все же к теме: "Принять и ПАРАЛЛЕЛЬНО распарсить поток 10Гбит/с. Как решаются такие задачи?"

Вообще все это похоже на лохотрон. Ну скучно перед праздником... Вот и тема появилась потрепаться.... 1000 датчиков из памяти читать одновременно... Смешно и грустно...

Если Вам скучно - сходите на фишки.нет и петросян.ком.
А тут серьёзный технический форум

[Flip-fl0p]

Если Вы всё знаете зачем тогда спрашиваете ?

Поэтому давайте вернемся все же к теме: "Принять и ПАРАЛЛЕЛЬНО распарсить поток 10Гбит/с. Как решаются такие задачи?"

Задача имеет решение только если известно как в потоке замешаны данные ! Т.е надо знать как формируется поток !
Какой применяется алгоритм для обработки данных ?
Очень странно, что такой профессионал, как Вы, этого не понимаете !
Пока можно сказать что:
В некоторых FPGA есть трансиверы для приема/передачи потока 10Гбит/с, при имеющейся постановки задачи большего сказать нельзя.
Допустим Вы приняли поток 10Гбит/с. Распарсили его паралельно, обработали вашим супер-алгоритмом. Как вы данные будете обратно отдавать ?

Сообщение отредактировал Flip-fl0p - Dec 30 2017, 20:14