none
Ticks, times, frequencies and all that stuff RRS feed

  • Question

  • Can anyone just confirm a few things for me?

    The MSDN docs are a bit vague when it comes to some of the documentation for ticks. high res timers and so on.

    Assuming a machine DOES have a high res timer, then the static Stopwatch.Frequency field represents the number of high-res-ticks per second, yes or no?

    Next, if I have two high-res-tick values an earlier and later - each obtained from calling the Stopwatch.GetTimestamp() - static method, then the time difference between these in microseconds is:

    ((later_time - earlier_time) / (Stopwatch.Frequency)) * 1000000;

    Yes or no?

    Thanks

    Cap'n


    Tuesday, August 14, 2012 6:02 PM

Answers

  • Yes, on both accounts.  Stopwatch.Frequency is ticks/second, so your math is correct.

    That being said, you need to be careful to use types which will handle the large magnitude of the numbers involved (ie: make sure you do your math using long, not int...)  As such, I'd recommend writing:

    ((later_time - earlier_time) / (Stopwatch.Frequency)) * 1000000L;

    This just makes it safer, later, so if you convert to variables, etc, you don't forget to keep everything using Int64.


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Tuesday, August 14, 2012 6:07 PM
    Moderator

All replies

  • Yes, on both accounts.  Stopwatch.Frequency is ticks/second, so your math is correct.

    That being said, you need to be careful to use types which will handle the large magnitude of the numbers involved (ie: make sure you do your math using long, not int...)  As such, I'd recommend writing:

    ((later_time - earlier_time) / (Stopwatch.Frequency)) * 1000000L;

    This just makes it safer, later, so if you convert to variables, etc, you don't forget to keep everything using Int64.


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Tuesday, August 14, 2012 6:07 PM
    Moderator
  • Yes, on both accounts.  Stopwatch.Frequency is ticks/second, so your math is correct.

    That being said, you need to be careful to use types which will handle the large magnitude of the numbers involved (ie: make sure you do your math using long, not int...)  As such, I'd recommend writing:

    ((later_time - earlier_time) / (Stopwatch.Frequency)) * 1000000L;

    This just makes it safer, later, so if you convert to variables, etc, you don't forget to keep everything using Int64.


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Yes indeed - the range etc is v important - will review logic...

    Thx

    Tuesday, August 14, 2012 6:21 PM
  • BTW - is there a reason you're not just using Stopwatch.Elapsed (or Stopwatch.ElapsedMilliseconds) directly?

    This is far easier and less error prone....


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Tuesday, August 14, 2012 6:23 PM
    Moderator
  • Yes Reed those others are rounded to nearest millisecond - even with a hi-res timer on the motherboard.

    Also a "Tick" as defined inside TimeSpan (returned by the Elapsed property) is different to a "Tick" as defined inside the his-res timer.

    Cap'n




    Wednesday, August 22, 2012 4:29 PM
  • Yes, but Windows isn't a real time operating system - so 100 nanosecond accuracy (TimeSpan.Tick's length) is really better than the OS and program is going to support, especially if you're using managed code where you don't have control over hiccups from GC, etc - All of the framework timers tend to only have accuracies in the 15ms range on most systems, for example...

    What are you trying to do that requires this level of accuracy?  


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Wednesday, August 22, 2012 5:30 PM
    Moderator
  • I have a high performance message based communications component. One of the supported features is "echo test" that causes a message to be sent to remote end of conection and then a reply sent back immediately.

    The sender stamps the msg header with current tick count before sending and does the same when reply comes back, the reply contains the originally sent tick count; this allows round trip time to be measured by using the difference bertween these two tick counts.

    Typically this is in the 100 uS range but sometims is longer or shorter as LAN/machine load varies.

    Windows is indeed not a real-time OS but it can measure time durations down the uS pretty well (if HPET present) even on a laptop here the resolution of the HPET is 0.5 uS.

    On a big desktop the tick duration is 0.3012 uS and two successive calls to Stopwatch.GetTimestamp() usually differ by 1 or 2 and sometimes don't differ.

    Also just to be clear, the Tick value exposed by TimeSpan (100 nS) seems to be just another way of expressing the millisecond time - it does not actually have a 100 nS resolution - the Tick count in Stopwatch though is different and has a true res (depends on hardware) of around 592 nS or in my big dev box's case 301 nS.

    Cap'n








    Wednesday, August 22, 2012 6:01 PM
  • Yes, but Windows isn't a real time operating system - so 100 nanosecond accuracy (TimeSpan.Tick's length) is really better than the OS and program is going to support, especially if you're using managed code where you don't have control over hiccups from GC, etc - All of the framework timers tend to only have accuracies in the 15ms range on most systems, for example...

    What are you trying to do that requires this level of accuracy?  


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    It's useful to measure time in short spans regardless of whether the operating system is capable of scheduling processors on those time scales.

    Timing how long a function took to execute is a good example.  Of course we take measurements of time spans between two points with a grain of salt because we don't know what else the system did between our start and end points, but it certainly creates an upper bound on the length of time something took.

    Intervals of time measurable by the Stopwatch component are on the order of hundreds of nanoseconds.

    Time based scheduling decisions are still driven by the system clock interrupt, which ticks on the order of once every 10 milliseconds by default on a workstation (slower like once every 40 ms on a server OS), and can be configured to tick as fast as once every 1 millisecond.

    Wednesday, August 22, 2012 6:09 PM