Hi
I have noticed that the time resolution of System.Timers.Timer and System.Threading.Thread.Sleep() varies significantly between systems of seemingly similar class.

For example on my HP Centrino 1.6GHz laptop, I see a resolution of 10ms for the event from System.Timers.Timer and a delay in System.Threading.Thread.Sleep() - e.g. if I change the delay in the latter (in a "highest priority" thread) from 30 ms to 20 ms, I see a change in the delay (although changing from say 30ms to 22ms makes no difference).

On the other hand, on a 2.0 GHz P4 desktop machine, I see a resolution in these same instances of more like 30ms i..e changing from 30ms to 20ms (or even to 15ms) leaves the delay at essentially 30ms.

In both of these cases, the System.Environment.TickCount (which I am using to instrument these cases) seems to have a resolution of 1ms or better

Can anyone tell me where the effective resolution of these timers is obtained on a given system - and also whether there is a way to improve the resolution, as my current project requires timing incoming data with time intervals of the order of 30 ms. I can (and do) keep track of the total number of passes vs. the expected number of passes and make appropriate corrections, but having a higher resolution timer would make things easier.

Thank

----- Gabriele G. Ponti wrote: ----

Comparing the Timer Classes in the .NET Framework Class Librar
http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNE


Gabriele
Thanks for the link which is a nice summary of the different timers (the information is available in the MSDN library, but it is somewhat scattered around). However, I was aware of most of the information in the article and I am definitely using the System.Timers.Timer class and not the Winform timer, so I am not being affected by the 55ms restriction and the effect of the GUI thread. Unfortunately the article does not give a clue as to why the effective resolution of the System.Timers.Timer events should vary signficantly between machines of a similar class

Lione

Comparing the Timer Classes in the .NET Framework Class Library
http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET

LJJ schrieb:

[quoted text, click to view]

I don't think you can obtain the resolution anyhow different than
testing (i.e. create a timer with the minimum resolution and use a
higher-resolution timer with known frequency to test). However, I would
expect the real resolution of the ordinary timers and especially
Thread.Sleep to depend on the scheduler and thus on the number of
processes/threads currently being scheduled.

If you need high precision, you need to p/invoke QueryPerformanceCounter
(very high-res, but only a counter, not a periodic timer) or the Windows
Multimedia Timers (can be adjusted to 1ms accuracy and also include a
notifying timer, see timeGetTime and similar).

BTW: TickCount has a 1ms resolution, but the effictive accuracy is only
about 10 to 55ms, depending on the OS, IIRC.

"LJJ" <anonymous@discussions.microsoft.com> wrote in
news:3F654DB7-73FF-46D3-848E-9DB0F9907C6F@microsoft.com...
[quoted text, click to view]
System.Threading.Thread.Sleep() varies significantly between systems of
seemingly similar class.
[quoted text, click to view]
for the event from System.Timers.Timer and a delay in
System.Threading.Thread.Sleep() - e.g. if I change the delay in the latter
(in a "highest priority" thread) from 30 ms to 20 ms, I see a change in the
delay (although changing from say 30ms to 22ms makes no difference).
[quoted text, click to view]
these same instances of more like 30ms i..e changing from 30ms to 20ms (or
even to 15ms) leaves the delay at essentially 30ms.

In my experience a Centrino 1.6 is the same class as a 3.0 GHz P4...
Anyway: Windows is a preemptive multitasking OS, that is some thread
executes, and from time to time (when a timer interrupt comes in, or when
the active thread ceases control) the task scheduler checks if it's some
other thread's turn to work.
Now, the Sleep routine effectively tells the task scheduler to "ignore" the
current thread for a specified number of timer-interrupts, yielding its
CPU-time to other threads.
So, since the thread-scheduler will usually be invoked every 10 ms or so
(personal experience) Sleep will usually have a resolution of 10 ms.

[quoted text, click to view]
to instrument these cases) seems to have a resolution of 1ms or better.

I think that "DateTime.Now.Ticks" is the most precise timer available in
..net;

Pentium (and higher) processors have an internal clock-tick-counter, (I'm
not 100% sure of the bus or the processor determines its frequency, but it
will usually be > 30 MHz). This value is available through the
QueryPerformanceCounter API. I think DateTime.Now.Ticks internally uses this
API (but again, I'm not 100% sure).

[quoted text, click to view]
obtained on a given system - and also whether there is a way to improve the
resolution, as my current project requires timing incoming data with time
intervals of the order of 30 ms. I can (and do) keep track of the total
number of passes vs. the expected number of passes and make appropriate
corrections, but having a higher resolution timer would make things easier.

The standard response to that kind of problem is: Windows is no realtime-os;
You can never guarantee how long some operation (response time, delay...)
takes.
That said: the Tick-Counters mentioned above are quite precise and reliable;
Sleep&friends weren't designed to be precise: they were desinged to be
cooperative; I'm not sure if you can change the task-scheduler frequency,
maybe you should ask that in some kernel ng.

Where does the "incoming data" come from?
Do you know there's no other delay (e.g. some hardware-buffer)?

Niki

All, Timers are inherently, not reliable in terms of when they fire.
System.Timers.Timer for example, will raise the event you requested, simply
at some unknown time after it was invoked. We can't actually do anything to
change this at the moment, but we do get a lot of feedback indicating
people want more 'teimly' timers: we're looking into it for a future
version. If you are actually TIMING something, then look out for a new
class called 'Stopwatch' in the upcoming beta release of V2.0.

Thread.Sleep specifically simply says 'sleep for a minimum of x'. That is
the only guarantee made: when the thread gets control back is not known.
That's why Sleep is also, not tied that strongly to time.