Stopwatch.GetTimeStamp на мультипроцессорах

Stopwatch.GetTimeStamp() может возвращать различные результаты синхронизации на разных процессорах из-за ошибок в BIOS или аппаратной абстракции. Слой.

Кто-нибудь знает, что эти ошибки хранят в себе в конкретных терминах?

  1. Могут ли временные метки на разных процессорах потенциально быть совершенно не связанными - или они будут отличаться не более чем на небольшую величину (доли миллисекунд?)?
  2. Могут ли числа на разных процессорах со временем разойтись, что в результате приведет к вышеупомянутым «абсолютно несвязанным временным меткам»? (Я бы подумал, что это могут делать разные частоты на разных процессорах)

.net stopwatch hal clock bios
person Evgeniy Berezovsky    schedule 05.06.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

это потому, что в документе написано:

Класс Stopwatch помогает манипулировать счетчиками производительности, связанными со временем, в управляемом коде. В частности, поле Frequency и метод GetTimestamp можно использовать вместо неуправляемых Win32 API QueryPerformanceFrequency и QueryPerformanceCounter.

И поэтому возникает необходимость использования счетчика производительности.

Реализация Windows имеет по крайней мере 2 возможных источника для счетчика производительности, HPET, RDTC, и это определяется ACPI. Тем не менее, в основном проблема заключается в ACPI, большинство производителей плохо его реализуют, поэтому иногда принимается решение полностью игнорировать рекомендации ACPI и вместо этого делать что-то другое.

При использовании RDTC миграция потока через другой ЦП приведет к несколько отрицательным результатам, если вам не повезет и если вы все равно измеряете очень маленькое время. Но это может случиться.

person v.oddou    schedule 05.06.2014
comment
Таким образом, вы говорите, что худшее, что может сделать эта ошибка, это привести к тому, что она будет отключена только super small time. Другими словами, даже близко не 1 миллисекунда. - person Evgeniy Berezovsky; 05.06.2014
comment
конечно НЕ 1 мс. больше похоже на 1 микро максимум. но чаще всего разработчиков пугает отрицательная дельта. если какой-то код позже не поддерживает разницу со знаком или предполагает положительность в условиях/ветвлении или расчете (деление, чтобы получить скорость передачи чего-то...) - person v.oddou; 05.06.2014
comment
Под «отрицательными результатами» вы подразумеваете, что результат GetTimestamp() - slightlyEarlierTakenStamp становится отрицательным? В моем конкретном случае это нормально, и «гарантии» отключения только микросекунд здесь более чем достаточно. Просто нужно быть сопоставимым в миллисекундном мире. - person Evgeniy Berezovsky; 05.06.2014
comment
Отлично. на случай, если вы знаете: как они предотвращают дрейф из-за разных частот на процессор? - person Evgeniy Berezovsky; 05.06.2014
comment
Я думаю, что ОС пытается манипулировать частотами, используя базовую виртуальную частоту 1 ГГц, подстраивая фактическое количество RDTSC к этой виртуальной частоте, когда она учитывает ее, путем умножения на какой-то коэффициент виртуальной/реальной частоты. в Linux вы можете получить доступ к частоте ядра в любое время, запросив /sys/devices/system/cpu/cpu0/cpufreq/, окна должны иметь свой собственный путь (deviceIOControl?); Дело в том, что он способен это сделать. В случае, если он использует HPET, у него нет проблем (один источник на материнской плате). - person v.oddou; 05.06.2014