boost::ptime - реальные интервалы на разных системах, странная проблема с таймером под вендой Опции

[Iron Bug]

наверное, я тут соберу все возможные глюки систем пока я пишу свой проект!
какой-то очередной затык, на этот раз с таймерами...
в результате экспериментов выползла весьма странная, на мой взгляд, проблема:
написан тестовый бустовский поток, работающий с прерываниями (thread::interrupt()), c условными переменными (conditional_variable) в качестве синхронизации и с таймерами (timed_wait), работающими с этими переменными. в качестве временных интервалов для таймеров использовался позиксовский ptime, реализованный в бусте как часть date_time библиотеки.
вообще, у меня была идея проверить совсем другие вещи, но в итоге получился такой интересный вывод про таймеры: запускаю тест дома под линюксом - минимальный интервал срабатывания timed_wait - примерно 50 микросекунд. при риал-тайм приоритете даже до 10 можно довести, а в худшем случае при загрузке системы - ну максимум 200 задержка может быть (это десктопный вариант дебиана с 26 ядром).
а вот под вендой XP Pro на работе та же прога даёт минимальный интервал аж в 15625 микросекунд - и это вообще без нагрузки на систему!
это что, такие тормоза системного таймера в венде или я чего-то недопонимаю в реализации??? может, ptime не самый быстрый таймер в бусте? (я использую microseconds интервалы).
я понимаю, что венда - не риал-тайм система, но неужели всё настолько плохо или это всё-таки реализация подводит?


копалась в сети, вот чел на ту же самую проблему напоролся:
http://www.nabble.com/-date_time--Timer-an...td21884194.html

видимо, всё-таки проблема в реализации...

[Andrew Selivanov]

наверное, я тут соберу все возможные глюки систем пока я пишу свой проект!
какой-то очередной затык, на этот раз с таймерами...
в результате экспериментов выползла весьма странная, на мой взгляд, проблема:
написан тестовый бустовский поток, работающий с прерываниями (thread::interrupt()), c условными переменными (conditional_variable) в качестве синхронизации и с таймерами (timed_wait), работающими с этими переменными. в качестве временных интервалов для таймеров использовался позиксовский ptime, реализованный в бусте как часть date_time библиотеки.
вообще, у меня была идея проверить совсем другие вещи, но в итоге получился такой интересный вывод про таймеры: запускаю тест дома под линюксом - минимальный интервал срабатывания timed_wait - примерно 50 микросекунд. при риал-тайм приоритете даже до 10 можно довести, а в худшем случае при загрузке системы - ну максимум 200 задержка может быть (это десктопный вариант дебиана с 26 ядром).
а вот под вендой XP Pro на работе та же прога даёт минимальный интервал аж в 15625 микросекунд - и это вообще без нагрузки на систему!
это что, такие тормоза системного таймера в венде или я чего-то недопонимаю в реализации??? может, ptime не самый быстрый таймер в бусте? (я использую microseconds интервалы).
я понимаю, что венда - не риал-тайм система, но неужели всё настолько плохо или это всё-таки реализация подводит?


копалась в сети, вот чел на ту же самую проблему напоролся:
http://www.nabble.com/-date_time--Timer-an...td21884194.html

видимо, всё-таки проблема в реализации...

Почитай еще здесь
http://lists.boost.org/Archives/boost/2002/06/31205.php
http://www.ddj.com/windows/184416651
http://msdn.microsoft.com/en-us/magazine/cc163996.aspx
Иии если будешь думать про RDTSC имей ввиду, что там много своих подводных камней.
Резюмируя - единого решения нет.

Но лучше RDTSC навряд ли можно что-то накопать... нуууу почти навряд ли.
18.11 Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System Programming Guide, Part 2
http://download.intel.com/design/processor...uals/253669.pdf

Сообщение отредактировал Andrew Selivanov - 20.3.2009, 14:10

[Iron Bug]

