Чертовщина со временем в виртуалках с Win8/10
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 29.12.15 10:45
Оценка:
В качестве быстрого и точного таймера для отладочных целей я давно использую TSC. На железе у меня стоят только XP и Win7 (32/64), а Win8/8.1/10 — только в виртуалках под VMware Workstation (сейчас 8.0.6, раньше были 5.x-6.x).

Поскольку гипервизор VMware по умолчанию перехватывет RDTSC, в настройках большинства виртуалок стоит запрет перехвата (monitor_control.virtual_rdtsc = false). В итоге точное измерение даже наносекундных интервалов внутри гостевых систем уже лет десять работает совершенно чудесно. Таким образом, под XP/Win7 — как на железе, так и в виртуалках — до недавних пор проблем не возникало.

Недавно стал обнаруживать странное поведение отлаживаемого софта под гостевыми восьмерками/десяткой. Поскольку под ними я тестирую мало, поначалу не обращал внимания, но вчера потребовалось проверить пристально, и обнаружилось, что под ними TSC периодически резко меняется на несколько секунд. И ладно бы это было только в user-mode, но и в ядре происходит то же самое.

Но как, Холмс? Напомню, в параметрах виртуалок стоит запрет перехвата RDTSC — то есть, VMM честно исполняет гостевую RDTSC на хостовом процессоре. Поскольку в хостовой системе никаких сбоев в работе TSC не наблюдается, возникает подозрение, что восьмерки/десятка перехватывают RDTSC и в ядре тоже. Если это так, то зачем это делается, и почему не удается найти на этот счет никакой информации? Если винда RDTSC не перехватывает — отчего значения TSC внезапно и резко меняются?

Кстати, это может быть связано со странным поведением времени в гостевых восьмерках/десятках под Workstation 8.0.6: если запустить запись/воспроизведение звука — системное время начинает тормозить в полтора-два раза, а через несколько секунд после остановки звукового потока начинает "догоняться" ускоренным темпом. Спрашивал об этом на форуме VMware, но оттуда, похоже, уже давно ушли все сколько-нибудь толковые люди.
Re: возможно виновата многоядерность
От: кт  
Дата: 31.01.16 05:34
Оценка:
Но как, Холмс? Напомню, в параметрах виртуалок стоит запрет перехвата RDTSC — то есть, VMM честно исполняет гостевую RDTSC на хостовом процессоре. Поскольку в хостовой системе никаких сбоев в работе TSC не наблюдается, возникает подозрение, что восьмерки/десятка перехватывают RDTSC и в ядре тоже. Если это так, то зачем это делается, и почему не удается найти на этот счет никакой информации? Если винда RDTSC не перехватывает — отчего значения TSC внезапно и резко меняются?

У меня была похожая проблема. Вылечил переходом на одно ядро. Счетчики ядер разбегаются из-за штрафных тактов, поэтому при пе ключе ни на другое ядро может быть скачок времени.
Re[2]: возможно виновата многоядерность
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 31.01.16 06:11
Оценка:
Здравствуйте, кт, Вы писали:

кт>Счетчики ядер разбегаются из-за штрафных тактов


Расхождение счетчиков разных ядер последний раз имело место в процессорах AMD выпуска середины-конца первой декады 2000-х, а у Intel, начиная с Core Duo, его вообще никогда не было (у меня i7-3610QM).
Re[3]: возможно виновата многоядерность
От: кт  
Дата: 31.01.16 06:36
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, кт, Вы писали:


кт>>Счетчики ядер разбегаются из-за штрафных тактов


ЕМ>Расхождение счетчиков разных ядер последний раз имело место в процессорах AMD выпуска середины-конца первой декады 2000-х, а у Intel, начиная с Core Duo, его вообще никогда не было (у меня i7-3610QM).


переход на одно ядро легко проверить
Скачки у меня были на компьютере 2007 года выпуска
Re[4]: возможно виновата многоядерность
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 31.01.16 07:23
Оценка:
Здравствуйте, кт, Вы писали:

кт>переход на одно ядро легко проверить


Зачем проверять то, чего не может быть, поскольку этого не может быть никогда?

Сами подумайте: если бы TSC расходились между ядрами — как я мог этого совершенно не замечать на протяжении многих лет пользования процессорами Core 2 Duo/Quad и i7? И как может получиться так, что TSC меняется сразу на несколько секунд? Даже в худших AMD столь ужасающего расхождения не бывало никогда. И почему это наблюдается только в виртуалках с Win8/10, а с XP/2k3/Win7 — никогда?
Re: Чертовщина со временем в виртуалках с Win8/10
От: flаt  
Дата: 02.02.16 14:41
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Спрашивал об этом на форуме VMware, но оттуда, похоже, уже давно ушли все сколько-нибудь толковые люди.


Правильно ли я понимаю, что проблема была в HPET у VMWare 8.0?
Re: Чертовщина со временем в виртуалках с Win8/10
От: Sinix  
Дата: 02.02.16 14:49
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Недавно стал обнаруживать странное поведение отлаживаемого софта под гостевыми восьмерками/десяткой. Поскольку под ними я тестирую мало, поначалу не обращал внимания, но вчера потребовалось проверить пристально, и обнаружилось, что под ними TSC периодически резко меняется на несколько секунд. И ладно бы это было только в user-mode, но и в ядре происходит то же самое.


