Real time на Windows XP Опции

[Slovan]

Добрый день!

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

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

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

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

[juvf]

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

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

Если на комп поставить голый линукс, то ситуация не лучше. Что для линукса, что для венды... чтоб получить жёсткие интервалы времени нужен бубен типа такого.

[_Pasha]

На DOS перейдите, чего уж там...

[sasamy]

Если на комп поставить голый линукс, то ситуация не лучше.

Что такое голый линукс ? Это голый или не голый
http://www.redhat.com/products/mrg/realtime/

[Slovan]

Если на комп поставить голый линукс, то ситуация не лучше. Что для линукса, что для венды... чтоб получить жёсткие интервалы времени нужен бубен типа такого.

Ну если бы можно было поставить другую систему, то смотрели бы в первую очередь сторону QNX...
Venturcom RTX это и есть http://www.intervalzero.com/

На DOS перейдите, чего уж там...

Ну да, вариант. Еще Win CE можно попробовать.

[juvf]

Что такое голый линукс ? Это голый или не голый
http://www.redhat.com/products/mrg/realtime/

это не голый.

Технически MRG Realtime – это набор пакетов, превращающих стандартный Red Hat Enterprise Linux (RHEL) в ОС реального времени.

Можно поставить какойнить дебьян и руками настроить и/или доставить набор пакетов превращяющий дебьян в реалтайм.

Ну если бы можно было поставить другую систему, то смотрели бы в первую очередь сторону QNX...

В общем, уговорить перейти на что-то более адекватное у меня не получается.

я не предлагаю поставить др систему. Я про линукс сказал к тому, что дригие ос, а это линуксы, фрибсд, макОС.... это тоже не реалтайм и там тоже нужен бубен.
Да, совсем забыл про QNX. Могу сказать про QNX4.25 реалтаймовости она даст, но будут проблемы с дровами под современное железо. QNX6 ... ни чего не скажу, неуспел освоить.

А ДОС даст опрос по таймеру строго каждые 10 мс или строго каждую мс если паралельно будут крутиться ещё несколько мение приоритетных задач? Тоже есть пару проектов где хотелось-бы строгие интервалы иметь

[gerber]

Понимаю всю обсурдность вопроса... но стоит задача - обеспечить передачу UDP пакетов в сеть с жестким интервалом 10мс.

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

Сообщение отредактировал gerber - Sep 28 2012, 07:00

[_Pasha]

А ДОС даст опрос по таймеру строго каждые 10 мс или строго каждую мс если паралельно будут крутиться ещё несколько мение приоритетных задач? Тоже есть пару проектов где хотелось-бы строгие интервалы иметь

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

[sasamy]

это не голый.
Можно поставить какойнить дебьян и руками настроить и/или доставить набор пакетов превращяющий дебьян в реалтайм.

Тогда нужно говорить не голый/одетый а про ванильное ядро. Ветка -rt одна из многих девелоперских веток и все что там стабильно и имеет применение со временем попадает в майнстрим
https://www.osadl.org/Realtime-Linux.projec...me-linux.0.html

юзерспейс остается тем-же, в этом изюминка подхода - realtime Linux не требует модификации кода юзерспейс, специальных драйверов и пакетов кроме утилиты для раздачи приоритетов (chrt), которая там и так есть.

Действительно, абсурдная постановка задачи. Первый же встретившийся на пути пакетов UDP роутер или даже Ethernet-свич сломает любой жёсткий интервал следования пакетов.

http://en.wikipedia.org/wiki/Precision_Tim...ssage_transport


Сообщение отредактировал sasamy - Sep 28 2012, 08:14

[juvf]

Тогда нужно говорить не голый/одетый а про ванильное ядро. Ветка -rt одна из многих девелоперских веток и все что там стабильно и имеет применение со временем попадает в майнстрим
https://www.osadl.org/Realtime-Linux.projec...me-linux.0.html

ну уж тогда нужно говорить "linux" и "realtime Linux". Даже на вашей ссылке в одном месте слово линукс
"Is realtime possible with Linux?" (даже в этом вопросе подрозумевается что обычный линукс не реалтаймовый), и на всем сайте они свой линукс называют "Realtime Linux".