м-дя... что-то совсем грустно, что нет единого решения для такой нехитрой задачи, как обычный таймер. так хотелось сделать общую софтину без ifdef'ов и всяких ухищрений машинно- и системно-зависимых...
умилил вопрос в статейке: Why would you be interested in obtaining the system time with a resolution below one millisecond?
блин, у меня в рабочих машинах миллисекунда - это целая вечность, а за 10 миллисекунд вообще физические девайсы могут поломаться, если вовремя не отловить и не обработать критическое событие...
определённо, венда - не RT система: на уровне драйверов я наблюдала задержки вызова обработки немаскируемых прерываний до 200 микросекунд, теперь вот это ракообразие реализации системного таймера на верхнем уровне...
придётся сесть и написать отдельный модуль с таймером для венды.
но всё-таки интересно узнать, что об этом разработчики буста думают. в багах у них нет такого пункта. но 15-миллисекундный квант в реализации таймеров для потоков - это если и не бага, то просто ужоснах какой-то. вполне возможно, что имеет смысл доработка буста в этом плане, тем более, что она возможна.

[Andrew Selivanov]

В Boost-e я так понимаю тупо используется GetSystemTimeAsFileTime, т.е. навряд ли это бага Boost-a (хотя кто знает)

см ../datetime/microsec_time_clock.hpp

Кстати ты прочитала ответ Кемпфа в первой ссылке за 2002 год? (и последующий тред?)

>1. The Windows system timer runs between 10ms and 55ms, depending on the
>version of Windows used
>(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/ti
>me_5h2d.asp). Reinhold tells me that the value returned by
>GetSystemTimeAsFileTime seems to update at the same rate.

This one I consider a non-issue. The xtime stuff does not promise any kind
of granularity, so a 10-55ms variation on different Windows platforms is not
a "violation" of the implied contract here.

Что в переводе как я полагаю "и не ...волнуют меня ваши виндовые проблемы"

[Iron Bug]

тут не про xtime речь. xtime - это маленькая "самопальная" реализация таймеров в библиотеке thread. она действительно маленькая, простенькая и примитивная. там один файл реализации и две-три служебные функции. однако thread поддерживает работу синхронизации по всем видам таймеров, включая общие бустовские таймеры ptime из date_time. и вот date-time - это уже серьёзная библиотека, в которой они попытались создать универсальный набор утилит для работы со временем и таймерами. она развивается и вполне вероятно, что её можно укомплектовать некоторыми наворотами по уточнению работы со временем в венде. ведь там даже есть работа с наносекундными интервалами в 64-битных системах. я её не тестировала, но теортетически она как-то работает и явно не через тормозной вендозный системный таймер! почему бы не поковыряться и для 32-битных систем...

[Andrew Selivanov]

тут не про xtime речь. xtime - это маленькая "самопальная" реализация таймеров в библиотеке thread. она действительно маленькая, простенькая и примитивная. там один файл реализации и две-три служебные функции. однако thread поддерживает работу синхронизации по всем видам таймеров, включая общие бустовские таймеры ptime из date_time. и вот date-time - это уже серьёзная библиотека, в которой они попытались создать универсальный набор утилит для работы со временем и таймерами. она развивается и вполне вероятно, что её можно укомплектовать некоторыми наворотами по уточнению работы со временем в венде. ведь там даже есть работа с наносекундными интервалами в 64-битных системах. я её не тестировала, но теортетически она как-то работает и явно не через тормозной вендозный системный таймер! почему бы не поковыряться и для 32-битных систем...

Ты внимательно мой пост посмотри... я про xtime не говорил. Именно в ../datetime/microsec_time_clock.hpp и есть тормозной системный таймер и пачка дефайнов / workarounds

