Anders
Anders

Reputation: 17554

Is Thread.Sleep now using high res timer or have Windows 10 changed default system clock frequency?

Thread.Sleep used to be tied to the system clock which clocked in at a interval at roughly 16 ms, so anything below 16ms would yield 16ms sleep. The behaviour seems to have changed some way down the line line.

What has changed? Is Thread.Sleep no longer tied to the system clock but to the high res timer? Or has the default system clock frequency increased in Windows 10?

edit: It seems people are intersted in knowing why I use Thread.Sleep, its actually out of the scope of the question, the question is why the behavior have changed. But anyway, I noticed the change in my open source project freepie https://andersmalmgren.github.io/FreePIE/

Its a input/output emulator which is controlled by the end user using Iron python. That runs in the background. It has no natural interrupts. So I need to marshal the scripting thread so it does not starve an entire core.

Upvotes: 4

Views: 906

Answers (2)

Anders
Anders

Reputation: 17554

Thanks to Hans Passant comment which I first missed I found the problem. It turns out Nvidias driver suit is the problem maker.

Platform Timer Resolution:Outstanding Timer Request A program or service has requested a timer resolution smaller than the platform maximum timer resolution. Requested Period 10000 Requesting Process ID 13396 Requesting Process Path \Device\HarddiskVolume2\Program Files\NVIDIA Corporation\NVIDIA GeForce Experience\NVIDIA Share.exe

This is so idiotic on so many levels. In the long run this is even bad for the environment since any computer with nvidia will use more power.

edit: Hans Comment, relevant part:

Too many programs want to mess with it, on top of the list is a free product of a company that sells a mobile operating system. Run powercfg /energy from an elevated command prompt to find the evildoer, "Platform Timer Resolution" in the generated report.

Upvotes: 1

Nick
Nick

Reputation: 5042

The newer hardware does have a more precise timer, indeed. But the purpose of Thread.Sleep is not to be precise, and it should not be used as a timer.

It is all in the documentation:

If dwMilliseconds is less than the resolution of the system clock, the thread may sleep for less than the specified length of time. If dwMilliseconds is greater than one tick but less than two, the wait can be anywhere between one and two ticks, and so on.

Also very important is that after the time elapses, your thread is not automatically run. In stead, the thread is marked as ready to run. This means that it will get time only when there are no higher priority threads that are also ready to run, and not before the currently running threads consume their quantum or get into a waiting state.

Upvotes: 0

Related Questions