[krux 8]

используйте разбиение по 64 датчика, а не по 128,

и два езернета, а не один.

и всё у вас получится.

[blackfin 16]

используйте разбиение по 64 датчика, а не по 128,

и два езернета, а не один.

и всё у вас получится.

Пример для TSE:

This example uses a Nios II subsystem running the InterNiche TCP/IP stack to setup and tear down high speed UDP packet streams which are processed in hardware. The hardware UDP data streams are transmitted and received over the Altera TSE MAC at the maximum data rate achievable over the GbE network, this is over 1.48 million packets per second for minimum sized Ethernet packets and over 81.27 thousand packets per second for maximum sized Ethernet packets.

Считая, что максимальный размер пакета равен 1500 байт, находим скорость в битах: 8*1500*81270 = 975,24 Mb/s.

[Alex11 3]

NIOS вполне может справиться с таким потоком, но комп под виндой его не переварит. Если, конечно, не писать свой драйвер карточки. Дело даже не в скорости винчестера, просто прием UDP ограничен существенно меньшими цифрами. Мы пытлись передавать большой поток со своего устройства, которое могло генерировать все что угодно на гигабитную медь. Винда начинала рубить поток. Потом где-то нашли, что это какая-то политика безопасности (именно для UDP), и сделано специально, подробности не помню. Под линуксом было лучше существенно.

[zltigo 0]

Если, конечно, не писать свой драйвер карточки...

...просто прием UDP ограничен существенно меньшими цифрами

1)Драйвер и стек две разые сущности и соответственно "переписывая драйвер" ничего в собственно IP стеке не изменить.

2)Полагаю, что сталкивалитсь не с ограничениями на UDP, а на broadcast пакеты.

 

[blackfin 16]

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

Ну вообще-то, в природе существуют Ethernet карточки с двумя(!) 10GbE портами: Intel® Ethernet Converged Network Adapter X540-T2.

 

И раз их выпускают, значит кто-то умеет работать с фулл-дуплексными сетевыми потоками под 20 Gb/s..

 

Как-то так..

[dxp 34]

Пример для TSE:

 

Считая, что максимальный размер пакета равен 1500 байт, находим скорость в битах: 8*1500*81270 = 975,24 Gb/s.

Экая скорость у вас дикая получилось. С Mb не попутали? :)

 

У нас по UDP получилось что-то 957 Mb/s, что где-то почти 100% от полезной пропускной для этого протокола. Это по меди порядка 30 м.

 

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

[blackfin 16]

Экая скорость у вас дикая получилось. С Mb не попутали? :)

Попутал, конечно..

[zltigo 0]

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

Так вот именно в PC c его стеками проблема и есть. Поскольку соединение точка-точка на отдельную сетевую, то повесить на эту сетевую драйвер и на него уже прием фреймов самый простой и независимый путь. Да и если на меньших скоростях в общем потоке работать, то гнать IEEE 802.2 фрейм а не Ethernet II и вытаскивать через RAW без проблем. В противном случае придется на стороне контролера разные не нужные сущности добавлять, типа ARP и заголовков UDP/IP. Не сложно, но прото лишнее.

[RobFPGA 27]

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

 

У меня Win7 стек нормально пережевывал UDP с двух 10G каналов 1.1 GByte каждый. Так что с 100Mbyte справится.

Естественно для таких целей нужна приличная сетевая карточка.

 

ТС нужно для начала просто немного поэкспериментировать. Взять тот же iperf или что-то похожее и

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

Конечно работать впритык к макс лимиту стремно - всегда есть вероятность потерь пакетов даже при точка-точка - но тут уж TC виднее

какие требования к каналу.

Для снижения трафика можно также задумается над простым сжатием/упаковкой в передатчике раз там FPGA и так стоит -

10% сжатия - и 90MByte уже не так страшны и можно даже какой нибудь протокол натягивать поверх.

 

Успехов! Rob.

[zltigo 0]

Для снижения трафика можно также задумается над простым сжатием/упаковкой в передатчике раз там FPGA и так стоит -

10% сжатия - и 90MByte уже не так страшны и можно даже какой нибудь протокол натягивать поверх.

Да, это хорошее предложение.

 

У меня Win7 стек нормально пережевывал UDP с двух 10G каналов 1.1 GByte каждый.

И во что они "пережевывались" эти 2.2 гигабайта в секунду?

 

 

 

[RobFPGA 27]

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

 

И во что они "пережевывались" эти 2.2 гигабайта в секунду?

В кольцевой буфер памяти - это была тестовая машина я на ней отлаживал распаралеливание UDP трафика из FPGA на несколько 10G каналов и последующею сборку на приемной машине для записи.

В рабочей машине на базе Linux работает 4 10G канала в параллель - пишет поток до 4GByte на raid из 32 SSD.

 

Успехов! Rob.

[zltigo 0]

В рабочей машине на базе Linux работает 4 10G канала в параллель - пишет поток до 4GByte на raid из 32 SSD.

Спасибо! Понятно.

 

[prig 0]

...

1. На какую аппаратную базу в устройстве следует закладываться?...

 

2. Как под Виндой получать переданные данные? Понятно, что TCP, UDP можно получать

