issue with .NET system.diagnostics stopwatch

Question

i am trying to create an application which incorporates the use of the stopwatch class.

Stopwatch sw = new Stopwatch();
sw.Start();
while (play)
{
    long timer = sw.ElapsedMilliseconds;
    Debug.WriteLine(timer);
}

When i tested this loop and checked the elapsed time, i discovered that the program is missing some milliseconds.

some clockings from the debugger output:

31
32
33
34
35
36
37
38
40 <------39 missed
41
42
43

Any suggestions on how i can solve this issue?

I think that you will probably need to provide more details of what "missing" milliseconds means - perhaps some output. — Neil, Jan 30 '11 at 23:02
when i checked the timer in the debugger output the numbers where not sequential example 1,2,3 then it skips to 5. — RyanB, Jan 30 '11 at 23:03
Oh come on? sometimes it takes more than a millisecond go around your loop - (this seems inordinate long for a simple as your loop is) You should not expect any consistency from call to call on how long any operation should take. Other things are running. If you need to optimize your app get a profiler, if you don't then quit worrying about it. The CPU will not get tired from running unnecessary code. — Neil, Jan 30 '11 at 23:19
Neil if i was running an entire application with lets say 100 or more lines of code i would not be posting here, cause i would understand their might be some performance issue. however i am only executing the code shown in the post — RyanB, Jan 30 '11 at 23:23
why do you *need* your loop to have a consistent running time? You said you need it to be accurate to 10 ms, but why? — jb., Jan 30 '11 at 23:24
What do you want to solve? What do you want to do, exactly? Windows kernel had, and always will have (unless they change something drastically) 10ms task switch resolution. Your CPU wandered of to do something more important for that one ms. — Daniel Mošmondor, Jan 30 '11 at 23:26
well i am trying to do a firing application which on predetermined timings (cues) issues a pulse via rs-232 and communicates with my firing module..with 10ms it would be fine but when i added some extra functionality the inaccuracy was worst — RyanB, Jan 30 '11 at 23:30
The fact that the _other_ lines come in at 1 ms is pure coincidence. Console.WriteLine() is not a reliable timing instrument. — H H, Jan 30 '11 at 23:54
This has been covered before in depth: http://stackoverflow.com/questions/4212611/raise-event-in-high-resolution-interval-timer/4213950#4213950 — Cody Gray - on strike, Jan 31 '11 at 05:13
can anyone suggest a suitable solution? even if it means using another programming language — RyanB, Jan 31 '11 at 12:35

score 5 · Answer 1 · answered Jan 30 '11 at 23:01

5

The miliseconds you're losing is due to the fact that your program isn't the only one running on the OS.

So, once in a while other programs get their time slice, and a few mililseconds are left out.

You can't "fix" it.

answered Jan 30 '11 at 23:01

Yochai Timmer

48,127
24
147
185

Paul Sasik · Answer 2 · 2011-01-30T23:12:08.307

5

Missing milliseconds? Are you expecting to see a entry for every single millisecond tick for a second? E.g. 1000 per second? If so then that will never happen. There is no timing API that is accurate to 1 millisecond.

The fact that you're doing an assignment as well as stream output in the loop where you're outputting the millisecond data in addition to other operating system processes such as task switching means that millisecond accuracy is not possible. You would need a dedicated, real-time machine to pull off the kind of output you're looking for

edited Jan 30 '11 at 23:12

answered Jan 30 '11 at 23:03

Paul Sasik

79,492
20
149
189

2

A great example of the inaccuracy of the timing, is to do it in Silverlight, where the accuracy is only 15ms. – Ray Booysen Jan 30 '11 at 23:06
in my application i need it to be at least accurate to 10ms however when i increased the lines of code and added some functions the timer missed more often and up to 60ms :S – RyanB Jan 30 '11 at 23:14
paul i understand your point, i even tried increasing the application priority to realtime and running the executable file and then on termination i streamed the results to a file, however there were still some errors. the real problem is that when i add some basic functionality as checking that the timer is within some stipulated time, there are more milliseconds left out – RyanB Jan 30 '11 at 23:20
5

Windows is not a realtime operating system. – Lasse V. Karlsen Jan 30 '11 at 23:23
As Lasse has stated, Windows and C# are not real-time so you cannot expect this sort of accuracy. Even with this sort of accuracy, how long will your code run for on each 10ms tick? – Ray Booysen Jan 30 '11 at 23:39

score 0 · Answer 3 · answered Jun 05 '13 at 06:44

A Debug.WriteLine can be slower then 1 millisecond. It isn't optimized for speed.

You could add a call placing the message to a list and then write the list to Debug.WriteLine after running. You could add a background task sending the message to Debug.WriteLine.

Both should prevent the timer from missing ticks.

Another reason for missing ticks might be the OS or another program doing some work between two Debug.WriteLine calls. It might even be a slow machine.

Setting the Thread Priority or running this application on a Dedicated machine should help but these kind of timer issues are expected on Windows since it never said it was a Real Time OS.

issue with .NET system.diagnostics stopwatch

3 Answers3