Discovered more microsoft timer trickery #61

New Issue

reece · 2023-05-12T14:10:43Z

reece commented

2023-05-12 14:10:43 +00:00

They crippled another ucrt api under older operating systems, this time its the steady time api. its nowhere near acceptable. its like, 3-4 orders of magnitude slower. i wont even wait for the test to finish. its just getting stuck.

reece commented

2023-05-12 16:10:17 +00:00

casue: RDSC path isnt being followed

Raymond Chen's profile photo
Raymond Chen
Jun 16, 2000, 8:00:00 AM
to
The reason why QPC doesn't always use RDTSC is twofold.

On multiprocessor systems, you have to make sure that if you
execute RDTSC on both processors simultaneously, they return the
same answer back. Otherwise, an app that gets migrated between
processors is going to see time go backwards.

If a HAL cannot guarantee this behavior, it cannot use RDTSC for
QPC.

On systems where the CPU runs at multiple speeds (laptops with
power management, the new intel speedstep stuff, etc.), you
cannot use RDTSC because it counts cycles, not time. When the
CPU changes speed, the cycles per second changes, which
invalidates the result of QueryPerformanceFrequency.

So if a system supports dynamic CPU speeds, it cannot use RDTSC
for QPC.

(My return address is intentionally invalid to foil spammers. Delete the
".---" to get my real address. I do this on my own time with my own money;
my responses are not to be considered official technical support or advice.
Personal requests for assistance will be ignored.)

casue: RDSC path isnt being followed Raymond Chen's profile photo Raymond Chen Jun 16, 2000, 8:00:00 AM to The reason why QPC doesn't always use RDTSC is twofold. 1. On multiprocessor systems, you have to make sure that if you execute RDTSC on both processors simultaneously, they return the same answer back. Otherwise, an app that gets migrated between processors is going to see time go backwards. If a HAL cannot guarantee this behavior, it cannot use RDTSC for QPC. 2. On systems where the CPU runs at multiple speeds (laptops with power management, the new intel speedstep stuff, etc.), you cannot use RDTSC because it counts cycles, not time. When the CPU changes speed, the cycles per second changes, which invalidates the result of QueryPerformanceFrequency. So if a system supports dynamic CPU speeds, it cannot use RDTSC for QPC. -- (My return address is intentionally invalid to foil spammers. Delete the ".---" to get my real address. I do this on my own time with my own money; my responses are not to be considered official technical support or advice. Personal requests for assistance will be ignored.)

reece commented

2023-05-12 16:18:55 +00:00

https://chromium.googlesource.com/chromium/chromium/+/refs/heads/main/base/time_win.cc more details

reece commented

2023-05-12 16:19:12 +00:00

gonna experiment with different hypervisor clocks

reece commented

2023-05-12 16:39:38 +00:00

semi-fix merged with w7vmm. its no longer stalling for a stupid amount of time, but steady clock is still 8x slower

reece commented

2023-05-12 16:44:11 +00:00

alternative fix is marginally slower

wont fix in runtime; windows kernel hal compatibility defect in hypervisor stack

alternative fix is marginally slower wont fix in runtime; windows kernel hal compatibility defect in hypervisor stack

reece added the

wontfix

label 2023-05-12 16:44:17 +00:00

reece closed this issue

2023-05-12 16:44:19 +00:00

reece changed title from ~~Discovered more microcuckry~~ to Discovered more microsoft trickery

2023-05-12 16:53:16 +00:00

reece changed title from ~~Discovered more microsoft trickery~~ to Discovered more microsoft timer trickery

2023-05-12 16:53:24 +00:00

reece commented

2023-05-12 17:04:20 +00:00

Test: 20. Hello Time

Microsoft NT

When comparing steady clock to wall clock is:
8x slower: (~7s vs ~700ms) - you are running an older operating system with a HAL that does not trust your chipset;
434x slower: (05:04 vs ~700ms) - you are running on broken hardware or a system configuration;
Abs: ~3seconds - you are running a modern system under modern windows;
Abs: ~6 seconds - you are running under old windows with aurora runtime, or modern windows using dumb-cunt code microsoft devs knowingly refuse to improve upon

Noting regular desktops and modern virtual machines will be much much faster, most likely beating wall clock or residing in the same ballpark. Also noting, 6 something seconds is still possible if you're braindead enough to use and trust Microsoft code. Namely, the STL and its' high-res clock. 3s is a 2x improvement over the stock STL clocks. I don't have the exact perf characteristics of wall clock under win11 at hand.

## Test: 20. Hello Time ### Microsoft NT When comparing steady clock to wall clock is: 8x slower: (~7s vs ~700ms) - you are running an older operating system with a HAL that does not trust your chipset; 434x slower: (05:04 vs ~700ms) - you are running on broken hardware or a system configuration; Abs: ~3seconds - you are running a modern system under modern windows; Abs: ~6 seconds - you are running under old windows with aurora runtime, or modern windows using dumb-cunt code microsoft devs knowingly refuse to improve upon Noting regular desktops and modern virtual machines will be much much faster, most likely beating wall clock or residing in the same ballpark. Also noting, 6 something seconds is still possible if you're braindead enough to use and trust Microsoft code. Namely, the STL and its' high-res clock. 3s is a 2x improvement over the stock STL clocks. I don't have the exact perf characteristics of wall clock under win11 at hand.

Sign in to join this conversation.