Windows Timer Resolution: The Great Rule Change (2020)

https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/

by todsacerdoti • 5 years ago

42 21 5 years ago

randomascii.wordpress.com

monocasa3• 5 years ago

Does anyone know why hasn't NT become a tickless kernel? Is it some binary compatibility of the drivers thing?

dmitrygr2• 5 years ago

Considering that it is VASTLY better for battery runtime than Linux on same hardware, I guess ticklessness ain't all that important.

monocasa3• 5 years ago

It's just a cleaner design, having implemented a tickless kernel for an RTOS. All of these "what is the actual timer frequency" questions that get more and more complicated as you're doing more (and other contexts are doing more) just sort of disappear.

zlynx• 5 years ago

That is your default Linux configuration. The distros tend to err on the side of functional systems but higher power use.

Start tweaking things like the stuff found in powertop. If your hardware is pretty standard Intel stuff you can get very low. For example, my Dell laptop will idle at 0.5 W with the display off, the SSD, USB, WiFi and PCIe bus all at idle.

That's about 5 days of power on battery. About equal to what any version of Windows can do with Modern Standby settings.

trevorishere• 5 years ago

As of Windows 8, it is tickless (along with XNU and Linux). Windows refers to this as "dynamic tick".

monocasa3• 5 years ago

What this means is that timeBeginPeriod still sets the global timer interrupt interval, on all versions of Window. We can tell from the results of timeGetTime() that the interrupt fires on at least one CPU core at that rate, and the time is updated.

Maybe I'm misunderstanding that sentence, but it doesn't sound tickless. Digging into dynamictick, it sounds like they can suspend the timer interrupt for some ticks, but there's still a regular timer tick going off rather than setting up the timer for each next event like you'd see in a tickless design.

brucedawson4• 5 years ago

Functions like GetTickCount() need to read the tick count which is updated by the interrupt. Changing the behavior of GetTickCount() would be difficult and would likely be less efficient. So, NT can't become completely tickless - there needs to be an interrupt to increment that counter.

Realistically there will almost always be some thread that wants to wake up then so the recurring interrupt probably doesn't cost anything.

mkoc• 5 years ago

Would anyone have an idea how to find out which program set the timer resolution? Would be very helpful in investigating battery drain problems. Any ugly hack is welcome.

abbeyj• 5 years ago

I believe that this is included in the report generated by `powercfg /energy`.

brucedawson4• 5 years ago

powercfg will indeed report on what programs have raised the timer interrupt frequency. However powercfg (and clockres) both just report on the state at a moment in time. Many programs repeatedly raise and then restore the timer interrupt frequency and powercfg utterly fails to understand this. And yet, powercfg is the best that Microsoft has supplied.

I eventually decided to write a better alternative. The batch file below (requires Python and Windows Performance Toolkit to be installed) will report on all timer interrupt changes by all processes over the time period recorded:

https://github.com/google/UIforETW/blob/main/bin/trace_timer...

eznzt• 5 years ago

This is all very weird, and I don’t understand the rationale, or the implementation. The intentional inconsistency in the Sleep(1) delays is particularly worrisome. Maybe it is a bug, but I doubt it.

Why doesn't someone reverse engineer the implementation?

Stratoscope2• 5 years ago

CPUs have historically not been good at keeping accurate time (their clocks intentionally fluctuate to avoid being FM transmitters, and for other reasons)...

This is an interesting point about transmitting FM. I hadn't heard about that before and a quick search didn't enlighten me. I wonder if anyone knows where to read about it? (I understand about unintentional emissions, just not sure how a fluctuating clock frequency would mitigate them.)

nayuki2• 5 years ago

See "spread spectrum" for CPUs: https://www.anandtech.com/show/2500/20

Stratoscope2• 5 years ago

Just what I was looking for, thanks!

brucedawson4• 5 years ago

Interesting reference. I'm not sure I agree with their conclusion that "even the smallest variation in a clocking signal can be enough to create data transfer errors." Citation needed, as the kids say.

Turning your computer into an FM broadcast based on an "as you can imagine" seems like irresponsible advice.

That said, I'm not an EE so if somebody knows more, please educate me.

nayuki2• 5 years ago

The author of the page writes: "This post was an accidental duplicate. The content has been deleted from this copy. You can find the (updated) original here."

Please change the URL from https://randomascii.wordpress.com/2021/01/29/windows-timer-r... to https://randomascii.wordpress.com/2020/10/04/windows-timer-r...

mintplant• 5 years ago

In the future, emailing hn@ycombinator.com will get a faster response.

dang2• 5 years ago

Yup, an email worked. Changed from https://randomascii.wordpress.com/2021/01/29/windows-timer-r.... But this also revealed dupiness: https://news.ycombinator.com/item?id=24684813

dang2• 5 years ago

https://news.ycombinator.com/item?id=24684813

Windows Timer Resolution: The Great Rule Change (2020)

Related Stories