Как быстро передавать данные через Ethernet, Поток данных порядка 100+ мбайт/сек Опции

[jur]

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

Никогда на практике не сталкивался с передачей данных по сети Ethernet. И вот...

Задача довольно простая. Имеется устройство (нашей разработки), которое с помощью
ПЛИС снимает данные со 128 датчиков. Затем эти данные нужно передать в компьютер
для последующей обработки.

Имеется два основных требования, которые ставят меня в тупик:

1. Скорость поступающих данных 100+ мбайт/сек. (не мбит!).
2. Расстояние от устройства до компьютера 100-300 метров.
3. Соединение типа точка-точка.

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

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

На компьютерной стороне у заказчика стоит PC с Виндой. Мне нужно будет написать
простую DLL-ку, которая примет поток данных и положит их куда прикажут (в файл на диск,
запихнет в Memory Mapped File и т.п.).

Исходя из вышеизложенного имеются следующие вопросы:

1. На какую аппаратную базу в устройстве следует закладываться? Видимо примененная
микросхема продиктует требуемый протокол передачи? Наверное устройства вроде W5300
фирмы WIZnet не подойдут по скорости, а другие не имеют аппаратной реализации TCP, UDP?

2. Как под Виндой получать переданные данные? Понятно, что TCP, UDP можно получать
с помощью Winsock, а если протокол более низкого уровня, тогда чем? Тем же Winsock-ком?

Спасибо!

[jur]

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

Заметно продвинулся в плане понимания проблем, возникающих в ходе работы над поставленной задачей. Попутно пришло осознание, что телепатия, телепортация, левитация - это не просто фантазии. Не знаю насчет телепортации с левитацией, но телепатия точно есть! Иначе как объяснить, что слова уважаемого 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 по алфавиту? Счас проверю :-)