Кто нибудь использовал Ethernet в приложениях реального времени?
Необходимо не более чем за 1мсек передавать 1024 байта на простейшее исполнительное устройство - CPU и несколько цапов. Прога в виндах расчитывает данные для цапов и посылает пакет на сетевую карту, главное чтобы пакеты не терялись и задержка не превышала 1мсек. Увидел в инете такой вот Real-Time контроллер: http://www.prosoft.ru/products/brands/hilscher/374263/
Кто нибудь работал с таким? Можно ли вообще для такой задачи использовать встроенный в материнку сетевой контроллер совместно с CS8900A например? Посоветуйте, может есть (не)стандартные решения?

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

Буду слать в потоке. Пробовал с УСБ в балке получалось порядка 0,3мсек в лучшем случае, в худшем более 10. А изохорный даёт 2,5мсек. Поэтому и подумал про Ethernet. Да и драйвер к тому Real Time контроллеру поставляется под винды с компонентом.

А если взять мышкой окошко и пошевелить? Никакой поток не поможет. Будете свой драйвер писать? Только толку, сетевые протоколы то не real-time в винде...

Единственный способ - это заранее посылать пакеты из под винды, накапливать их в устройстве. А устройство должно говорить большому брату что у него близок к заполнению буфер, надо остановиться, и, соответственно, обратная ситуация. Т.е. отсчет миллисекундных тиков и точную выдачу берет на себя само устройство.

Ну и загруженность сети надо смотреть. Хотя, конечно, средняя скорость ~1МБайт/с - это вроде и не скорость...

Этого я больше всего и боюсь...



То что винда используется это к сожалению необходимость, как мне сказал програмист, алгоритм сложный и с ним справляется только топовый комп с 2-мя камнями. И скроее всего комп будет заточен только для прибора. В общем я пока оцениваю возможность передачи данных.
Хочу все же узнать, юзал ли кто Real time контроллеры? Стит ли их покупать?

А, простите, на "топовый комп с 2-мя камнями" становится только винда?

А если, то, что поставить будет называться просто "Линукс", то сразу только от самого этого факта свершится чудо

а какой отклик сейчас обеспечивает XP ? Там помоему не все так плохо, в NT4 таймер тикал раз в миллисекунду, другое дело что производительность Etherneta была около тысячи пакетов в секунду, правда тогда был ходовым 10 мегабитный Ethernet.

К сожалению, у нас пока нет людей умеющих работать и программировать под Линукс, поэтому остаётся только винда.


Я правда не спец в высоком программировании, но кажись порядка 16 мсек. это реакция на события виндой. (могу правда и ошибаться). Другое дело если делать поток. В потоке если что то делать, то вроде все происходит гораздо быстрее, но жутко не синхронно, как уже говорилось, шевеление окна мышой тормозило поток. Наверное как то можно повесить поток на отдельное ядро, тока пока непонятно как это сделать.
Проверял через queryperformancecounter. Оказалось что драйверы устройств имеют в большинстве приличный отклик, например драйвер для FTDI имел отклик порядка 0,35мсек. У CyUSB до 0,15мсек доходило. Думается у Etherneta может быть и быстрее. Остаётся заставить винду работать быстрее.
В инете видел что для реал тайм приложений есть надстройка для виндов - INtime 3.0, кто нибудь работал?

Вы ничего не поняли . Не сожалейте - ничего принципиально не изменится. Либо для Win, либо Linux так или иначе придется пробовать заниматься программированием сильнозоаточенных под Вашу задачу "драйверов". Поскольку любые приложения по любому идут лесом.

Советую прислушаться к словам Rst7. Ни в виндах, ни в линуксе вы не победите отсутствие реального времени и не добьетесь равномерной посылки пакетов. Выход- на приемной стороне делать буфер пакетов и уже оттуда выгребать равномерно на ЦАПы. Потребуется обратная связь на ПК в виде старт/cтоп управляющих пакетов по тому-же самому Ethernet.

Равномерной посылки мне добиваться и не нужно, главное обеспечить критерий: вермя м/у 2 пакетами < 1мс. Точной синхронизацией будет заниматься сам прибор.

Ну не гарантирует Вам в винде никто время между двумя пакетами < 1ms, можно надеятся, что 40 пакетов будут отправлены за время, существенно меньше 40 ms. Гарантировать можно, что 1000 пакетов отправятся быстрее 1000 ms.

ну не совсем так - для виды есть надстройка реал тайм гарантирующая доставки и время реакции - но это деньги и довольно приличные

но в целом вы правы
надо искать какоето другое решение для решения поставленной задачи с учетом ваших ресурсов
но надо уточнять постановку задачи
потому как просто пакеты отсылать это не задача или ее можно решить промежуточным железом которое будет это делать с необходимой точностью

