 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / June 2004Timer accuracy
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 Lionel Comparing the Timer Classes in the .NET Framework Class Library http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET ----- 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 LJJ schrieb: > 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 [quoted text clipped - 3 lines] > of passes and make appropriate corrections, but having a higher > resolution timer would make things easier. 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. Fabian 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. > 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 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. > 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. 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). > 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. 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
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.