Дос-то однозадачный

досы то разные бывают..... я просто думал что FreeDOS-32 многозадачный. ашипся, пока тока в планах ввести многозадачность.

[sasamy]

"Is realtime possible with Linux?" (даже в этом вопросе подрозумевается что обычный линукс не реалтаймовый)

и "необычный" не реалтаймовый (по крайней мере как это многие понимают на микроконтроллерах - точность до тактов) это игра слов, а детерминизм достаточный для задач ТС (10 мс) обеспечит даже ванильное ядро на х86 (HPET там давным давно есть на всех системах).

Сообщение отредактировал sasamy - Sep 28 2012, 08:53

[gerber]

http://en.wikipedia.org/wiki/Precision_Tim...ssage_transport

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

[_Pasha]

досы то разные бывают..... я просто думал что FreeDOS-32 многозадачный. ашипся, пока тока в планах ввести многозадачность.

http://www.on-time.com/rtkernel-dos.htm
Знакомая штучка?

[Slovan]

Действительно, абсурдная постановка задачи. Первый же встретившийся на пути пакетов UDP роутер или даже Ethernet-свич сломает любой жёсткий интервал следования пакетов.

Хм... Ну роутеров у нас нет, только свичи. Большого потока данных не идет. Небольшое колебание 9-11мс допускается. Вроде не должно быть проблем.

[sasamy]

Возможность синхронизировать время по сети никак не гарантирует, что UDP пакеты дойдут до получателя строго с тем же интервалом, с каким вышли от отправителя.

Ну все - нужно срочно каждому тянуть синхронные коммуникации до Гринвича, ггг. Как говорится смотрю в книгу вижу фигу.

[gerber]

Ну все - нужно срочно каждому тянуть синхронные коммуникации до Гринвича, ггг. Как говорится смотрю в книгу вижу фигу.

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

[juvf]

a детерминизм достаточный для задач ТС (10 мс) обеспечит даже ванильное ядро на х86 (HPET там давным давно есть на всех системах).

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

http://www.on-time.com/rtkernel-dos.htm
Знакомая штучка?

*ЗАПЕСАЛ*

Хм... Ну роутеров у нас нет, только свичи. Большого потока данных не идет. Небольшое колебание 9-11мс допускается. Вроде не должно быть проблем.

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

[sasamy]

при чем здесь детерминизм? ну будет таймер давать импульсы с точностью ±1*10^(-10000000000000000000000000000000) секунд. и что дальше.....

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

[syoma]

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

[_Pasha]

*ЗАПЕСАЛ*

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

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

[_pv]

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

Код

SetPriorityClass (GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
//SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);
SetProcessAffinityMask(GetCurrentProcess(), 1);
//SetThreadAffinityMask(GetCurrentThread(), 1);

__int64 freq;
__int64 t1;
__int64 t2;
QueryPerformanceFrequency((LARGE_INTEGER *) &freq);
QueryPerformanceCounter((LARGE_INTEGER *) &t1);
QueryPerformanceCounter((LARGE_INTEGER *) &t2);
while (1){
  while ((t2 - t1) < 0.01 * freq) QueryPerformanceCounter((LARGE_INTEGER *) &t2);
  QueryPerformanceCounter((LARGE_INTEGER *) &t1);
  sendUdpPacket();
}

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

[AHTOXA]

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

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

поднимите приоритет у процесса да посмотрите что получится

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

[Olej]

На сколько плавать? вопрос хороший... простой линукс изкоропки... без х11, 1 задача раз в 10 мс опрашивает устройства,

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

Возможность синхронизировать время по сети никак не гарантирует, что UDP пакеты дойдут до получателя строго с тем же интервалом, с каким вышли от отправителя.

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

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

[Konst_777]

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

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

[_pv]

Не сможете вы ничего гарантировать при UDP!

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

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

[_Pasha]

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

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

[Палыч]

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

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

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

[Палыч]

Вот есть MIDI-RTP, RTP - протоколы. Они ведь поверх udp! А время доставки гарантируется...

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

[Olej]

Вот есть MIDI-RTP, RTP - протоколы. Они ведь поверх udp! А время доставки гарантируется...

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

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

[Slovan]

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

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

[Olej]

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

Могу (с очень большой вероятностью) предположить, что все эти различия связаны: а). с значением временного тика в системе, б). с дискретностью измерения времени не выше этого значения тика + в). того как вы делаете измерения временных интервалов.Обычно такие измерения очень грубые, чтобы по ним смотреть статистику.

