Здравствуйте, Sinix, Вы писали:
S>поведение задокументировано:
Дык, коню понятно, что при манипуляциях с образом остановленной VM могут быть какие угодно глюки из-за подмены виртуализованного TSC реальным. Но я-то этим не занимаюсь, у меня резкие скачки TSC наблюдались именно в непрерывно работающих VM, раз в несколько секунд.
S>И ещё вопрос, какой hardware version выставлен?
8. Но фишка в том, что семерка и первая восьмерка таких эффектов никогда не давали, а вот 8.1/10 — давали регулярно.
S>врало оно всегда, но не в таких масштабах.
О чем и речь. При помощи отключения виртуализации TSC я в коде под гостевой системой могу измерять микросекундные интервалы с достаточно высокой точностью. Конечно, показания скачут иногда и на десятки миллисекунд, но, если отбросить подобные эксцессы, средние значения измерений очень хорошо согласуются с теми, что получаются непосредственно на железе.
В принципе, меня не заломает доплатить за апгрейд WS до десятой версии, но основные глюки 8.0.6 я давно знаю и умею их обходить, а в десятке придется наступать на грабли снова. Пока не хочется тратить время на обнаружение и обход глюков, поэтому и хочу сохранить 8.0.6 хотя бы до лета.
Re[2]: Чертовщина со временем в виртуалках с Win8/10
В качестве быстрого и точного таймера для отладочных целей я давно использую 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, но оттуда, похоже, уже давно ушли все сколько-нибудь толковые люди.
Но как, Холмс? Напомню, в параметрах виртуалок стоит запрет перехвата RDTSC — то есть, VMM честно исполняет гостевую RDTSC на хостовом процессоре. Поскольку в хостовой системе никаких сбоев в работе TSC не наблюдается, возникает подозрение, что восьмерки/десятка перехватывают RDTSC и в ядре тоже. Если это так, то зачем это делается, и почему не удается найти на этот счет никакой информации? Если винда RDTSC не перехватывает — отчего значения TSC внезапно и резко меняются?
У меня была похожая проблема. Вылечил переходом на одно ядро. Счетчики ядер разбегаются из-за штрафных тактов, поэтому при пе ключе ни на другое ядро может быть скачок времени.
Здравствуйте, кт, Вы писали:
кт>Счетчики ядер разбегаются из-за штрафных тактов
Расхождение счетчиков разных ядер последний раз имело место в процессорах AMD выпуска середины-конца первой декады 2000-х, а у Intel, начиная с Core Duo, его вообще никогда не было (у меня i7-3610QM).
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, кт, Вы писали:
кт>>Счетчики ядер разбегаются из-за штрафных тактов
ЕМ>Расхождение счетчиков разных ядер последний раз имело место в процессорах AMD выпуска середины-конца первой декады 2000-х, а у Intel, начиная с Core Duo, его вообще никогда не было (у меня i7-3610QM).
переход на одно ядро легко проверить
Скачки у меня были на компьютере 2007 года выпуска
Здравствуйте, кт, Вы писали:
кт>переход на одно ядро легко проверить
Зачем проверять то, чего не может быть, поскольку этого не может быть никогда?
Сами подумайте: если бы TSC расходились между ядрами — как я мог этого совершенно не замечать на протяжении многих лет пользования процессорами Core 2 Duo/Quad и i7? И как может получиться так, что TSC меняется сразу на несколько секунд? Даже в худших AMD столь ужасающего расхождения не бывало никогда. И почему это наблюдается только в виртуалках с Win8/10, а с XP/2k3/Win7 — никогда?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Недавно стал обнаруживать странное поведение отлаживаемого софта под гостевыми восьмерками/десяткой. Поскольку под ними я тестирую мало, поначалу не обращал внимания, но вчера потребовалось проверить пристально, и обнаружилось, что под ними TSC периодически резко меняется на несколько секунд. И ладно бы это было только в user-mode, но и в ядре происходит то же самое.
Здравствуйте, flаt, Вы писали:
F>Правильно ли я понимаю, что проблема была в HPET у VMWare 8.0?
С эмуляцией HPET была проблема в поддержке системного времени (часов/таймеров), а тут резко меняется значение, возвращаемое непосредственно rdtsc.
Хотя, возможно, включение эмуляции HPET в WS 8.0 принудительно включает и перехват rdtsc, даже если он отключен собственным параметром — надо будет это проверить.
Re[3]: Чертовщина со временем в виртуалках с Win8/10
Здравствуйте, 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, а бывает, что за месяц ни разу не упадет.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Поскольку гипервизор 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 выставлен? От него тоже зависит, см табличку тут.
В общем, вопрос скорее в "как оно работало раньше?", чем "почему сломалось?". Потому что судя по вот этому, врало оно всегда, но не в таких масштабах.
Напомню, в параметрах виртуалок стоит запрет перехвата RDTSC — то есть, VMM честно исполняет гостевую RDTSC на хостовом процессоре. Поскольку в хостовой системе никаких сбоев в работе TSC не наблюдается, возникает подозрение, что восьмерки/десятка перехватывают RDTSC и в ядре тоже. Если это так, то зачем это делается, и почему не удается найти на этот счет никакой информации? Если винда RDTSC не перехватывает — отчего значения TSC внезапно и резко меняются?
