Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Real time на Windows XP
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
Slovan
Добрый день!

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

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

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

Если подключить к COM порту контроллер, который будет каждые 10мс посылать сигнал, и роботать по прерыванию - может это как-то улучшить ситуацию?
juvf
Цитата(Slovan @ Sep 28 2012, 02:58) *
Если подключить к COM порту контроллер, который будет каждые 10мс посылать сигнал, и роботать по прерыванию - может это как-то улучшить ситуацию?
Нет, такое решение не улучшит. Какя разница кто будет источником прерывания - компорт или внутренний таймер? Если винде надо будет обслужить другую задачу, например перерисовать гуи, то она запросто предержить обработку прерывания от компорта. Но если городить внешний контроллер, так пусть он и передает эти UDP паеты сам.

Если на комп поставить голый линукс, то ситуация не лучше. Что для линукса, что для венды... чтоб получить жёсткие интервалы времени нужен бубен типа такого.
_Pasha
На DOS перейдите, чего уж там...
sasamy
Цитата(juvf @ Sep 28 2012, 05:06) *
Если на комп поставить голый линукс, то ситуация не лучше.


Что такое голый линукс ? Это голый или не голый
http://www.redhat.com/products/mrg/realtime/
Slovan
Цитата
Если на комп поставить голый линукс, то ситуация не лучше. Что для линукса, что для венды... чтоб получить жёсткие интервалы времени нужен бубен типа такого.

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

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

Ну да, вариант. Еще Win CE можно попробовать.
juvf
Цитата(sasamy @ Sep 28 2012, 10:00) *
Что такое голый линукс ? Это голый или не голый
http://www.redhat.com/products/mrg/realtime/

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

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


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

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

А ДОС даст опрос по таймеру строго каждые 10 мс или строго каждую мс если паралельно будут крутиться ещё несколько мение приоритетных задач? Тоже есть пару проектов где хотелось-бы строгие интервалы иметь
gerber
Цитата(Slovan @ Sep 28 2012, 00:58) *
Понимаю всю обсурдность вопроса... но стоит задача - обеспечить передачу UDP пакетов в сеть с жестким интервалом 10мс.

Действительно, абсурдная постановка задачи. Первый же встретившийся на пути пакетов UDP роутер или даже Ethernet-свич сломает любой жёсткий интервал следования пакетов. Поэтому упираться в ОС бессмысленно. Для таких задач нужно смотреть в сторону синхронных коммуникаций.
И, кстати, реалтайм тут совершенно ни при чём. rolleyes.gif
_Pasha
Цитата(juvf @ Sep 28 2012, 09:27) *
А ДОС даст опрос по таймеру строго каждые 10 мс или строго каждую мс если паралельно будут крутиться ещё несколько мение приоритетных задач? Тоже есть пару проектов где хотелось-бы строгие интервалы иметь

Дос-то однозадачный sm.gif Но это совершенно не беда, если смастерить приложение, которое на самом деле будет FREERTOS с юзаньем железячных прерываний с одной стороны и доступом к биосу через досовские сервисы с другой. Почему бы и нет?
sasamy
Цитата(juvf @ Sep 28 2012, 10:27) *
это не голый.
Можно поставить какойнить дебьян и руками настроить и/или доставить набор пакетов превращяющий дебьян в реалтайм.


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

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

Цитата(gerber @ Sep 28 2012, 10:58) *
Действительно, абсурдная постановка задачи. Первый же встретившийся на пути пакетов UDP роутер или даже Ethernet-свич сломает любой жёсткий интервал следования пакетов.


http://en.wikipedia.org/wiki/Precision_Tim...ssage_transport
juvf
Цитата(sasamy @ Sep 28 2012, 14:28) *
Тогда нужно говорить не голый/одетый а про ванильное ядро. Ветка -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
Цитата(juvf @ Sep 28 2012, 12:37) *
"Is realtime possible with Linux?" (даже в этом вопросе подрозумевается что обычный линукс не реалтаймовый)


и "необычный" не реалтаймовый (по крайней мере как это многие понимают на микроконтроллерах - точность до тактов) это игра слов, а детерминизм достаточный для задач ТС (10 мс) обеспечит даже ванильное ядро на х86 (HPET там давным давно есть на всех системах).
gerber
Цитата(sasamy @ Sep 28 2012, 12:28) *