P.S. попробуйте измерять по значению счётчика процессорных тактов - RDTSC.

[juvf]

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

на венде легко выставить приоритет задаче. можно выставить... как же он называется... . TimeCriticalPriority чтоли, ну или выше, чуть ли не реалтаймПриорити. При каком приоритете какие результаты? Какие результаты при самом высоком приоритете?

[Slovan]

P.S. попробуйте измерять по значению счётчика процессорных тактов - RDTSC.

Именно так и измеряю.

на венде легко выставить приоритет задаче. можно выставить... как же он называется... . TimeCriticalPriority чтоли, ну или выше, чуть ли не реалтаймПриорити. При каком приоритете какие результаты? Какие результаты при самом высоком приоритете?

Да все с риалтам приорити естественно.

[Olej]

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

"чуть ли не реалтайм"(с) - это высокий класс!
Это уже - рождение терминологии!

Вообще, сочетания слов "Real time" и "Windows XP" в названии темы - это очень веселит ... я по-началу так и подумал, что это анекдот какой...

[_pv]

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

Добавте что-нибудь по-проще перед посылкой UDP пакета, вроде дергания статусными ногами на ком порте, и посмотрите осциллографом. может грабли где-то дальше лежат.
какой там сервис за сеть в виндах отвечает, может и ему приоритет поднять?
Affinitymask менять не пробовали?

[sasamy]

Вообще, сочетания слов "Real time" и "Windows XP" в названии темы - это очень веселит ... я по-началу так и подумал, что это анекдот какой...

Это не анекдот - это совковое воспитание, в нормальной стране такие "разработчики" давно бы заборы подметали

Система только виндоуз и ничего кроме виндоуз. (Причины: ... просто лень разработчиков)...

[_Pasha]

Вообще, сочетания слов "Real time" и "Windows XP" в названии темы - это очень веселит ... я по-началу так и подумал, что это анекдот какой...

Шутки шутками, а под вынь-98 (голая, там только моя программа стояла) принимало постоянный поток от uart->usb на PL230x(не помню какая) на 230400 в одном из 4-х тредов. Был пень-133. Памяти не помню, но мало. Сбоев на пальцах можно пересчитать было часов за 4 работы.
Пакеты были короткие и утоптанные по самое немогу - надо было вкладываться во временные рамки. Этот же тред их и декодировал. ЦПУ загрузка 80% минимум.

Сообщение отредактировал _Pasha - Oct 2 2012, 07:31

[Slovan]

Вот так выглядят тестовые программы:

Для передачи:

CODE

#include <windows.h>
#include <tchar.h>
#include <stdio.h>


SOCKET sock;
struct sockaddr_in to;
char tx[] = "testtestestesttestestesttestestesttestestesttestes";

void CALLBACK SendPacket(UINT wTimerID, UINT msg, DWORD dwUser, DWORD dw1, DWORD dw2)
{
sendto(sock, tx, 48, 0, (struct sockaddr*)&to, sizeof(struct sockaddr_in));
}

int _tmain(int argc, _TCHAR* argv[])
{
SetProcessAffinityMask(GetCurrentProcess(), 0x02);
SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);

WSADATA wd;
WSAStartup(MAKEWORD(2, 2), &wd);

sock = socket(AF_INET, SOCK_DGRAM, 0);

to.sin_family = PF_INET;
to.sin_addr.s_addr = INADDR_BROADCAST;
to.sin_port = htons(49501);
memset(&(to.sin_zero), 0, 8);
char on = 1;
setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on));


