Windows Timer Resolution: The Great Rule Change (2020) | Hacker News Reader

Windows Timer Resolution: The Great Rule Change (2020)

randomascii.wordpress.com

42 pointstodsacerdoti21 comments

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

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...

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

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

> 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.)

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

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.

Just what I was looking for, thanks!

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

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

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.

What did you do for timer coalescing? If every thread can request a custom wakeup time then power consumption goes up. If wakeups are coalesced then what algorithm do you use to coalesce them, and how much movement in wakeup times do you allow? Depending on how you coalesce timers you can very easily find yourself reinventing the basics of what Windows does.

The Windows system also gives you a very cheap to read timer counter which is a nice attribute.

The Windows system is frustrating, especially for those who don't understand it, but it does have some excellent attributes.

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.

5 years ago I would have done that. And I did. A number of times. it never even approaches the runtime of Windows. Nowadays, I don't waste my time. I pay Microsoft for windows license, and do all my work in a Linux VM. Believe it or don't, this produces longer battery lives.

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.

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

> 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.

>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?

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.

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

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...

Reply on news.ycombinator.com