Пальцем в небо: не оно?
Re[2]: Чертовщина со временем в виртуалках с Win8/10
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 02.02.16 16:20
Оценка:
Здравствуйте, flаt, Вы писали:

F>Правильно ли я понимаю, что проблема была в HPET у VMWare 8.0?


С эмуляцией HPET была проблема в поддержке системного времени (часов/таймеров), а тут резко меняется значение, возвращаемое непосредственно rdtsc.

Хотя, возможно, включение эмуляции HPET в WS 8.0 принудительно включает и перехват rdtsc, даже если он отключен собственным параметром — надо будет это проверить.
Re[2]: Чертовщина со временем в виртуалках с Win8/10
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 02.02.16 16:24
Оценка: 19 (1)
Здравствуйте, Sinix, Вы писали:

S>не оно?


Не, то другой глюк. Хотя, возможно, тот как-то связан с поддержкой HPET.
Re[3]: Чертовщина со временем в виртуалках с Win8/10
От: flаt  
Дата: 02.02.16 18:14
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

Просто пост на том форуме выглядит как "я нашёл, в чём проблема", вот и решил уточнить.
Re[4]: Чертовщина со временем в виртуалках с Win8/10
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 03.02.16 07:05
Оценка:
Здравствуйте, flаt, Вы писали:

F>Просто пост на том форуме выглядит как "я нашёл, в чём проблема", вот и решил уточнить.


Там была речь о том, что в Win 8.1/10 под WS 8 начинало тормозить время при включенной поддержке HPET и увеличении разрешения таймера до единиц миллисекунд. Это действительно вылечилось запретом HPET в параметрах VM. Тут ничего странного нет — Win 8.1/10 использует HPET для таймеров высокого разрешения и, если он криво реализован в WS 8, глюки со временем вполне могут иметь место.

А вот резких скачков самого TSC я объяснить не могу. Или включение поддержки HPET в VM принудительно включает и перехват rdtsc, независимо от параметра "monitor_control.virtual_rdtsc", или Win 8.1/10 сама перехватывает rdtsc даже в потоках ядра, но тогда возникает вопрос, для чего она это делает.

Впрочем, сейчас у меня не получилось воспроизвести эти скачки, хотя тогда они совершенно точно наблюдались в VM с Win 8.1/10 при многократных перезагрузка гостевых систем, но не возникали в параллельно работающих VM с XP/7/8.

Но я уже привык к подобной мистике — например, у меня периодически начинают регулярно (по многу раз за день) валиться VM с любыми виндами где-то в глубине DbgPrint, а бывает, что за месяц ни разу не упадет.
Re: Чертовщина со временем в виртуалках с Win8/10
От: Sinix  
Дата: 03.02.16 07:31
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Поскольку гипервизор VMware по умолчанию перехватывет RDTSC, в настройках большинства виртуалок стоит запрет перехвата (monitor_control.virtual_rdtsc = false). В итоге точное измерение даже наносекундных интервалов внутри гостевых систем уже лет десять работает совершенно чудесно. Таким образом, под XP/Win7 — как на железе, так и в виртуалках — до недавних пор проблем не возникало.


Полистал мануал — похоже, поведение задокументировано:

You can disable virtualization of the TSC by adding the setting monitor_control.virtual_rdtsc = FALSE to
the virtual machine’s .vmx configuration file. This feature is no longer recommended for use. When you disable
virtualization of the TSC, reading the TSC from within the virtual machine returns the physical machine’s TSC
value, and writing the TSC from within the virtual machine has no effect
. Migrating the virtual machine to another
host, resuming it from suspended state, or reverting to a snapshot causes the TSC to jump discontinuously. Some
guest operating systems fail to boot, or exhibit other timekeeping problems, when TSC virtualization is disabled.


И ещё вопрос, какой hardware version выставлен? От него тоже зависит, см табличку тут.

В общем, вопрос скорее в "как оно работало раньше?", чем "почему сломалось?". Потому что судя по вот этому, врало оно всегда, но не в таких масштабах.
Re[2]: Чертовщина со временем в виртуалках с Win8/10
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 05.02.16 06:57
Оценка: 19 (1) +1
Здравствуйте, Sinix, Вы писали:

S>поведение задокументировано:


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

S>И ещё вопрос, какой hardware version выставлен?


8. Но фишка в том, что семерка и первая восьмерка таких эффектов никогда не давали, а вот 8.1/10 — давали регулярно.

S>врало оно всегда, но не в таких масштабах.


О чем и речь. При помощи отключения виртуализации TSC я в коде под гостевой системой могу измерять микросекундные интервалы с достаточно высокой точностью. Конечно, показания скачут иногда и на десятки миллисекунд, но, если отбросить подобные эксцессы, средние значения измерений очень хорошо согласуются с теми, что получаются непосредственно на железе.

В принципе, меня не заломает доплатить за апгрейд WS до десятой версии, но основные глюки 8.0.6 я давно знаю и умею их обходить, а в десятке придется наступать на грабли снова. Пока не хочется тратить время на обнаружение и обход глюков, поэтому и хочу сохранить 8.0.6 хотя бы до лета.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.