UINT m_uResolution;
TIMECAPS tc;
timeGetDevCaps(&tc, sizeof(TIMECAPS));
m_uResolution = min(max(tc.wPeriodMin, 0), tc.wPeriodMax);

timeBeginPeriod(m_uResolution);

MMRESULT m_idEvent = timeSetEvent(
10,
m_uResolution,
SendPacket,
NULL,
TIME_PERIODIC);


getchar();
return 0;
}

Для приема:

CODE

#include <windows.h>
#include <tchar.h>
#include <stdio.h>

#define TOTAL_PACKETS 10000

double PCFreq = 0.0;

double GetCounter()
{
LARGE_INTEGER li;
QueryPerformanceCounter(&li);
return double (li.QuadPart)/PCFreq;
}

int _tmain(int argc, _TCHAR* argv[])
{

SetProcessAffinityMask(GetCurrentProcess(), 0x01);
SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);

LARGE_INTEGER li;
QueryPerformanceFrequency(&li);
PCFreq = double(li.QuadPart)/1000.0;


WSADATA wd;
WSAStartup(MAKEWORD(2, 2), &wd);

SOCKET sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);

struct sockaddr_in sa;

sa.sin_family = PF_INET;
sa.sin_addr.s_addr = INADDR_ANY;
sa.sin_port = htons(49501);
memset(&(sa.sin_zero), 0, 8);

bind(sock, (struct sockaddr*)&sa, sizeof(struct sockaddr));

int nbrcvd;
char buf[255];
double t0 = 0, t1 = 0, dt = 0;
int counter = 0;

unsigned __int32 tbl[100];
memset(tbl, 0, 400);

while (1)
{

nbrcvd = recv(sock, buf, sizeof(buf), 0);


if (nbrcvd > 0)
{

t1 = GetCounter();

if (t0 == 0)
t0 = t1;
else
{
dt = t1-t0;
t0 = t1;

//сбор статистики
nbrcvd = static_cast<int>((dt+0.1)/0.2);
tbl[nbrcvd]++;
}

counter++;
if (counter == TOTAL_PACKETS)
{
for (int i = 0; i<100; i++)
{
if (tbl[i] > 0)
fprintf(stdout, " %5.1f ms %5d %5.1f%% \n", (0.2*i), tbl[i], (double) (tbl[i]*100/TOTAL_PACKETS));
}

getchar();
return 0;
}
}
}
}

Такой результат на семерке, когда обе программы выполняются на одном компе:

CODE

8.8 ms 3 0.0%
9.0 ms 6 0.0%
9.2 ms 4 0.0%
9.4 ms 7 0.0%
9.6 ms 9 0.0%
9.8 ms 88 0.0%
10.0 ms 9746 97.0%
10.2 ms 110 1.0%
10.4 ms 11 0.0%
10.6 ms 7 0.0%
10.8 ms 4 0.0%
11.0 ms 1 0.0%
11.2 ms 3 0.0%

Вообще, сочетания слов "Real time" и "Windows XP" в названии темы - это очень веселит ... я по-началу так и подумал, что это анекдот какой...

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

[Olej]

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

А Linux и расширять ничем не надо: там и так всё, что касается времени - намного серьёзнее.
Ну так и вы Linux-ом передавайте?!

Кроме того, вся ваша задача к "реалтайм" вообще никакого касательства не имеет - это задача укладывания (более-менее) во временные рамки, задача масштаба времени.
Тем более с вовлечением в цепь событий IP-сети, которая по определению не может быть детерминированной.

стоит задача - обеспечить передачу UDP пакетов в сеть с жестким интервалом 10мс.
Система только виндоуз и ничего кроме виндоуз.

Хотя ... если задача стоит так, как изначально написано: ПЕРЕДАТЬ в сеть UDP дэйтаграммы с интервалом 10мс., а дальше в той сети ... "хоть трава не расти"...?
Может быть, может быть...

[_pv]

Вот так выглядят тестовые программы:

так нечестно, передача сделана от системных тиков в 1мс.
сделайте и передачу тоже по быстрому таймеру, оно конечно 100% процессорного времени отожрёт на опрос таймера, но работать должно гораздо лучше.

