Вопрос.
Есть GigaBit Ethernet. Соединение точка-точка.
В одну сторону необходимо передать большой поток, в другую очень маленький.
Расстояние 10-20 м.
Источник большого потока ПЛИС с физическим уровнем.
Приемник - средний компьютер с GigaBit Ethernet.
Чем будет обусловлена минимальная скорость передачи большого потока?
Интересуют аппаратные ограничения

PS если тема поднималась, дайте пожалуйста ссылочку )

Какой-то странный вопрос...
Минимальная скорость - это ноль.
Уточните, что конкретно надо понять.

Есть соединение ПЛИС компьютер по ethernet.
Из ПЛИС необходимо гнать большой поток 700-900 Мбит/с.
Буферизировать его негде.
Интересно какую стабильную скорость можно получить.
И будет ли она всегда такой и выше.

Вы оцените, сможет ли компьютер принять такой поток и что он с ним будет делать.
GigaBit Ethernet полностью не определяет скорость передачи: буферы сетевой карты, драйверы карты, жесткий диск и т.д.

а чего бы не смог ? 100-125 Мегабайт в секунду при хардварных оффлоадах и джамбо фреймах для процессора не такая сложная задача, а вот что делать ? если писать на диск то нужно обеспечить такую скорость записи - современным ssd с правильной фс , справится очень даже хорошо

Необходимо на винчестер записывать поток 90-100 Мегабайт в режиме реального времени.
Можете по подробнее описать как можно этого достичь?
Или ссылку дать, где это можно посмотреть?

Сообщение отредактировал Tpeck - May 21 2011, 11:27

как уже сказали ssd диски.
либо несколько обычных hdd в RAID-0.
хотя 100 МБ на запись может быть и без raid'а с хорошим диском получить можно.

Аппаратные ограничения, как вам уже сказали, упираются в жёсткий диск и легко решаются.

А я бы вам рекомендовал ещё подумать про программные ограничения.
Из собственного опыта: винда на больших скоростях тупо теряет пакеты - т.е. часть из них не доходит до приложения, несмотря на устанавливаемые приоритеты потоков, использование как стандартных виндовых сокетов через WinAPI так и библиотеки WinPCAP.
Средняя скорость получается большая, но имеются дырки. Для решения проблемы нужно использовать протокол повторных запросов в случае потери пакета типа TCP.

Реализация быстрой записи на жёсткий диск в винде через свою программу на С++ тоже задача не из лёгких - придётся сильно попотеть с программными трюками.

Лучше для таких задач, которые используют большие потоки данных, подходит Линух.

А большие - это сколько? Почему это происходит?
Заранее спасибо.

У меня было около 60 МБайт/c - стояло ограничение по скорости передачи в ПЛИС.
В тестовых целях пакеты я никуда не записывал - просто проверял зашитый в них последовательно увеличивающийся номер.
Если запустить только одну программу принимающую трафик, повысить ей приоритет и не дышать, то потерь пакетов могло и небыть достаточно долгое время (пока скринсейвер не запуститься).
Запуск паралельно любого приложения приводил к периодических потерям (скажем раз в секунду) небольшого количества пакетов, что наблюдалось в виде нарушения их нумерации.

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

Размер пакета - 1500 Байт,
1G Ethernet точка-точка.

P.S. ось: WinXP
проц: Core2Dura
сетевуха: встроенная


P.S2. ПЛИС непрерывно выдавала пакеты с данными без запроса

после платы поставить свитч, после него - 2 или 4 компа. в пакетах по очереди подставлять следующий MAC-адрес. это может облегчить работу компам.

Можно попытаться сжать поток, если предположить что источник данных АЦП и сигнал каждую выборку не меняется большим скачком, то сжать данные можно практически на порядок. Тем более ПЛИС позволяет наворотить своё чего нибудь.
Второй вариант буферизовать данные на устройстве сбора в большое ОЗУ, и передовать на ПК на пониженной скорости.
Естественно использование хорошего RAID массива с Ethernet выглядит превлекательней, как самое простое решение.