В огороде бузина, а в Киеве дядька.
Возможность синхронизировать время по сети никак не гарантирует, что UDP пакеты дойдут до получателя строго с тем же интервалом, с каким вышли от отправителя.
_Pasha
Цитата(juvf @ Sep 28 2012, 11:37) *
досы то разные бывают..... я просто думал что FreeDOS-32 многозадачный. ашипся, пока тока в планах ввести многозадачность.

http://www.on-time.com/rtkernel-dos.htm
Знакомая штучка?
Slovan
Цитата(gerber @ Sep 28 2012, 10:58) *
Действительно, абсурдная постановка задачи. Первый же встретившийся на пути пакетов UDP роутер или даже Ethernet-свич сломает любой жёсткий интервал следования пакетов.

Хм... Ну роутеров у нас нет, только свичи. Большого потока данных не идет. Небольшое колебание 9-11мс допускается. Вроде не должно быть проблем.
sasamy
Цитата(gerber @ Sep 28 2012, 13:04) *
Возможность синхронизировать время по сети никак не гарантирует, что UDP пакеты дойдут до получателя строго с тем же интервалом, с каким вышли от отправителя.


Ну все - нужно срочно каждому тянуть синхронные коммуникации до Гринвича, ггг. Как говорится смотрю в книгу вижу фигу.
gerber
Цитата(sasamy @ Sep 28 2012, 13:33) *
Ну все - нужно срочно каждому тянуть синхронные коммуникации до Гринвича, ггг. Как говорится смотрю в книгу вижу фигу.

Не каждому, а только топикстартеру. Это он так ставит задачу.
juvf
Цитата(sasamy @ Sep 28 2012, 14:51) *
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
Знакомая штучка?
*ЗАПЕСАЛ*

Цитата(Slovan @ Sep 28 2012, 15:23) *
Хм... Ну роутеров у нас нет, только свичи. Большого потока данных не идет. Небольшое колебание 9-11мс допускается. Вроде не должно быть проблем.

а обычная винда какое колебание даёт? Измеряли?
sasamy
Цитата(juvf @ Sep 28 2012, 13:44) *
при чем здесь детерминизм? ну будет таймер давать импульсы с точностью ±1*10^(-10000000000000000000000000000000) секунд. и что дальше.....


Вы с гербером хоть иногда шлем виртуальной реальности снимайте sm.gif
syoma
У MATLAB есть Real-time Windows Target. Мне кажется, что там возможно то, что ТС требует.
_Pasha
Цитата(juvf @ Sep 28 2012, 12:44) *
*ЗАПЕСАЛ*

Я одно не пойму: фридос32 аппликухи в супервизоре запускает или? Если нет -какая может быть реалтаймовость?, если SVC при желании "заткнет" всю систему собой... smile3046.gif Int21h - и привет.
_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
Цитата(_Pasha @ Sep 28 2012, 16:30) *
Я одно не пойму: фридос32 аппликухи в супервизоре запускает или? Если нет -какая может быть реалтаймовость?, если SVC при желании "заткнет" всю систему собой... smile3046.gif Int21h - и привет.
Дык, ежели повиснуть на таймере - никакой Int21h не помешаетsm.gif
Таймер, кстати, можно ускорить. Помнится, делал 1КГц, всё чудесно работало (в MS-DOS, но не суть).

Цитата(_pv @ Sep 28 2012, 17:33) *
поднимите приоритет у процесса да посмотрите что получится

+1. Мультимедиа таймер + REALTIME_PRIORITY_CLASS - давали вполне приемлемую работу с милисекундными интервалами.
Olej
Цитата(juvf @ Sep 28 2012, 12:44) *
На сколько плавать? вопрос хороший... простой линукс изкоропки... без х11, 1 задача раз в 10 мс опрашивает устройства,


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


Цитата(gerber @ Sep 28 2012, 12:04) *
Возможность синхронизировать время по сети никак не гарантирует, что UDP пакеты дойдут до получателя строго с тем же интервалом, с каким вышли от отправителя.

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

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

Konst_777
Цитата(Olej @ Sep 29 2012, 00:50) *

