Добрый день!

Понимаю всю обсурдность вопроса... но стоит задача - обеспечить передачу UDP пакетов в сеть с жестким интервалом 10мс.
Система только виндоуз и ничего кроме виндоуз. (Причины: драйвера, ПО, просто лень разработчиков изучать другие системы)
В общем, уговорить перейти на что-то более адекватное у меня не получается.

Какие есть варианты?

Мультимедия таймер не обеспечивает необходимой точности.
http://www.intervalzero.com/ - вроде бы то, что нужно. Но непонятно, сколько времени уйдет на освоение и сколько вообще это будет стоить.

Если подключить к COM порту контроллер, который будет каждые 10мс посылать сигнал, и роботать по прерыванию - может это как-то улучшить ситуацию?

Не каждому, а только топикстартеру. Это он так ставит задачу.

при чем здесь детерминизм? ну будет таймер давать импульсы с точностью ±1*10^(-10000000000000000000000000000000) секунд. и что дальше..... примет обычный линукс это событие.... но у него там ещё к примеру 100 фоновых задач... сколько времени пройдет от импульса до выхода первого байта из порта? Если постучать бубном над приоритетами в линуксе, то можно назначить приоритет задаче отправляющей запрос (как в винде), но все равно, задача по отправке запроса получит больший слот времени, но не все 100% и время от прерывания до выхода первого байта запроса будет плавать.
На сколько плавать? вопрос хороший... простой линукс изкоропки... без х11, 1 задача раз в 10 мс опрашивает устройства, 4 "фоновых" задачи по тсп отдают инфу. так задержки между опросами иногда получаются больше 100 мс, да и при передачи пакета.... по спецификации модбуса если в пакете между байтами пауза больше 1,5 символа, то пакет бракуется. на линуксе 1 задача постоянно шлет пакеты на скорости 921600..... так там постояк паузы до 2-3 символов. А настроить приоритеты на линуксе, даже без реал тайма - пока руки не дошли.


*ЗАПЕСАЛ*


а обычная винда какое колебание даёт? Измеряли?

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

У MATLAB есть Real-time Windows Target. Мне кажется, что там возможно то, что ТС требует.

Я одно не пойму: фридос32 аппликухи в супервизоре запускает или? Если нет -какая может быть реалтаймовость?, если SVC при желании "заткнет" всю систему собой... Int21h - и привет.

Сообщение отредактировал _Pasha - Sep 28 2012, 10:33

поднимите приоритет у процесса да посмотрите что получится:
и еще если ядер/процессоров больше чем одно может сильно помочь принудительно перекинуть процесс на другие ядра, там ему почти никто мешать не будет.

вполне удавалось распарсить синхронный битовый поток просто подключенный к статусным линиям компорта (клоки и данные). с частотами в десятки килогерц, так что 10мс не должно быть проблемой. у меня там правда потеря данных вообще некритична была.
всё упирается в то, насколько критично иногда, пусть очень редко получить задержку более чем 1 мс и в вероятности этого события.

Дык, ежели повиснуть на таймере - никакой Int21h не помешает
Таймер, кстати, можно ускорить. Помнится, делал 1КГц, всё чудесно работало (в MS-DOS, но не суть).


+1. Мультимедиа таймер + REALTIME_PRIORITY_CLASS - давали вполне приемлемую работу с милисекундными интервалами.

Откуда слухи?
Таймслайс в ядрах 2.6 Linux из той самой вашей "изкоропки" - 1мс., и именно в таком временном масштабе будут происходить все процессы в Linux.



Стандарт UDP вообще не гарантирует, что UDP пакеты вообще дойдут до получателя: стек IP вполне имеет право при высокой загруженности отправлять полученные дэйтаграммы в мусор без всяких реакции или уведомления.
ТС - читайте матчасть по IP, всё того же Р.Стивенса.
Не сможете вы ничего гарантировать при UDP!

P.S. TCP/IP Illustrated, 2nd Edition

Спасибо . Получилось скачать и отсюда.

если допустим +-1мс разброса вероятность потери можно сильно уменьшить, послав десяток другой пакетов вместо одного за эту самую 1мс.
а от TCP радости тут тоже не сильно много, то что пакет потерялся и его надо перепослать за 1мс можно и не понять.
то есть какой-нибудь свой простой протокол поверх UDP для контроля потерь может оказаться более подходящим для данной задачи.

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

Вот есть MIDI-RTP, RTP - протоколы. Они ведь поверх udp! А время доставки гарантируется...
Пожалуйста, объясните, за счет чего, я не понимаю. Типа, там в транспортном уровне все?

Сообщение отредактировал _Pasha - Sep 29 2012, 18:34

Можно ли получить от Вас какую-нибудь ссылку на стандарт/документ/книгу/что-то ещё, подтверждающие эти Ваши слова ?

При переполнении входных буферов, несомненно, входящая IP-датаграмма будет отброшена, но её отправитель будет уведомлён ICMP сообщением. Теоретически - ICMP сообщение тоже может быть отброшено из-за переполнения буферов, но уже на другой стороне, и тогда IP-датаграмма, действительно, молча "канет в лету". Но, это - уже ошибка в проектировании системы с "жестким" временем, но успользующую для передачи информации "узкие" каналы, а не недостаток UDP. Трименять же TCP в задачах с "жестким" временем - неразумно, поскольку TCP в описанной выше ситуации убивает "жесткое" время "наповал"...

Нет, не гарантируется.... Пакеты могут запаздывать или, вообще, терятся. Эти протоколы "заточенны" под алгоритмы сокрытия ошибок. В случае потери (запаздывания) пакета - информация реального времени (голос, видео, и т.п.) воспроизводится с потерей качества с использованием тех пакетов, что были приняты к моменту времени, когда информацию по условию Real time необходимо воспроизвести.

RTP создан главным образом (я не знаю других реальных применений) как несущий протокол для SIP, протокол для передачи потоковых видео-аудио. Там потеря даже и не одного UDP пакета никак принципиально не критична (вы разговаривали по VoIP каналам, наверняка ... ну и как? ).

Всё что связано с RTP для этих целей очень обстоятельно и любопытно можно наблюдать (или почитать в их документации) в открытых проектах PBX (soft switch): Asterisk, а ещё лучше FreeSWITCH.

~99.5% пакетов укладываются по времени.
Колебание 7-13мс. При чем на семерке пакеты идут вокруг 10.0 мс, а на ХР где-то ~75% приходит в 9.8мс и ~25% в 10.8 мс. Не знаю с чем это связано.
Сегодня буду разговаривать с алгоритмистами, как я понял, для них главное получать новые показания не реже, чем раз 10мс, то есть если уменьшить период до 5мс (или еще меньше) - это их полностью устроит.