[_Pasha]

оно конечно 100% процессорного времени отожрёт на опрос таймера, но работать должно гораздо лучше.

Тем более, что можно скомбинировать оба метода и устраивать "ахтунг" по прошествии 5 мс

[_pv]

Тем более, что можно скомбинировать оба метода и устраивать "ахтунг" по прошествии 5 мс

ну или просто спать

Код

__int64 freq;
__int64 t1;
__int64 t2;
QueryPerformanceFrequency((LARGE_INTEGER *) &freq);
QueryPerformanceCounter((LARGE_INTEGER *) &t1);
t2 = t1;
while (1){
  while ((t2 - t1) < 0.01L * freq) QueryPerformanceCounter((LARGE_INTEGER *) &t2);
  t1 += 0.01L * freq;
  sendUdpPacket();
  Sleep(5);
}

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

[Konst_777]

Код

...
  Sleep(5);
...

Проснуться может и через 10 мс и через 100 мс и через ...

[_Pasha]

Проснуться может и через 10 мс и через 100 мс и через ...

Не-не. Приоритет ему понижать никто не буит.попалось на глаза

The moral of the story? Priorities are evil, don't mess with them. Always use Sleep(1) instead of Sleep(0). The Windows balance set manager is cool.

[Olej]

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

И не только "не очень хорошо"(с), а категорически нельзя измерять задержки в сетевой клиент-серверной системе (любой, не только в этой задаче) когда клиент и сервер работают на одном хосте, т.е. когда передача идёт на localhost. При этом процесс-клиент и процесс-сервер конкурируют за процессорные кванты и вытесняют друг друга... там начинаются такие чудеса!

Это не из области домыслов, а из реальной практики: как только клиент и сервер работают на localhost - временные результаты и зависимости получаются совершенно не те, чем при работе их в реальной LAN. И это не только в Windows (где всё хрен знает как смазано), а в Linux, QNX, Solaris и др. - где всё куда прозрачнее и понятнее.

[Slovan]

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

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

Вот статистика для вашего варианта, с подсчетом тиков. Запускал на двух ХР, 100 000 пакетов.
Получается точнее, но больших скачков, видимо, никак не избежать.

CODE

0.0 ms 2 0.0%
2.8 ms 1 0.0%
3.0 ms 1 0.0%
3.2 ms 1 0.0%
3.6 ms 1 0.0%
4.6 ms 1 0.0%
5.2 ms 3 0.0%
5.4 ms 1 0.0%
5.6 ms 1 0.0%
5.8 ms 1 0.0%
6.2 ms 1 0.0%
6.4 ms 1 0.0%
6.8 ms 2 0.0%
7.0 ms 1 0.0%
7.2 ms 1 0.0%
7.4 ms 2 0.0%
8.0 ms 1 0.0%
8.2 ms 2 0.0%
8.4 ms 1 0.0%
8.6 ms 6 0.0%
8.8 ms 19 0.0%
9.0 ms 47 0.0%
9.2 ms 54 0.0%
9.4 ms 38 0.0%
9.6 ms 48 0.0%
9.8 ms 720 0.0%
10.0 ms 97959 97.0%
10.2 ms 854 0.0%
10.4 ms 45 0.0%
10.6 ms 33 0.0%
10.8 ms 55 0.0%
11.0 ms 46 0.0%
11.2 ms 19 0.0%
11.4 ms 4 0.0%
11.6 ms 3 0.0%
11.8 ms 1 0.0%
12.0 ms 1 0.0%
12.2 ms 1 0.0%
12.4 ms 2 0.0%
12.8 ms 1 0.0%
13.2 ms 1 0.0%
13.4 ms 1 0.0%
13.6 ms 1 0.0%
14.0 ms 1 0.0%
14.2 ms 1 0.0%
14.4 ms 2 0.0%
14.6 ms 1 0.0%
14.8 ms 3 0.0%
15.4 ms 1 0.0%
16.4 ms 1 0.0%
16.8 ms 2 0.0%
17.0 ms 1 0.0%

Сообщение отредактировал Slovan - Oct 3 2012, 10:13