Спасибо a14.gif. Получилось скачать и отсюда.
_pv
Цитата(Olej @ Sep 29 2012, 03:50) *
Не сможете вы ничего гарантировать при UDP!

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

а для синхронизации какой-нибудь 1588 не лучше подходит разве? ну или просто NTP.
зачем каждые 10мс с 10% точностью выдавать синхронизацию? по своим часам каждый эти 10мс отмерить не может? ну и иногда подводить их чтоб не разбегались.
_Pasha
Вот есть MIDI-RTP, RTP - протоколы. Они ведь поверх udp! А время доставки гарантируется...
Пожалуйста, объясните, за счет чего, я не понимаю. Типа, там в транспортном уровне все?
Палыч
Цитата(Olej @ Sep 29 2012, 01:50) *
стек IP вполне имеет право при высокой загруженности отправлять полученные дэйтаграммы в мусор без всяких реакции или уведомления.

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

При переполнении входных буферов, несомненно, входящая IP-датаграмма будет отброшена, но её отправитель будет уведомлён ICMP сообщением. Теоретически - ICMP сообщение тоже может быть отброшено из-за переполнения буферов, но уже на другой стороне, и тогда IP-датаграмма, действительно, молча "канет в лету". Но, это - уже ошибка в проектировании системы с "жестким" временем, но успользующую для передачи информации "узкие" каналы, а не недостаток UDP. Трименять же TCP в задачах с "жестким" временем - неразумно, поскольку TCP в описанной выше ситуации убивает "жесткое" время "наповал"...
Палыч
Цитата(_Pasha @ Sep 29 2012, 22:33) *
Вот есть MIDI-RTP, RTP - протоколы. Они ведь поверх udp! А время доставки гарантируется...

Нет, не гарантируется.... Пакеты могут запаздывать или, вообще, терятся. Эти протоколы "заточенны" под алгоритмы сокрытия ошибок. В случае потери (запаздывания) пакета - информация реального времени (голос, видео, и т.п.) воспроизводится с потерей качества с использованием тех пакетов, что были приняты к моменту времени, когда информацию по условию Real time необходимо воспроизвести.
Olej
Цитата(_Pasha @ Sep 29 2012, 21:33) *
Вот есть MIDI-RTP, RTP - протоколы. Они ведь поверх udp! А время доставки гарантируется...


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

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

Slovan
Цитата(juvf @ Sep 28 2012, 13:44) *
а обычная винда какое колебание даёт? Измеряли?

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

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

P.S. попробуйте измерять по значению счётчика процессорных тактов - RDTSC.
juvf
Цитата(Slovan @ Oct 1 2012, 17:05) *
~99.5% пакетов укладываются по времени.
Колебание 7-13мс. При чем на семерке пакеты идут вокруг 10.0 мс, а на ХР где-то ~75% приходит в 9.8мс и ~25% в 10.8 мс. Не знаю с чем это связано.
Сегодня буду разговаривать с алгоритмистами, как я понял, для них главное получать новые показания не реже, чем раз 10мс, то есть если уменьшить период до 5мс (или еще меньше) - это их полностью устроит.

на венде легко выставить приоритет задаче. можно выставить... как же он называется... . TimeCriticalPriority чтоли, ну или выше, чуть ли не реалтаймПриорити. При каком приоритете какие результаты? Какие результаты при самом высоком приоритете?
Slovan
Цитата(Olej @ Oct 2 2012, 02:10) *
P.S. попробуйте измерять по значению счётчика процессорных тактов - RDTSC.

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

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

Да все с риалтам приорити естественно.
Olej
Цитата(juvf @ Oct 2 2012, 07:16) *
на венде легко выставить приоритет задаче. можно выставить... как же он называется... . TimeCriticalPriority чтоли, ну или выше, чуть ли не реалтаймПриорити.


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

Вообще, сочетания слов "Real time" и "Windows XP" в названии темы - это очень веселит ... я по-началу так и подумал, что это анекдот какой... biggrin.gif
_pv
Цитата(Slovan @ Oct 1 2012, 17:05) *
Колебание 7-13мс. При чем на семерке пакеты идут вокруг 10.0 мс, а на ХР где-то ~75% приходит в 9.8мс и ~25% в 10.8 мс. Не знаю с чем это связано.