/*! @file microsec_time_clock.hpp
  This file contains a high resolution time clock implementation.
*/
...
    //! Return the local time based on computer clock settings
    static time_type local_time() {
      FILETIME ft;
      #if BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3205))
      // Some runtime library implementations expect local times as the norm for ctime.
      FILETIME ft_utc;
      GetSystemTimeAsFileTime(&ft_utc);
      FileTimeToLocalFileTime(&ft_utc,&ft);
      #elif defined(BOOST_NO_GETSYSTEMTIMEASFILETIME)
      SYSTEMTIME st;
      GetSystemTime( &st );
      SystemTimeToFileTime( &st, &ft );
      #else
      GetSystemTimeAsFileTime(&ft);
      #endif
      return create_time(ft, LOCAL);
    }
    
    //! Return the UTC time based on computer settings
    static time_type universal_time() {
      FILETIME ft;
      #if BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3205))
      // Some runtime library implementations expect local times as the norm for ctime.
      FILETIME ft_utc;
      GetSystemTimeAsFileTime(&ft_utc);
      FileTimeToLocalFileTime(&ft_utc,&ft);
      #elif defined(BOOST_NO_GETSYSTEMTIMEASFILETIME)
      SYSTEMTIME st;
      GetSystemTime( &st );
      SystemTimeToFileTime( &st, &ft );
      #else
      GetSystemTimeAsFileTime(&ft);
      #endif
      return create_time(ft, GMT);
    }

[Tonal]

2 Iron Bug Таки посмотри на Erlang - он даёт soft real time.

[Iron Bug]

2 Iron Bug Таки посмотри на Erlang - он даёт soft real time.

Не... Думаю, не канает. Две причины: во-первых - виртуальная машина... нафиг надо ещё интерпретаторы - я по скорости на Си с полной оптимизацией едва укладываюсь иногда... А вторая - строгая изоляция процессов в Erlang, а у меня общих данных просто дофига - и все процессы(потоки) должны иметь к ним доступ. Так что думаю, всё-таки старый добрый Си. Ну, и ++ иже с ним, я их особо не разделяю, ибо на чистом Си практически не пишу последнее время, только изредка для контроллеров разве что.
Я думаю, пока что просто буду копаться и писать ifdef'ы для венды вместо буста, чтобы обойти ограничения таймеров. Если время будет - посмотрю реализацию date-time: насколько сложно туда внедрить обход этого тормозного "системного таймера". Если можно - то буду писать разработчикам буста. Просто так писать нет смысла - надо сначала поглядеть, какая там ситуация с таймерами и можно ли её улучшить.

[Iron Bug]

вот, пока копала буст и точные таймеры...
выяснилось, что проблема не только в них. точнее, если бы только в них! я первым делом прикрутила быстрые таймеры к date_time. это только заголовочники, так что тут сложностей не было. но тут вылезли другие "цветочки": потоки... все слипы, вся синхронизация потоков сделаны через вендозный Sleep и WaitForSingleObject, а там.... там миллисекунды! (тут бы надо подвесить кое-кого за кое-что, но об этом умолчу). Можно сделать более хитрожопо, через объекты ядра, но будет жрать больше ресурсов и возни там не на один день и возможно даже не на месяц, если капитально всё переделывать. более того, если копать дальше, то эти геморройные миллисекундные функции вылазят в межпроцессной библиотеке - теоретически, если уж править, то и там тоже надо всё перекапывать.
так что пока что у меня миллисекундная задержка осталась при синхронизации потоков и слипе. понятное дело, откуда - из реализации вендозных функций, заюзанных в потоках.
покопаюсь ещё, если не задолбает - буду потихоньку дорабатывать библиотеки, но хрен знает сколько времени это может занять, тем более что код не мой. я теперь понимаю, почему господин Кемпф не хочет с этим связываться!

[Tonal]

Для винды есть мультимедийный таймер. (About Multimedia Timers) Он вроде как даёт заметно большую точность чем обычный.

Но таки лучше не использовать десктопную винду для реалтайма.

Сообщение отредактировал Tonal - 31.3.2009, 11:12