обычно так и пытаются сделать, оптимально конечно читать ацп прямо драйвером Ethernet-а :-)

Вот провел тест, слал пакеты по 1024Б через CyUSB на УСБ в потоке, при этом считал время на посылку 1 пакета. На 2 Гига данных посланных в драйвер было насчитано 18-20! посылок со временем >1мсек, к сожалению из этих 18 были пакеты с задержкой и в 100мсек. Приоритет на поток был самым высоким, мышкой ничего не двигал, точнее сначала подвигал, потом устал. Интересно, есть ли у кого подобного плана статистика на ethernet драйвер? Или хотя бы время отклика?


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

Я плевал с внешнего устройства на PC пакеты по 504 байта через каждые 19 мс. Сниффер (Wireshark) показывал время между приходами пакетов 19+-3мс. Правда не могу утверждать насколько корректно он показывает время и на каком уровне его достает.

Ясно. Не густо, а это канал какой был? 10МБит?

Нет. 100 Мбит.

В этом случае следует отказаться от готовых компонентов и GUI в программе. Можно попробовать библиотеку драйверов WinCap. Я с ней работал на прием пакетов в составе снифера WireShark. Если отключить всякое графическое обновление в снифере, то он без пропусков принимает пакеты 1.5К, следующие с интервалом 7..8 мкс(микросекунд!). Если включить обновление графики в окне, то через примерно десяток пакетов, появляются паузы 1мс(миллисекунда). Это винды отбирают на GUI. В библиотеке есть возможность и отсылать пакеты,- я пробовал с Raw пакетами. Получилось. Но максимальную скорость отправки пакетов не проверял. Мне кажется, если на прием неплохо работает, то и на передачу есть неплохие шансы. Главное, отключить виндовое GUI.

Да легко вы сделаете этот "realtime"
На компе тупо шлете в сокет сколько влезает.
А в своем контроллере дайте Ethernet MAC подсистеме команду PAUSE на заданное время пока не готовы принять следующий пакет. По истечении времени комп сразу же прецизионно вышлет че у него там в буфере. От виндов это не зависит.
Естественно при этом, что ваш MAC должен поддерживать выдачу команд Pause.
И смотрите чтоб сетевая карта компа позволяла управлять параметрами Flow Control.
Т.е. управление потоком есть на физическом уровне Ethernet-а и голову ломать не надо.

А реальные realtime приложения на Ethernet-e борятся с коллизиями на линии которых в вашем случае видимо не будет.

Вы действительно не видите больше способа для синхронизации как слать пакеты с жестко определенными задержками? Не подойдет ли вам такой вариант - снабжать пакеты временными метками и порядковыми номерами и соотвественно собирать в небольшой буфер в вашем устройстве и анализировать.

Смысл иметь двое несинхронных часов? В компе и в железяке? Не лучше ли одни просто в железке?

А вот на фреймы pause я бы не закладывался.
Сегодня работает, а завтра попадется свич с неправильным бутстрепом и не будет он обрабатывать флоуконтрол. И начнутся танцы с бубном при луне. Лучше организовать свой флоуконтрол через тот же UDP.

Во, вот это мне уже нравится. В действительности GUI мне и не нужен. А можно по подробнее про WinCap? Интервал между пакетами сильно зависит от величины канала? По сути мне гигабит не нужен, думаю вообще 10М должно хватить. Драйвер работает со встроенными сетевухами или есть какие то ограничения? Вообще, спасибо за инфу, буду разбираться...


Да, действительно больше на линии сидеть никто не будет. Насчет Pause подумаю, я ещё правда не выбрал контроллер, так что приму на заметку, спасибо. Вообще в протоколах Ethernet тока начал разбираться, так что не ругайте, можно ли обойти физикой и маком и не организовывать стек? Валяется у меня платка на CS8900A хочу подрубить ее к Spartan 3, FPGA просто тупо будет выцеплять данные которые будут приходить с компа. По идее должно быть все как можно прощще, так вообще возможно?


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


Ну в компе таймера как такового нету, там стоит плата на которую поступают кадры с частотой 1 Кгц, плата кидает данные прямо в память, потом данные обрабатываются (около 100мкс) и отправляются в устройство.

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

Название я слегка перепутал, правильно Winpcap. Берут бесплатно здесь. Там же все хелпы и примеры. Очень просто делается обмен Raw-пакетами через обычные сетевые платы в ПК. Поскольку стек протоколов и сокеты виндов не используются, то вполне возможно, что Raw-пакеты удастся отсылать с гарантированным периодом 1mc.
Что же касается выбора контроллера на приемной стороне, то вам почти наверняка подойдет этот девайс, на котором легко делается обмен Raw пакетами вообще без всякого стека протоколов.

Большое спасибо всем за помощь, пока думаем в сторону RTX надстройки.