Добавте что-нибудь по-проще перед посылкой UDP пакета, вроде дергания статусными ногами на ком порте, и посмотрите осциллографом. может грабли где-то дальше лежат.
какой там сервис за сеть в виндах отвечает, может и ему приоритет поднять?
Affinitymask менять не пробовали?
sasamy
Цитата(Olej @ Oct 2 2012, 11:02) *
Вообще, сочетания слов "Real time" и "Windows XP" в названии темы - это очень веселит ... я по-началу так и подумал, что это анекдот какой... biggrin.gif


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

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


_Pasha
Цитата(Olej @ Oct 2 2012, 10:02) *
Вообще, сочетания слов "Real time" и "Windows XP" в названии темы - это очень веселит ... я по-началу так и подумал, что это анекдот какой... biggrin.gif

Шутки шутками, а под вынь-98 (голая, там только моя программа стояла) принимало постоянный поток от uart->usb на PL230x(не помню какая) на 230400 в одном из 4-х тредов. Был пень-133. Памяти не помню, но мало. Сбоев на пальцах можно пересчитать было часов за 4 работы.
Пакеты были короткие и утоптанные по самое немогу - надо было вкладываться во временные рамки. Этот же тред их и декодировал. ЦПУ загрузка 80% минимум.
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
Цитата(Slovan @ Oct 2 2012, 15:06) *
Самое смешное, что в системе вообще не будет машин с жестким реальным временем. В частности компьютер, которому предназначаются эти пакеты, работает под линуксом, без каких либо реал тайм расширений.

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

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



Цитата(Slovan @ Sep 27 2012, 23:58) *
стоит задача - обеспечить передачу UDP пакетов в сеть с жестким интервалом 10мс.
Система только виндоуз и ничего кроме виндоуз.


Хотя ... если задача стоит так, как изначально написано: ПЕРЕДАТЬ в сеть UDP дэйтаграммы с интервалом 10мс., а дальше в той сети ... "хоть трава не расти"...?
Может быть, может быть... laughing.gif
_pv
Цитата(Slovan @ Oct 2 2012, 18:06) *
Вот так выглядят тестовые программы:

так нечестно, передача сделана от системных тиков в 1мс.
сделайте и передачу тоже по быстрому таймеру, оно конечно 100% процессорного времени отожрёт на опрос таймера, но работать должно гораздо лучше.
_Pasha
Цитата(_pv @ Oct 2 2012, 16:37) *
оно конечно 100% процессорного времени отожрёт на опрос таймера, но работать должно гораздо лучше.

Тем более, что можно скомбинировать оба метода и устраивать "ахтунг" по прошествии 5 мс
_pv
Цитата(_Pasha @ Oct 2 2012, 20:37) *
Тем более, что можно скомбинировать оба метода и устраивать "ахтунг" по прошествии 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
Цитата(_pv @ Oct 2 2012, 17:52) *
Код
...
  Sleep(5);
...

Проснуться может и через 10 мс и через 100 мс и через ...
_Pasha
Цитата(Konst_777 @ Oct 2 2012, 20:17) *
Проснуться может и через 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
Цитата(_pv @ Oct 2 2012, 17:52) *
и не очень хорошо на одном компе такое тестировать, виндовс насколько помню вообще пакет наружу в кабель не вытолкнет если передавать и принимать на адреса одного и того же интерфейса. возможно так было в прошлых версиях и в W7 по другому, но какие-то такие грабли припоминаю.


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

Это не из области домыслов, а из реальной практики: как только клиент и сервер работают на localhost - временные результаты и зависимости получаются совершенно не те, чем при работе их в реальной LAN. И это не только в Windows (где всё хрен знает как смазано), а в Linux, QNX, Solaris и др. - где всё куда прозрачнее и понятнее.
Slovan
Цитата(_pv @ Oct 2 2012, 18:52) *
и не очень хорошо на одном компе такое тестировать, виндовс насколько помню вообще пакет наружу в кабель не вытолкнет если передавать и принимать на адреса одного и того же интерфейса. возможно так было в прошлых версиях и в 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%
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.