10

I searched this question but didn't see an answer. If it is a duplicate I'll gladly close it.

I am currently trying to do some performance evaluation on a technology and saw some rather unbelievable results so I decided to experiment some. In that I wanted to try and see if the Stopwatch class was returning what I expected.

Stopwatch sw = Stopwatch.StartNew();
Thread.Sleep(1);
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds);

In this case I was pretty much seeing a return value of 15ms. I understand the resolution of DateTime to be around there but shouldn't Thread.Sleep(1) sleep a thread for 1ms? The system I am on returns Stopwatch.IsHighResolution true and its running in .NET 4.

Background: This code in its complete and proper form is intended to gather some numbers on Aerospike db get requests. The DB is not on the same box. When I printed out the sw.ElapsedMilliseconds when a query was in the middle I'm seeing mostly sub millisecond responses and that sounds a little suspect considering my Java equivalent code is returning much more believable 5ms-15ms responses most of the time. The Java code is using the difference of System.nanoTime(). By submilli responses in my C# code I mean Console.WriteLine(sw.ElapsedMilliseconds) prints 0.

Rig
  • 1,276
  • 3
  • 22
  • 43
  • I think for very low amounts, it will take more thank the actual time for a thread to go to sleep and wake up again. I suggest you to try and increment the `sleep()` argument and see in what number the argument and the actual sleeping time will be equal. – Mehraban Sep 28 '13 at 12:24
  • I stepped it up progressively up to about 100 and I was still consistently seeing 5 to 15 ms higher. I understand its not a realtime OS but I didn't expect to see this – Rig Sep 28 '13 at 12:28
  • I wouldn't say its necessarily a duplicate but the answer is there. Should I delete this question? – Rig Sep 28 '13 at 12:59

6 Answers6

36

Timers other than Stopwatch are incremented by the clock interrupt. Which by default ticks 64 times per second on Windows. Or 15.625 milliseconds. So a Thread.Sleep() argument less than 16 doesn't give you the delay you are looking for, you'll always get at least that 15.625 interval. Similarly, if you read, say, Environment.TickCount or DateTime.Now and wait less than 16 millisecond then you'll read the same value back and think 0 msec has passed.

Always use Stopwatch for small increment measurements, it uses a different frequency source. Its resolution is variable, it depends on the chipset on the motherboard. But you can rely on it being better than a microsecond. Stopwatch.Frequency gives you the rate.

The clock interrupt rate can be changed, you have to pinvoke timeBeginPeriod(). That can get you down to a single millisecond and actually make Thread.Sleep(1) accurate. Best not to do this, it is very power unfriendly.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Well, there is always multimedia timers – David Heffernan Sep 28 '13 at 12:38
  • For others coming to this thread, I tested to verify with Mono C# under linux/ubuntu using Thread.Sleep(1) sleeps thread for precisely 1ms. – JaredBroad Sep 10 '14 at 17:55
  • 2
    @JaredBroad -- of course, the issue is Windows specific. (And the answer gives you a clue as to how to "fix" the behavior in windows -- but again, it's power hungry, so, for most scenarios, not worth it.) – BrainSlugs83 Oct 02 '15 at 02:47
  • 1
    This really helped me. Was seeing a simple problem where on my laptop Thread.Sleep of 1ms was about 1-2ms. Where doing the exact same code on my Azure VM was giving me the 15-16ms. Very strange but now we know why! – Matt Watson Oct 15 '16 at 20:20
4

I expect that Thread.Sleep is nothing more than a managed wrapper around the Win32 Sleep API. It is well known that this API function has low resolution. The documentation says this:

This function causes a thread to relinquish the remainder of its time slice and become unrunnable for an interval based on the value of dwMilliseconds. The system clock "ticks" at a constant rate. 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. To increase the accuracy of the sleep interval, call the timeGetDevCaps function to determine the supported minimum timer resolution and the timeBeginPeriod function to set the timer resolution to its minimum. Use caution when calling timeBeginPeriod, as frequent calls can significantly affect the system clock, system power usage, and the scheduler. If you call timeBeginPeriod, call it one time early in the application and be sure to call the timeEndPeriod function at the very end of the application.

After the sleep interval has passed, the thread is ready to run. If you specify 0 milliseconds, the thread will relinquish the remainder of its time slice but remain ready. Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses. For more information, see Scheduling Priorities.

So, you could use timeBeginPeriod and timeEndPeriod as suggested to increase timer resolution, but that's really not to be recommended. If you really need to block for short periods of time then I suggest that you find a better solution. For instance a multimedia timer.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
2

Yes what you've figured out is absolutely correct.

Thread.Sleep doesn't guarantees to release at N milliseconds. It will make sure that Sleep will not release before N milliseconds.

In other words Thread.Sleep(1) means that Sleep for atleast 1 millisecond. Operating system will not schedule the time slice for specific thread for specific amount of time.

The thread will not be scheduled for execution by the operating system for the amount of time specified. This method changes the state of the thread to include WaitSleepJoin.

From Msdn

Sriram Sakthivel
  • 72,067
  • 7
  • 111
  • 189
1

Thread.Sleep(n) means block the current thread for at least the number of timeslices (or thread quantums) that can occur within n milliseconds. The length of a timeslice is different on different versions/types of Windows and different processors and generally ranges from 15 to 30 milliseconds. This means the thread is almost guaranteed to block for more than n milliseconds. The likelihood that your thread will re-awaken exactly after n milliseconds is about as impossible as impossible can be. So, Thread.Sleep is pointless for timing.

OBV
  • 1,169
  • 1
  • 12
  • 25
  • I wasn't actually using Thread.Sleep for timing but rather to validate my extremely fast response times which, as it turns out, were seemingly accurate. I definitely understand your point though. – Rig Oct 08 '13 at 15:39
1

Searching for "thread sleep resolution" brings up these related SO questions:

Consensus is that by default, Sleep() takes at least 15ms, unless you set the resolution using timeBegin/EndPeriod() as in this answer.

Community
  • 1
  • 1
devio
  • 36,858
  • 7
  • 80
  • 143
0

Thread.Sleep(1) will put a thread to sleep for 1ms, but you usually can't get that precision.

However, once thread goes in the sleep state, it takes time for kernel to put it back into the ready queue, and then to put it into the running state when the thread will actually be run again.

All these factors depend on the platform, number of the CPUs, number of the other processes, etc. With non-RT operating system, you can't get any guarantee on this.

Nemanja Boric
  • 21,627
  • 6
  • 67
  • 91
  • Do RT based devices provide a different contract here? This is relevant since I am working on a separate RT compatible application. – Rig Oct 08 '13 at 15:41