2

Please be kind, I'm just learning C# and inheriting this application from a former-employee is my first C# project.

I am observing inconsistent and slow periods with System.Windows.Forms.Timer. The application is written in C# with MS Visual Studio.

The timer is set for an interval of 100 msec yet I am observing periods ranging from 110 msec to 180 msec.

I am using several tools to observe this including: - a SW oscilloscope (the Iocomp.Instrumentation.Plotting.Plot package), - a real oscilloscope, - letting the timer run for some time and comparing the number of ticks * 100 msec to both the system time and to a stopwatch.

In all cases I am observing a 10% lag that becomes evident within the first few seconds.

The methods that are executed with each tick take fewer than 4 msec to run. There is no time-consuming asynchronous processing happening, either. This shouldn't matter, though, as the timer tick is an interrupt, not an event added to an event handler queue (as far as I know).

Has anyone experienced a problem like this before? What were the root causes?

Thanks.

ErikB
  • 21
  • 1
  • 2
  • 1
    looks like this has already been resolved by Andre Saffin [click here for the link](http://stackoverflow.com/questions/21027375/how-to-c-sharp-several-accurate-timers-exactly-for-10-milliseconds-interval) –  Sep 16 '14 at 18:58

4 Answers4

9

Timers are only as accurate as the operating system clock interrupt. Which ticks 64 times per second by default, 15.625 msec. You cannot get a clean 100 msec interval from that, it isn't divisible by 15.625. You get the next integer multiple, 7 x 15.625 = 109.375 msec. Very close to the 110 msec you observed.

You need to add the latency in the handling of the timer notification to this theoretical minimum. Timers have to compete with everything else that's going on in your UI thread. They are treated as the least important notification to be delivered. Sent messages go first, user input goes next, painting is next, timer messages are last. Either way, if you have an elaborate user interface that takes a while to repaint then the Tick event is going to be delayed until that's done. Same for any event handler you write that does something non-trivial like reading a file or querying a dbase.

To get a more responsive timer that doesn't suffer from this kind of latency, you need to use an asynchronous timer. System.Threading.Timer or System.Timers.Timer. Avoid the latter. Their callback runs on a threadpool thread so can get running pretty quickly. Be very careful what you do in this callback, lots of things you cannot do because they are not thread-safe.

You can these timers more accurate by changing the clock interrupt rate. That requires pinvoke, call timeBeginPeriod(). timeEndPeriod() when you're done.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
1

Yes,I always faced this issue with System.Windows.Forms.Timer as it doesnt ticks accurately(most of the time). You can try System.Timers.Timer instead and it raises interrupt precisely(atleast for 100ms precision)

Dark Knight
  • 3,507
  • 8
  • 35
  • 44
0

System.Windows.Forms.Timer is really just a wrapper for the native WM_TIMER message. this means that the timer message is placed in the message queue at time roughly close to the interval you requested (plus or minus... there's no guarantee here). when that message is processed is entirely dependant on other messages in the queue and how long each takes to process. For example, if you block the UI thread (and thus block the queue from processing new messages) you won't get the timer event until after you unblock.

Windows is not a real-time operating system, you can't expect fine-grained accuracy in timers. If you want something more fine-grained, a multimedia timer is the best choice.

Peter Ritchie
  • 35,463
  • 9
  • 80
  • 98
  • Thanks for the response, Peter. I knew Windows is not an RTOS, I just didn't realize how un-realitime it is. I've only worked on embedded devices with an RTOS or an interrupt/queue mechanism I've written myself. Trusting Windows is a whole new thing for me. – ErikB Sep 16 '14 at 19:59
0

This is old, but in case anyone comes here looking for an actually correct answer:

From https://msdn.microsoft.com/en-us/library/system.windows.forms.timer(v=vs.110).aspx (emphasis mine):

The Windows Forms Timer component is single-threaded, and is limited to an accuracy of 55 milliseconds. If you require a multithreaded timer with greater accuracy, use the Timer class in the System.Timers namespace.

So with Windows.Forms.Timer you can get 55ms, 110ms, 165ms, etc.; which is consistent with what you were seeing. If you need higher precision, try System.Timers.Timer or System.Threading.Timer

Ozy
  • 55
  • 1
  • 7