с помощью Winsock, а если протокол более низкого уровня, тогда чем? Тем же Winsock-ком?

 

Спасибо!

 

- Ориентироваться надо на синтезируемые MAC в ПЛИС.

При реализации PHY лучше сразу смотреть в сторону оптических модулей 1G SFP (модули под витую пару тоже можно прикрутить, но надо учитывать, что "вяжутся" они по SGMII).

То, что подается/принимается по дифф. парам оптического модуля SFP - это 1000BASE-X.

1000BASE-X можно получить прямо с ПЛИС (т.е. PHY, точнее PMA, на борту ПЛИС) или от чего-нибудь типа аляски 1111, подключаемой к ПЛИС по GMII.

Для реализации 1000BASE-X PMA на борту ПЛИС могут использоваться как скоростные трансиверы, так и трансиверы LVDS (тут надо смотреть конкретные модели конкретных производителей ПЛИС). Я бы предпочёл сразу ориентироваться на скоростные трансиверы.

Что-нибудь типа относительно недорогих Спартана-6 или Циклона-5 будет самое то.

 

 

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

Для Винды я бы таки ориентировался на UDP и 2 канала 1G с жёсткой привязкой к конкретному типу сетевой карточки на 2 порта.

В части UDP это имха. Будет проще с программерами.

В том, что касается 2 портов, полностью поддерживаю krux чисто из практических соображений:

 

используйте разбиение по 64 датчика, а не по 128,

и два езернета, а не один.

и всё у вас получится.

 

[dxp 34]

Так вот именно в PC c его стеками проблема и есть. Поскольку соединение точка-точка на отдельную сетевую, то повесить на эту сетевую драйвер и на него уже прием фреймов самый простой и независимый путь. Да и если на меньших скоростях в общем потоке работать, то гнать IEEE 802.2 фрейм а не Ethernet II и вытаскивать через RAW без проблем. В противном случае придется на стороне контролера разные не нужные сущности добавлять, типа ARP и заголовков UDP/IP. Не сложно, но прото лишнее.

Не так всё срашно на РС. Если у ТС стоит венда, то там с RAW сокетами не шоколадно, но вполне приемлемо делается на WSA сокетах. На линухе можно через RAW тащить хоть с MAC уровня, но смысла большого нет. Да, поднятие стека хотя бы до UDP требует некоторой возни, зато предоставляет возможность использовать всю сетевую инфраструктуру, что очень удобно и расширяемо. Выбор, конечно, за тем, кому реализовывать.

[jur 0]

 

Большое спасибо, друзья, вы мне здорово помогаете!

 

Заметно продвинулся в плане понимания проблем, возникающих в ходе работы над поставленной задачей. Попутно пришло осознание, что телепатия, телепортация, левитация - это не просто фантазии. Не знаю насчет телепортации с левитацией, но телепатия точно есть! Иначе как объяснить, что слова уважаемого krux: "используйте разбиение по 64 датчика, а не по 128" попали ко мне в голову именно в тот же вечер, когда он об этом написал! :-)

 

В результате размышлений, ковыряния в Интернете, чтения различных документов у меня складывается следующая картина:

 

1. На стороне устройства поставить два канала Ethernet на 1 Гигабит каждый. Для этого использовать микросхему(ы) PHY или реализовать это дело в ПЛИС. Мы как раз используем микросхемы Cyclone V фирмы Altera. Нужно будет посмотреть, что получится проще. Возможно легче будет поставить одну/две микросхемы Ethernet PHY с SRAM-like интерфейсом. Что-то вроде этой: AX88180.

 

2. К микросхеме(мам) присоединить один/два адаптера для оптики, вроде Antaira SFP-M. Только нужно будет выбрать согласующуюся по интерфейсу пару PHY-оптика.

 

3. Для управления/конфигурации всего этого хозяйства поставить какой-нить незатейливый микроконтроллер. (Имею опыт работы с Атмеловскими 8-битными МК.)

 

4. На стороне компьютера поставить двухканальную плату Gigabit Ethernet с соответствующими оптическими согласователями.

 

Что касается программной части, то мне представляются такие варианты действий:

 

1. Использовать WinPcap для работы на уровне Ethernet-фреймов. Передавать блоки данных по 1 килобайту с добавлением необходимой информации о каждом блоке (типа, с какого датчика этот блок, коков его порядковый номер и т.п.). Такой вариант не представляет ни малейших проблем.

 

2. Добавить к передаваемой информации заголовки IP и UDP, тем самым превратив передачу в стандартную для Винды UDP/IP. Эти заголовки можно занести в ПЛИС при конфигурации. Можно даже реагировать на возможные ICMP-сообщения (наверное просто игнорируя их). Тоже сложностей не видно, однако позволяет работать в Винде чисто стандартными средствами. Это - плюс. Минус - это небольшое усложнение каналов передачи со стороны устройства. Это небольшой минус.

 

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

 

Покритикуйте/покомментируйте пожалуйста мои соображения.

 

Спасибо за помощь!

 

P.S. Если кто интересуется Windows 10 Insider Preview, то вышел Build 10576. Интересно, откликнулись ли они на многочисленные просьбы инсайдеров выбросить их идиотское упорядочивание All Apps по алфавиту? Счас проверю :-)