Выполнение участка кода в реальном времени, засекаем время?

Question

[Zenker]

Приведу сразу фрагмент кода:

t1 = timeGetTime();
    Device.sendRequest( Command1 );
    R1 = Device.readResponse();

    Device.sendRequest( Command2 );
    R2 = Device.readResponse();
t2 = timeGetTime();
cout << t2-t1 << " ms" << endl;

На некоторое устройство по интерфейсу RS-232 посылаем некоторый запрос, затем дожидаемся ответа и повторяем все еще раз. Для замера времени работы используется Multimedia Timer. Возникает два вопроса:


1) Насколько вообще корректно подобным образом замерять время работы? Данный таймер, как заявляет майкрософт, обеспечивает разрешение 1 мс. В реальных условиях данный код выполняется(по данным этого таймера) за 20..50 мс, и точность этого измерения играет критичную роль в решении задачи.


2) Собственно, главный вопрос. Работаем мы в многозадачной среде. Если прогнать вышеприведенный замер, скажем, 100 раз подряд, в среднем получаются значения 20..30 мс, что более-менее сходится с теоретическими расчетами для данной скорости передачи и длины сообщений. Однако, периодически встречаются выбросы в 50..60 мс, а этот момент имеет принципиальное значение. Если мое предположение верно, где-то в процессе ожидания ответа или перед посылкой второго запроса процесс может быть сочтен ожидающим и планировщик «вклинивает» на выполнение какой-то посторонний процесс. Разумеется, возможно дело в самом оборудовании, но хотелось бы исключить влияние ОС. Собственно, вопрос: подскажите, пожалуйста, грамотный способ: как можно повысить приоритет для данного участка кода, чтобы он выполнялся максимально монопольно, без непредсказуемых задержек со стороны ОС?

У меня сейчас нет возможности попробовать самому, но удалось нагуглить про функции SetPriorityClass() и SetThreadPriority(). Это хотя бы верное направление, поможет решить задачу?

Answer 1

[Vladimir]

а разве Windows 7 является системой реального времени? :)
установить более высокий приоритет — да — это чуть поможет, но от переключения контекста не избавит.
если важен RT, то лучше смотреть в сторону RTOS, пробовать Linux с RT-патчем и т.п.

Comments

[Zenker]

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

[egorinsk]

В Windows есть приоритет реального времени, или что-то вроде этого, но им при неумелом использовании можно повесить систему (так как задача займет все процессорное время).

Answer 2

[ntkt]

По поводу таймеров в Windows есть неплохая вводная статья Jan Wassenberg «Timing Pitfalls and Solutions»
github.com/0ad/0ad/raw/master/docs/timing_pitfalls.pdf

Comments

[ntkt]

Ключевые слова: QueryPerformanceFrequency / QueryPerformanceCounter, HPET.

Еще смотрите на gamedev.ru, там знают толк в таймерах: www.gamedev.ru/code/forum/?id=80205
Кажется, именно оттуда я копал пару лет назад, когда нужно было измерить именно на винде и именно с максимально высокой точностью

[ntkt]

www.gamedev.ru/code/forum/?id=132140#m9 сюда же

[Zenker]

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

Answer 3

[egorinsk]

В windows есть более точные методы измерения времени, например. QueryPerformanceCounter. Чтобы узнать, вытеснялся ли ваш процесс, можно поискать значение какого-нибудь счтечика переключений контекста.

Answer 4

[Ilya Evseev]

По поводу таймера — уже читали stackoverflow.com/questions/1825720/c-high-precision-time-measurement-in-windows?
Это первая ссылка в Гугле по запросу «windows high resolution timer».

По поводу приоритетов всё написано правильно, тут пишут то же самое.
Найдено Гуглом по запросу «windows change process priority c++».
На многоядерном процессоре максимальный приоритет позволит процессу/потоку получить _почти_ реалтайм.
Если его всё равно окажется недостаточно — тогда останется либо переходить на полноценную(?) RT OS, либо брать WDK и писать собственный драйвер :)

Comments

[Zenker]

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

Answer 5

[Владимир Мартьянов]

Как уже написали выше: винда — не Real Time. Второе: последовательный порт, как минимум в XP/2K — штука хитрая и от реализации Device.readResponse может зависеть время. И самый, все-таки, главный вопрос: что вы измеряете? Реальное время от приема посылки до окончания передачи (с точки зрения устройства) или время от передачи до приема на винде? Если первое — светодиод и осцилограф. Если второе — печаль.

Comments

[ntkt]

Полностью согласен, что ПК на винде тут не лучший измерительный прибор.
Берем любой приличный цифровой осцилл с интерфейсом к ПК, вешаем на интересующие сигнальные линии и, используя его SDK и/или labview-плагин, делаем замеры.

[Владимир Мартьянов]

Да даже цифровой не нужен: в цикле гоним с винды сообщения, приемник при приеме ножку вверху, после конца передачи — вниз. Нормально синхронизацию на аналоговом выставить — сразу и минимальное и максимальное время будет видно :-)

[Zenker]

Функции send и read — это по сути обертки для работы с кодом отсюда: msdn.microsoft.com/en-us/library/ff802693.aspx
Что касается самого измерения — тут как раз второй случай. Одна итерация цикла — с момента отправки первого запроса и до момента получения второго ответа, на это есть около 30 мс, в которые в принципе удается уложиться даже с запасом, если бы не отдельные выбросы

[Владимир Мартьянов]

Хороший код, до боли знакомый :-) В общем, есть подозрение что от выбросов избавиться не выйдет — ОС так работает. Попробуйте осциллом ткнуться, если на осцилле все ровно, а в винде время сильно плавает — винда виновата.