dcsimg
Results 1 to 30 of 30

Thread: Stopwatch Resolution

  1. #1

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Stopwatch Resolution

    Quote Originally Posted by JohnW2 View Post
    What about the 'sensitivity' though? I still haven't seen ...Elapsed.TotalMilliseconds ever produce more than 4 decimal places (whereas Double could obviously provide far more than that). Is that down to Stopwatch, or maybe even hardware?
    Quote Originally Posted by jmcilhinney View Post
    Not sure but perhaps look at the Ticks property to see whether it provides higher resolution.
    Having investigated, the documentation says …

    The timer used by the Stopwatch class depends on the system hardware and operating system. IsHighResolution is True if the Stopwatch timer is based on a high-resolution performance counter. Otherwise, IsHighResolution is false, which indicates that the Stopwatch timer is based on the system timer.
    The latter lower-resolution option (“based on the system timer”) is elsewhere referred to as “using the Datetime Class”

    On my machine, Stopwatch.IsHighResolution is True and Stopwatch.Frequency gives 10,000,000 (Hz, ticks per second), thereby indeed corresponding with the resolution of “4 decimal places of milliseconds” I have been seeing - i.e. a resolution of 0.0001 milliseconds (0.1 microseconds, 100 nanoseconds).

    I’ve yet to discover what determines whether a particular machine uses the high or low resolution option, what determines exactly what the high resolution is (CPU clock frequencies are orders of magnitude higher 10 MHz) or whether there is any user control over any of this.

    Kind Regards, John

  2. #2
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,619

    Re: Stopwatch Resolution

    It depends on the timer clock chip being used, which is independent of the CPU clock, which the CPU clock can speed up and slow down to save power or control heat, so wouldn't be a good timing source.

    On older machines, the HighResolutionTimer was usually around 3.58 Mhz, to correspond with the frequency of the signal used to encode color information in NTSC TV signals. Now that everything has pretty much gone digital, and the old analog NTSC signal is mostly irrelevant, the board manufacture can choose to implement a high resolution timer circuitry with whatever clock frequency chip they choose, or they can choose not to implement one at all, most likely on very inexpensive computing platforms.

    So, if high resolution timer hardware is not built in, then the stopwatch has to resort to using the system timer for timing.

    You don't control the frequency of the High resolution timer, it is built in by the manufacture. That is why the flag is there to tell you if they have one or not, and why they provide the frequency so you can calculate the number of ticks per period you are interested in.

    You can access these values through API calls. The stopwatch object just wraps this functionality up for you so you don't have to.

    Having the clock tick at 10,000,000 times per second is much more convenient than the older 3,579,545 (give or take a tick) per second.

    You do realize that you have elapsed ticks available in addition to elapsed milliseconds or total milliseconds.
    If you know the frequency of the ticks, then I would just use the elapsed ticks value to calculate the passage of time rather than total Milliseconds.
    Last edited by passel; Nov 27th, 2019 at 11:04 AM.
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  3. #3

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    It depends on the timer clock chip being used, which is independent of the CPU clock, which the CPU clock can speed up and slow down to save power or control heat, so wouldn't be a good timing source.
    Thanks. That makes sense.

    Quote Originally Posted by passel View Post
    You don't control the frequency of the High resolution timer, it is built in by the manufacture. That is why the flag is there to tell you if they have one or not, and why they provide the frequency so you can calculate the number of ticks per period you are interested in.
    Fair enough. Again, that makes sense.

    Quote Originally Posted by passel View Post
    Having the clock tick at 10,000,000 times per second is much more convenient than the older 3,579,545 (give or take a tick) per second.
    Indeed so, at least for humans and 'mental arithmetic'. However, I'm not sure that the computer necessarily regards the two numbers particularly differently (i.e. they are both 'just numbers'!), even though one is far more 'round' .

    Quote Originally Posted by passel View Post
    You do realize that you have elapsed ticks available in addition to elapsed milliseconds or total milliseconds. If you know the frequency of the ticks, then I would just use the elapsed ticks value to calculate the passage of time rather than total Milliseconds.
    Yes, I did realise that, but I assumed that the computer would be just as competent as me (or my code) at dividing by 10^7, so I didn't see any reason not to trust its milliseconds figure. Why would you prefer to calculate it yourself?

    Kind Regards, John

  4. #4
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,619

    Re: Stopwatch Resolution

    Quote Originally Posted by JohnW2 View Post
    ..., but I assumed that the computer would be just as competent as me (or my code) at dividing by 10^7, so I didn't see any reason not to trust its milliseconds figure. Why would you prefer to calculate it yourself?
    ...
    I suppose it is because stopwatch.ElapseMilliseconds is a Long type and I wanted more precision, I went to stopwatch.ElapseTicks. And the calculation to convert to the units you want, i.e microseconds or nanoseconds would be the same we been using for years with the API calls for the High Resolution Timer so just continuing with what was already familiar.

    Stopwatch.Elapsed returns a timespan and since I hadn't dealt with timespan objects much, I guess I ignored it for the most part. Multiplying Stopwatch.Elapsed.TotalMilliseconds to get microseconds or nanoseconds, seems like a reasonable thing to do. I don't know if there is any significant time difference between accessing the ElaspeTicks value of the stopwatch object compared to accessing the TotalMilliseconds property of the timespan object within the stopwatch object. It is a couple of extra levels of access to get to the property, but that is what object oriented is all about.
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  5. #5

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    I suppose it is because stopwatch.ElapseMilliseconds is a Long type and I wanted more precision, I went to stopwatch.ElapseTicks.
    Fair enough, but if you had used Stopwatch.Elapsed.TotalMilliseconds you would have got the answer as a Double, to the maximum degree of precision available from the system/hardware.

    Quote Originally Posted by passel View Post
    I don't know if there is any significant time difference between accessing the ElaspeTicks value of the stopwatch object compared to accessing the TotalMilliseconds property of the timespan object within the stopwatch object.
    I can't see why access time should be relevant after one has 'stopped' the stopwatch - the number of ticks recorded (the maximum precision available) will (unless the stopwatch is re-started) presumably be the same even if one accesses it 6 weeks later If one wants' say, milliseconds, then someone (with or without instruction from the programmer) has to calculate that from 'ticks', but I wouldn't expect the time taken for that to differ in the two situations.

    As I explained to jmc (in the 'other thread'), I understood the difference between te Elapsed.Milliseconds and Elapsed.TotalMilliseconds properties of timespan, but I thought (incorrectly) that the two would be the same if (as was the situation I had), I knew that the other components of timespan (days, hours, minutes and seconds) would all be zero. As I wrote to jmc, what I hadn't realised is that, whilst Elaspsed.Milliseconds was Integer, Elapsed.TotalMilliseconds was (like all the ".Totalxxxx" properties) Double.

    I think that, had I been designing it, I would probably have done things slightly differently with timespan. By definition, all but the smallest individual properties (i.e. Elapsed.Days, Elapsed.Hours, Elapsed.Minutes & Elapsed.Seconds) are all necessarily integers, but it would seem logical that the smallest component (i.e. Elapsed.Milliseconds) should be non-integer (i.e. Double). All of the "Totalxxx" properties are, of course, necessarily non-integer, so the situation 'as is' (all Double) is what one would expect.

    Kind Regards, John

  6. #6
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,619

    Re: Stopwatch Resolution

    I usually don't "stop" the stopwatch.
    I use if for regulating the timing of transfers over interfaces, so I'll check the elapsed time many times per second as part of the regulation mechanism, with more precision and accuracy than using a timer tick event to regulate the transfers.
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  7. #7

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    I usually don't "stop" the stopwatch. I use if for regulating the timing of transfers over interfaces, so I'll check the elapsed time many times per second as part of the regulation mechanism, with more precision and accuracy than using a timer tick event to regulate the transfers.
    Oh, that obviously moves the goalposts quite a long way from what I was doing and talking about - since the obvious way to time the execution of a code segment is (per the code I posted in the other thread) to start and stop the stopwatch immediately before and after the code segment of interest.

    In your situation, one is obviously at the mercy of the access time, and I don't think it would be too easy to investigate that. However, in that situation you are presumably right to favour using elapsed ticks (rather than .TotalMilliseconds), since things will then at least not be complicated by the time taken for the 'ticks to milliseconds' conversion.

    In terms of what I recently wrote about how I would probably have designed timespans, it has occurred to me that the situation is really analogous to the use of non-metric measurement units. One could, if one wished, express a weight as ‘fractional’ (i.e. not integer) stones, pounds or ounces (e.g. “7.345 pounds” or, equivalently, "117.52 ounces") and that is analogous to the .Totalxxx properties of timespan (all Double).

    However, more commonly, one would express a weight in “Stones, Pounds and Ounces”. In that case, all but the smallest of those components (i.e. Stones and Pounds) are necessarily integers (analogous with ‘Elapsed.Days, .Elapsed.Hours etc.), but the smallest one (Ounces) is logically (if one wants higher precision) non-integer - so that one can have, for example “3 stones, 1 pound and 4.6 ounces". Following that logic, I would be inclined to think that it would be logical for just .Elapsed.Milliseconds (but not .Elapsed.Days etc.) to be non-integer (i.e. Double)

    Kind Regards, John

  8. #8
    Frenzied Member
    Join Date
    Jul 2011
    Location
    UK
    Posts
    1,269

    Re: Stopwatch Resolution

    Quote Originally Posted by JohnW2 View Post
    On my machine, Stopwatch.IsHighResolution is True and Stopwatch.Frequency gives 10,000,000 (Hz, ticks per second), thereby indeed corresponding with the resolution of “4 decimal places of milliseconds” I have been seeing - i.e. a resolution of 0.0001 milliseconds (0.1 microseconds, 100 nanoseconds).

    The display of 4 significant decimal places is not due to the frequency of your StopWatch being 10 MHz. The StopWatch could have a frequency of 1MHz, 10,000Hz or 100Hz and you'd still see 4 decimal places being displayed for stopwatch.Elapsed.TotalMilliseconds.

    That's because, as JMC pointed out in your previous thread, the StopWatch.Elapsed property is a TimeSpan object, nothing (directly) to do with the StopWatch Class or its frequency. So what you are actually displaying is timespan.TotalMilliseconds.

    A TimeSpan value represents DateTime Ticks. A 'tick' is a notional time interval of 100ns. i.e. 1/10,000,000 of a second, hence timespan.TotalMilliseconds has a resolution of 0.0001 milliseconds.

    It's worth pointing out that the StopWatch Class has an ElapsedTicks Property. StopWatch ticks are not the same thing as DateTime ticks. Coincidentally, with your StopWatch.Frequency being 10,000,000 Hz they will have the same value. However, those of us who don't have such a high frequency timer will see different values. For example, the following code shows me:

    StopWatch frequency: 3312685
    DateTime ticks: 10000410
    StopWatch ticks: 3312821

    Code:
    Dim startTime = Now
    
    Dim sw = Stopwatch.StartNew
    Do
    Loop Until (Now - startTime).TotalSeconds > 1
    sw.Stop()
    
    Console.WriteLine($"StopWatch frequency: {Stopwatch.Frequency}")
    Console.WriteLine($"DateTime ticks: {sw.Elapsed.Ticks}")
    Console.WriteLine($"StopWatch ticks: {sw.ElapsedTicks}")

  9. #9

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by Inferrd View Post
    The display of 4 significant decimal places is not due to the frequency of your StopWatch being 10 MHz. The StopWatch could have a frequency of 1MHz, 10,000Hz or 100Hz and you'd still see 4 decimal places being displayed for stopwatch.Elapsed.TotalMilliseconds. .... That's because, as JMC pointed out in your previous thread, the StopWatch.Elapsed property is a TimeSpan object, nothing (directly) to do with the StopWatch Class or its frequency. So what you are actually displaying is timespan.TotalMilliseconds. ... A TimeSpan value represents DateTime Ticks. A 'tick' is a notional time interval of 100ns. i.e. 1/10,000,000 of a second, hence timespan.TotalMilliseconds has a resolution of 0.0001 milliseconds.
    Yes, I now understand most of that, but I think I may have been getting a bit confused by the fact that, on my machine, StopWatch ticks and DateTime ticks are the same frequency. However, what you say also confuses me a bit. If, on your machine, 10 MHz DateTime ticks are available, why on earth would/does Stopwatch use lower frequency ones (for its .ElapsedTicks)? Indeed, if both are available, why would .net ever use the lower frequency one for anything?

    What you say certainly seems to cast some doubt on the wisdom of the suggestion previously made that one should perhaps use .ElapsedTicks (and convert to milliseconds, if required) rather than .Elapsed.TotalMilliseconds since, at least on your machine, that would presumably result in lower precision.

    Kind Regards, John

  10. #10
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,619

    Re: Stopwatch Resolution

    I don't know that he was saying that a 10 MHz DateTime tick clock was available (note the word notional).
    He said that a tick in DateTime represents 100ns of time, so it is a constant unit. It doesn't necessarily represent the speed of any clock used by anyone to set the timespan value.

    Remember the lowly timer control in VB6, and the WinForm timer in .Net.
    The interval is specified in milliseconds, but that doesn't mean that you will get millisecond resolution. It is just the units used to specify the an amount of time.
    The actual clock speed that Windows used that drove the timer was programmable, so the actual resolution could be pretty much anything. By default over the last 20 years or so, it seems to have defaulted to 64hz, or 15.625ms per actual tick, but it may still be programmable through an API call, I don't know. I'm pretty sure it still was in Win7.
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  11. #11

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    I don't know that he was saying that a 10 MHz DateTime tick clock was available (note the word notional). He said that a tick in DateTime represents 100ns of time, so it is a constant unit. It doesn't necessarily represent the speed of any clock used by anyone to set the timespan value.
    As I said, I was a bit confused by what he was saying, but he seemed clear enough about the situation with his machine when he wrote:

    Quote Originally Posted by Inferrd View Post
    For example, the following code shows me:

    StopWatch frequency: 3312685
    DateTime ticks: 10000410
    StopWatch ticks: 3312821
    If his code, running on his machine, could see (and count) the 10MHz 'DateTime ticks', why would Stopwatch (or anything else) use some lower frequency timer that was also available?

    Kind Regards, John

  12. #12
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,619

    Re: Stopwatch Resolution

    The code runs for approximately a second, and then displays the ticks that passed.
    Since Date Time says one tick represents 100ns of time, then one second would be 10 million ticks of time, so would display around 10 million regardless of whatever resolution of timer the passage of time is compared against.

    If I run the following code on my laptop that I'm typing this post in right now.
    Code:
    Public Class Form1
    
      Dim sw As New Stopwatch
    
      Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
    
        Dim startTime = Now
        Dim ts1 As Long
        Dim ts2 As Long
        sw.Start()
    
        ts2 = sw.Elapsed.Ticks
        Do
          ts1 = sw.Elapsed.Ticks
        Loop Until ts2 <> ts1
        Do
          ts2 = sw.Elapsed.Ticks
        Loop Until ts2 <> ts1
        Do
          ts1 = sw.Elapsed.Ticks
        Loop Until ts2 <> ts1
    
        Debug.Print("Resolution: {0} nanoseconds", (ts1 - ts2) * 100)
        Debug.Print("StopWatch frequency: {0}", Stopwatch.Frequency)
        sw.Stop()
    
      End Sub
    End Class
    The majority of the time, the smallest value I get is:
    Code:
    Resolution: 100 nanoseconds
    StopWatch frequency: 10000000
    I ran the code on an older machine which has the previous High Resolution clock standard of some value a bit over 3 million ticks per second, and I got the following results
    Code:
    Resolution: 300 nanoseconds
    StopWatch frequency: 3222565
    So, if I ran Inferrd's code on either machine it would report that the amount of time in TimeSpan Ticks that passed in one second would be around 10 million, because ticks is being used as a unit of time equal to 100 ns.

    You are measuring time in units of tick, you are not counting ticks.

    Based on the fact that it reports that 300 ns is the minimum amount of time between one TimeSpan Tick change and the next, then the clock in theory should be 3,333,333 hz. That is close to the 3,222,565 High Resolution Timer.

    The TimeSpan Tick is in units of 100 ns, so the choices for the passage of time in nanoseconds will be multiples of that, i.e. 100, 200, 300, etc...
    It is reporting 300 ns, because given the clock speed of 3,222,565 the actual time between High Resolution Timer ticks on this machine would be around 310.312 ns.

    Hopefully that clears up what I was saying that the tick value in time span is a unit of time, and indicates how much time in units of tick have passed, not a count of how many ticks have occurred.
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  13. #13

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    Hopefully that clears up what I was saying that the tick value in time span is a unit of time, and indicates how much time in units of tick have passed, not a count of how many ticks have occurred.
    I'm afraid that I'm still rather confused, and therefore need to do some thinking and playing, and gets my thoughts straight, before I can really respond usefully - watch this space!

    Kind Regards, John

  14. #14
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,619

    Re: Stopwatch Resolution

    It boils down to the TimeSpan saying that x amount of time has passed. It has nothing to do with the resolution of whatever is keeping track of the time.
    If I note the time on the clock with a second hand when someone says go, and then note the time on the clock when someone says stop, and then they ask me how many seconds went by, I could answer with something like 15 seconds.
    If they then asked my how many microseconds went by, I could say 15 million, give or take.
    If they ask me how many grimels was that, I would have to ask what a grimel was.
    Oh, a grimel is 100 milliseconds.
    Oh, in that case around 150 grimels went by.

    That is what the timeSpan tick is. It is a unit of time, i.e. a grimel that is 100ns long.
    What units you use to define the passage of time in this case is just a mathematical unit conversion. It doesn't say to what resolution your actual observation or measurement was.
    If I have a measurement of a distance in inches, down to an inch resolution, I can convert that to millimeters, but that wouldn't make the original measurement more precise. You have a value in millimeters that is accurate to plus or minus 1/2 an inch, assuming there was rounding in the first measurement to the nearest inch.

    That is what the timespan tick value was on Inferrd and my older machine. It was a measurement in ticks to the nearest 310.312 ns (on my machine).
    If we actually captured the elapsed time in nanoseconds with each tick of the High Resolution timer, the timespan values on my machine would be as follows.
    Code:
    Clk            SW Tick  TS Tick
        0            0        0
      310.311816     1        3
      620.623633     2        6
      930.935450     3        9
    1,241.247267     4       12
    1,551.559084     5       16  assuming TS tick rounds to nearest elapsed time
    1,861.870900     6       19
    So, the TS tick represents time in 100ns increments, but only updates its tick value every 300+ ns.

    While the TimeSpan Ticks represents units of 100ns, that doesn't mean that some timer behind the scene was ticking at that rate.
    Likewise, as you mentioned, the CPU clocks are running in the GHZ range, so if you had a high resolution timer that ran at 1Ghz, the 100ns unit of time for the TimeSpan would not increase. It would still report the passage of time in ticks representing 100ns, even if the clock being read was ticking at a 1ns interval.
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  15. #15

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    So, the TS tick represents time in 100ns increments, but only updates its tick value every 300+ ns. While the TimeSpan Ticks represents units of 100ns, that doesn't mean that some timer behind the scene was ticking at that rate.
    [ throughout this, I will be talking about ‘old’ machines in which the stopwatch ticks are at ~300 ns intervals but the DateTime/TimeSpan ones at 100 ns intervals. Trying to think/talk about the ‘modern’ situation (like my machines) in which both are 100 ns just gets my head totally tied up in knots! ]

    Anyway, I think I fully understand what you've written in your last two posts. I initially thought that people were suggesting that there were two separate timers/clocks at work, but I soon realised that such was not the case.

    I think what I am missing is an understanding of the 'why' of all this.

    If the (hardware) timer/clock one has is generating ticks at, say, 300 ns intervals, that is what it is generating, and nothing ‘better’ is available. As per your various analogies, if one has a ruler that can only measure in feet, virtually nothing (and absolutely nothing in terms of ‘information’ or precision) is gained by expressing the results in inches - that simply means that the only possible answers are 12, 24, 36 etc., rather than 1, 2, 3 etc.

    … and the same seems to me to be true of these ticks. If what is available (from the timer) are intervals of 1, 2, 3, 4 etc. 300 ms intervals, then I find it very hard to see what is gained by, instead, regarding that as 3, 6, 9, 12 etc. 100 ns intervals. As with the ruler, there is no different/additional information/precision available. Indeed, such a conversion will presumably result in some loss of accuracy if the interval generated by the timer (300 ns or whatever) is not an exact multiple of 100 ns (just as would be the case, if one were using integers, if a foot were not an exact multiple of an inch).

    So, if I am now understanding the situation correctly and thinking straight, the one other thing I need to understand is what is gained by DateTime & TimeSpan using these rather contrived ‘derived' ticks, rather than the actual ('accurate') ticks from the timer/clock, as seemingly used by Stopwatch.

    If the reason is simply because the fixed 100 ns is a ‘nice round number’ that makes it fractionally easier to convert to actual time, that would seem a very trivial reason - a computer will not notice much difference between diving by 10 and diving by 3.xxxx.

    What am I missing or not understanding?

    Kind Regards, John

  16. #16
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,619

    Re: Stopwatch Resolution

    I assume it is just to provide a convenient unit that is a finer resolution of time time than the microsecond, i.e. a tenth of a microsecond.
    This is for the users benefit, and has nothing to do with computer calculation. I'm not sure what value you are saying you would want the TimeSpan Tick to represent.

    A TimeSpan tick will always nominally represent a span of time equal to 1/10 of a microsecond.
    The typical user may not be interested in having to go to the effort of finding out the frequency of the high resolution timer, then using that to calculate the period of a tick, to turn high resolution timer ticks into as accurate point of time as possible.

    You even said that yourself. You would just use the TotalMilliseconds value which is based on the TimeSpan object, which will give you the time rounded to the nearest 1/10th of a microsecond of the most recent tick of the high resolution timer. The fact that the high resolution timer is ticking slower than 1/10th of a microsecond as in the past, or may be ticking faster than 1/10th of a microsecond possibly in the future, is not something most would care about.

    And if it is something you care about, then you can use the Stopwatch Ticks and the Stopwatch Frequency to figure out the true interval that the timer has stepped, i.e. the numbers in the first column in post 14 rather than multiplying the number in the third column by 100.
    (of course, from a high level language, and those short of intervals, how accurate can you actually be since the code has to take a measurable amount of time just to access the object and get the value, which could swamp the value at that point).

    Since the stopwatch already supports getting to the "raw" values of the high resolution timer, why would someone who used the timespan object to track the span of time want to replicate that functionality and have to do those conversions when using the timespan object.

    Of course it is easy 20 years after the fact, to say why didn't you just use ElapsedNanoSeconds for a property rather than this theoretical Tick property?
    But it isn't really that odd of a thing to do, as similar things have been done many times in the past.

    We have the Inch, but printers needed something finer to work with so an inch was divided into 72 parts called points, and you used points when describing fonts, etc... It was a finer unit of measurement, but probably not all equipment would support positioning to the resolution of one point, but it gave you a common standard tied to the hardware pieces used in printing presses. And then when printers starting allowing dots to be printed at much finer resolution than points, the Twip was invented to divide the point into 20 parts, so you had 1440 twips per inch. Again, a somewhat arbitrary choice, but your 300 dpi, 600 dpi and 1200 dpi printers could convert twips to dots to define coordinates that directly related back to points, and were rounded to the nearest dot position the printer supported.

    Likewise, mouse driver coordinates used a scale that was essentially based on subunits of the screen width and height (i.e. a binary representation of percentage). If didn't matter the number of pixels in height, or pixels in width the screen was, the mouse driver always used "Mickeys", a 16-bit value so the full width of the screen or the full height of the screen was notionally 65536 mickeys wide and high, so the size of the mickey was different in relation to pixels in X and Y. It was up to the interface to the driver to convert mickey distances into pixel distances. The 16-bit range for position was just a convenience and allowed the hardware to use device independent method of describing the position of the mouse.

    Work on .Net started in the late 1990's, and I'm sure at the time that choosing 100ns for the unit of time that a tick would represent for the TimeSpan object seemed more than adequate. Also, you can fit 100 times more ticks in your variable type, giving you a larger range of time that can be held in the variable before overflowing than if the tick represented 1 ns.

    I doubt anyone would have thought that having the TimeSpan tick represent a variable span of time based on some hardware dependency would be a sensible thing to do.
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  17. #17

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    I assume it is just to provide a convenient unit that is a finer resolution of time time than the microsecond, i.e. a tenth of a microsecond.
    This is for the users benefit, and has nothing to do with computer calculation. ……. The typical user may not be interested in having to go to the effort of finding out the frequency of the high resolution timer, then using that to calculate the period of a tick, to turn high resolution timer ticks into as accurate point of time as possible.
    OK. There’s probably not much more that needs to be said about this, since it seems that the situation really is as ‘simple’ as I thought, the perceived reasons for it ‘being as it is’ being essentially ones which you are describing as matters of perceived ‘convenience’ (opinions about which will obviously vary) - in other words, along the lines of what I wrote …

    Quote Originally Posted by JohnW2
    If the reason is simply because the fixed 100 ns is a ‘nice round number’ that makes it fractionally easier to convert to actual time, that would seem a very trivial reason - a computer will not notice much difference between diving by 10 and diving by 3.xxxx.
    (those numbers obviously related to a conversion to microseconds)

    Quote Originally Posted by passel View Post
    I'm not sure what value you are saying you would want the TimeSpan Tick to represent.
    What I’m really saying is that I don’t see why there have to be two different types of ‘tick’. In other words, I don't see why the 'TimeSpan tick' needs to exist at all.

    As I see it, there are essentially two ways in which ‘ticks’ can be used. …

    Firstly (and probably not all that commonly) one might to work just with ‘ticks’ (without being concerned about the precise intervals between those ticks). In that situation, all that matters is how often the value changes (i.e. how many unique values there are in any particular period of time), and that is going to be the same (approximately equal to the interval of the actual timer), regardless of what units one may use or what ‘derivation’ of ticks one might make from the primary (i.e. ‘Stopwatch’ ones).

    In the second (I would think much more common) situation, the user/programmer is going to be interested in actual time intervals (in milliseconds/whatever), in which case the ticks (whatever ticks) have to be converted into actual time (milliseconds or whatever), using the timer (‘Stopwatch’) frequency. However, despite what you appear to be implying above, that does not have to be done (and rarely would be done) by the user/programmer, since the computer can and will do it ‘automatically’ (and ‘transparently’, as far as the user is concerned).

    Indeed, there might even be scope for an improvement in performance here - IF (I don’t know!) the ‘secondary ticks’ are derived from the ‘primary’ ones continuously (i.e. millions of times per second), I would have thought that the conversion would only actually be needed very occasionally if time was derived from ticks only ‘when required’.

    The bottom line is that, in either of those situations, I don’t really see why the ‘secondary ticks’ are really needed. Am I overlooking some other 'situations' which could arise?

    Quote Originally Posted by passel View Post
    Work on .Net started in the late 1990's, and I'm sure at the time that choosing 100ns for the unit of time that a tick would represent for the TimeSpan object seemed more than adequate. Also, you can fit 100 times more ticks in your variable type, giving you a larger range of time that can be held in the variable before overflowing than if the tick represented 1 ns.
    True, but I don’t think that’s of any practical relevance. As above, I don’t really see why we need these ‘derived ticks’ at all but, if we are to have them, even if the tick represented 1 ns, the Long variable type (which is what is used) would allow intervals up to just under 300 years to be timed and stored (in ns) - and that would obviously far exceed the lifespan of both the hardware and any user

    Quote Originally Posted by passel View Post
    I doubt anyone would have thought that having the TimeSpan tick represent a variable span of time based on some hardware dependency would be a sensible thing to do.
    As above, I don’t really see any problem with that. As I’ve said, if one’s application is such that one is happy to work with ticks (without being concerned about the precise intervals between them), then one just uses those ticks - in the situation we're discussing, nothing would be gained by using 10 MHz ticks rather than, say, 3.3 MHz ones, since they would simply change value about 3 times less frequently. If, more commonly, one is interested in actual time intervals (milliseconds or whatever), one just lets the computer (which knows the frequency of those ticks) undertake the conversion, in a manner that is transparent to the user.

    I’m having some difficulty in thinking of any situation in which it would even be ‘more convenient’ to have ‘derived ticks’ which were in ‘nice round units of actual time’ (like 100 ns) - since I would think that would only be a consideration when one was interested in ‘actual time’, in which case one would presumably be using the computer’s conversion to actual time (e.g. milliseconds), and therefore would probably not even know how many ticks (or whatever sort/size) that actual time interval corresponded to. As always, perhaps I’m missing something!

    Kind Regards, John

  18. #18
    Frenzied Member
    Join Date
    Jul 2011
    Location
    UK
    Posts
    1,269

    Re: Stopwatch Resolution

    Quote Originally Posted by JohnW2 View Post
    What I’m really saying is that I don’t see why there have to be two different types of ‘tick’. In other words, I don't see why the 'TimeSpan tick' needs to exist at all.

    Two different types of tick??? If only!!! There's millions of the beggars

    I mean no offence, but the written word can be difficult to interpret correctly, so it's not obvious to me whether or not you properly understand the difference between StopWatch ticks and a TimeSpan/DateTime 'tick'.

    There's a hardware clock that increments a number (3.3 million times a second on my machine). When you first call Start on the StopWatch class, it records the value of the hardware clock's number at that instant. When you later call the StopWatch's Stop method or read its ElapsedTicks property, the number is read again and the difference from the first number is calculated and stored. In this way the StopWatch keeps a running total of how many clock ticks have been generated by the hardware clock while the StopWatch has been running.

    In contrast, the TimeSpan/DateTime 'tick' has nothing to do with clock or timer ticks. It is just an unfortunately and confusingly named unit of time measurement.

    Microsoft could have chosen a day or an hour to be the length of that 'tick' time unit, but they decided on 100ns, presumably as a trade off between maximising precision and maximising the length of time duration that the TimeSpan or DateTime Structures could store.

  19. #19

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by Inferrd View Post
    I mean no offence, but the written word can be difficult to interpret correctly, so it's not obvious to me whether or not you properly understand the difference between StopWatch ticks and a TimeSpan/DateTime 'tick'.
    There's a hardware clock that increments a number (3.3 million times a second on my machine). When you first call Start on the StopWatch class, it records the value of the hardware clock's number at that instant. When you later call the StopWatch's Stop method or read its ElapsedTicks property, the number is read again and the difference from the first number is calculated and stored. In this way the StopWatch keeps a running total of how many clock ticks have been generated by the hardware clock while the StopWatch has been running.
    In contrast, the TimeSpan/DateTime 'tick' has nothing to do with clock or timer ticks. It is just an unfortunately and confusingly named unit of time measurement.
    Certainly no offence taken! It's probably not that easy to see, since some of the posts have been lengthy and rather 'rambling' (as probably will be the case with this one!), but if you looked carefully at my recent posts, particularly the last couple, I think you would see that I now fully understand all that.

    However, in terms of 'confusion', I think it's probably somewhat 'worse' than you imply. As you do say, to use “Ticks” to refer to something which is a unit of time measurement (but which has nothing to do with any physical 'ticks') is bad enough, but it actually seems to get treated as if it were 'ticks', rather than just a unit ascribed to something that was actually a measurement of time.

    For example, as you say, StopWatch’s ElapsedTicks property returns the number of (real) ticks which have passed during the interval in question, but then we also have “Elapsed.Ticks” which seems to return essentially the same thing, but converted into actual time, in units of 100 ns. I would suggest that no-one who wasn’t ‘in the know’ would have even dreamed that “Elapsed.Ticks’ referred to a measurement of the actual time duration of an interval, in any units!

    Am I right in assuming that Elapsed.Ticks is derived from the actual clock ticks (as in ElapsedTicks) in exactly the same way as is, say, Elapsed.TotalSeconds or Elapsed.TotalMilliseconds? If so, one wonders why they even bothered to have the confusing ‘Elapsed.Ticks’ - if they insisted on a unit of 100 ns, rather than 1ns (see below), it would have been ‘consistent’, and much less confusing had they called it Elapsed.Total100nanoseconds (rather than Elapsed.Ticks). For total consistency, they might also have had to make it Double, rather than Long - but that should only lose, at worse, 1 significant figure of precision, which I presume is an irrelevance unless the speed of hardware clocks rises by at least an order of magnitude.

    In fact, since it is all ‘decimal’ after minutes, I suppose that all Elapsed.Totalxxxx properties below Seconds are, in a sense, redundant, since all that differs (in these Double variables) is the position of the decimal point - so that (certainly with a 3.3 MHz or 10 MHz clock) even the .TotalSeconds property should have a precision of at least 100 ns.

    Given that it was essentially arbitrary, it’s perhaps a pity that they didn’t choose 1 ns (rather than 100 ns) (see below) since the Elapsed.Ticks property could then have been called Elapsed.TotalNanoseconds (tidier than the “Elapsed.Total100Nanoseconds” hypothesised above!) - and, if that had been done, there would be absolutely no confusion or uncertainty as to what it was!

    Quote Originally Posted by Inferrd View Post
    Microsoft could have chosen a day or an hour to be the length of that 'tick' time unit, but they decided on 100ns, presumably as a trade off between maximising precision and maximising the length of time duration that the TimeSpan or DateTime Structures could store.
    As I wrote recently, I don’t really understand this as a reason/’excuse’ for their not having used 1 ns - since, as I said, the Long variable type used for these things would then still enable one to measure and store time intervals up to almost 300 years - far far longer than the lifetime of any computer or user! … and, as above, had they chosen 1 ns, then I think that things could probably have been made far less confusing!

    Kind Regards, John

  20. #20
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,619

    Re: Stopwatch Resolution

    Quote Originally Posted by JohnW2 View Post
    ...
    Am I right in assuming that Elapsed.Ticks is derived from the actual clock ticks (as in ElapsedTicks) in exactly the same way as is, say, Elapsed.TotalSeconds or Elapsed.TotalMilliseconds? If so, one wonders why they even bothered to have the confusing ‘Elapsed.Ticks’ - if they insisted on a unit of 100 ns, rather than 1ns (see below), it would have been ‘consistent’, and much less confusing had they called it Elapsed.Total100nanoseconds (rather than Elapsed.Ticks). ...
    It sounds like you're thinking that the .Net framework and all the objects that are part of it had a single mind behind it.
    That isn't the way it works. This is an object oriented world, and most objects are not developed by the same person or team.

    I can well imagine that the TimeSpan Class was developed independently of the Stopwatch Class.
    And possibly late in the development by the Stopwatch class developer(s), someone said, "Hey, it is probably likely that people will want to use the stopwatch time in conjunction with Dates and TimeSpans, so rather than have the user have to instantiate a Timespan object and convert some Stopwatch properties into TimeSpan properties, we'll just add a Timespan object as a property in our class. And since the Stopwatch is used for tracking Elaspsed time from some reference time, we'll call the property Elapsed and the user can access the timespan properties through that.

    Perhaps someone may have noticed the TimeSpan Class also had a property called Ticks, and I don't know if there would have been a way to hide that property in the instantiated version within the StopWatch class, but if they did, then perhaps someone used to TimeSpan class would wonder what happened to the Ticks property of the TimeSpan class.

    And I wouldn't assume the TimeSpan Class and the Stopwatch Class code is using the same code to calculate their respective Ticks value. The TimeSpan instance would be using its class code of course. That is the whole point of including using another class object in your class, so you don't have to write all the code that that class already provides.

    I'm pretty sure that the code from both make use of the High Resolution Timer, if one is available, because that is the purpose of the High Resolution Timer, i.e. to provide a stable high frequency counter to provide high resolution time period tracking.

    As for the choice of 100 ns intervals vs 1 ns intervals for TimeSpan ticks, I don't know. It could be backlash related to the "complaint" that when people specified a time in milliseconds for the old system timer and the true value was nowhere near a millisecond, that they decided since the time interval was not likely to be a true 1 ns, or 10 ns anytime soon, so lets go with 100ns as that will be likely true at some point in the nearer future and is a nice round figure. Who's going to use the tick value anyway, since we provide TotalMilliseconds.

    There is also the possibility that using 100 ns gives the counter around a 3000 year range, which Pope Gregory the 13ths new calculations for the calendar back in 1582 also made the calendar accurate to within a day over about a 3000 year span. Coincidence?
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  21. #21

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    It sounds like you're thinking that the .Net framework and all the objects that are part of it had a single mind behind it. That isn't the way it works. This is an object oriented world, and most objects are not developed by the same person or team.
    I realise that. Maybe, by trying to “please too many people for too much of the time”, they have created something that is too complicated for it’s own (and users’) good - i.e. something “which confuses a good few for a fair bit of the time”?! … or maybe what we are seeing is the result of a less-than-ideal degree of communication, collaboration and co-ordination between individual/groups developing different bits of this super-complex animal?

    Quote Originally Posted by passel View Post
    I can well imagine that the TimeSpan Class was developed independently of the Stopwatch Class.
    Almost certainly, I would imagine.

    However having, as you say, decided to have a TimeSpan object as a property of StopWatch (so that TimeSpan properties could be accessed), why did they then decide to include StopWatch.Elapsed.Ticks, when essentially the same information, hopefully calculated in the same way, was already available (in a property with a much less confusing name!) as StopWatch.Elapsed.TotalMilliseconds? After all, no one 'forced’ them to include the Elapsed.Ticks property. As you subsequently say yourself:

    Quote Originally Posted by passel View Post
    Who's going to use the tick value anyway, since we provide TotalMilliseconds.
    Although your question is rhetorical, I’ll answer it - by saying that I see no reason why anyone would ever have a need to. However, quite apart from the undesirability of having ‘unnecessary things’ in a language which is already extremely complex, if the ‘ticks’ property did not exist, the likes of poor me would have been spared a few days of confusion and a good few forum posts!

    Quote Originally Posted by passel View Post
    And I wouldn't assume the TimeSpan Class and the Stopwatch Class code is using the same code to calculate their respective Ticks value.
    I never intended to imply that they were necessarily using the same code, merely that they were making the conversion (of the same thing) ‘in the same way’ - i.e (as I understand it) dividing the number of physical ‘ticks’ of a hardware timer by the frequency to get an actual time interval. If they are using different code and getting different answers for the same mathematical division, I would suggest that someone must have got their code a little wrong

    Quote Originally Posted by passel View Post
    I'm pretty sure that the code from both make use of the High Resolution Timer, if one is available, because that is the purpose of the High Resolution Timer, i.e. to provide a stable high frequency counter to provide high resolution time period tracking.
    On the basis of what everyone has written, that’s certainly what I’ve been assuming in what I have recently been writing.

    Quote Originally Posted by passel View Post
    There is also the possibility that using 100 ns gives the counter around a 3000 year range, which Pope Gregory the 13ths new calculations for the calendar back in 1582 also made the calendar accurate to within a day over about a 3000 year span. Coincidence?
    Well, the number is the same but, beyond that, I’m not sure of the connection between 1 day in 3000 years and 100 ns in 3000 years - which seem to be rather dramatically different concepts!

    Kind Regards, John

  22. #22
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,619

    Re: Stopwatch Resolution

    Quote Originally Posted by JohnW2 View Post
    ...
    However having, as you say, decided to have a TimeSpan object as a property of StopWatch (so that TimeSpan properties could be accessed), why did they then decide to include StopWatch.Elapsed.Ticks, .
    They didn't decide to include StopWatch.Elapsed.Ticks.
    Elapsed is a TimeSpan object and Ticks is a public property of the System.TimeSpan object, so it comes with the instance.

    If they didn't want to expose a puplic property of the TimeSpan object, then I assume you would not use a Visible TimeSpan object named Elaspsed in your class, but have a private instance of the class, and create separate properties of the StopWatch object to create a layer between the user and those internal properties, or wrap the TimeSpan (including by inheritance as a form of wrapping) in another embeded class within the TimeSpan object to provide a single property to expose a limited set of TimeSpan properties though your embedded class.

    So instead of a property that exposes an already developed class instance, you feel that the developers should have written their own class to wrap the class to limited the exposure of the Timespan class methods and properties, or added more properties to their class to shield the user from those properties of the TimeSpan object.

    That sounds like a lot of extra work for not much benefit. And if they wrap it in their own embedded class, it kind of defeats the purpose of providing a TimeSpan instance in their class so you don't have to create one.

    Fortunately, you can always write your own class to wrap up an instance of the stopwatch class and not expose any of the properties and methods that you think might be confusing, especially to people who don't want to explore the documentation on the classes they are using (that F1 key or Shift-F2 key are pretty hard to type).

    Actually this seems like the epitome of a moot point. It can be debated endlessly, but there isn't much point in it because nothing can be resolved. You're talking about Code and Classes that were written 20 years ago. If you were proposing to write your own Framework, rather than using .Net, then debating these things and creating a list of what you would have done differently would make sense. These are .Net classes, and have nothing to do with the languages that use them, so it isn't a VB thing.

    I can understand discussion for the purpose of understanding how something work, and perhaps why it works that way, but complaining about the choices made has never really made a lot of sense or had much appeal to me, unless you have a constructive means to change it.
    Last edited by passel; Dec 2nd, 2019 at 07:54 PM.
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  23. #23

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    They didn't decide to include StopWatch.Elapsed.Ticks.
    Elapsed is a TimeSpan object and Ticks is a public property of the System.TimeSpan object, so it comes with the instance.
    You're right - my thinking went all wrong and ended up with my probably asking the wrong question - my apologies. I think that the question I probably should have asked is nothing to do with Stopwatch but, rather, all to do with TimeSpan, namely .... why does TimeSpan provide both .Ticks and .TotalMilliseconds? They appear to be essentially the same thing, indicating the length of an interval to the nearest 100 ns (.TotalMilliseconds appears to be rounded to that precision), the only differences being the shift of the decimal point (in .TotalMilliseconds) and the fact that .TotalMilliseconds is Double, rather than Long (which means that accuracy {at least with incredibly long intervals} within the capacity of the Long type of .Ticks).

    Quote Originally Posted by passel View Post
    I can understand discussion for the purpose of understanding how something work, and perhaps why it works that way, but complaining about the choices made has never really made a lot of sense or had much appeal to me, unless you have a constructive means to change it.
    I totally agree. I am usually not particularly happy when I see others engaging in essentially non-productive "how it might have been" discussions, and am therefore sorry that I got dragged (or dragged myself!) into this one!

    As you will recall, I started this thread because, in another one, I asked why I was seeing only 4 decimal places (i.e. "to the nearest 100 ns") in figures returned by TotalMilliseconds, given that the Double type was capable of much 'more' than that (with any real-world intervals) - I asked whether that was due to StopWatch, hardware or what. When jmc said that he wasn't sure, but suggested that the Ticks property might provide higher resolution, I started this thread in order to try to find the answer!

    I now know (from the discussion in this thread) that the 100ns resolution is, indeed, down to 'hardware' and that, despite what jmc thought might be the case, TotalMilliseconds and .Ticks are (as above) essentially the same thing, both with a resolution of 100 ns.

    The 'trouble' started when you wrote, in the very first response (post #2), that you would use Ticks, rather than TotalMilliseconds, leading me to at least initially think that there was a material difference (and therefore asking you 'why?') - and the rest, as they say, "is history". However, I have nevertheless found it to be quite an interesting discussion, from which I have (incidentally) learned a good few other things - so many thanks for your contributions!

    Kind Regards, John

  24. #24
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,619

    Re: Stopwatch Resolution

    Quote Originally Posted by JohnW2 View Post
    ...
    The 'trouble' started when you wrote, in the very first response (post #2), that you would use Ticks, rather than TotalMilliseconds, leading me to at least initially think that there was a material difference (and therefore asking you 'why?') ...
    Yes, I guess so, and I didn't catch that you were referring to .Elapsed.Ticks (a Timespan property), where I was referring to .ElapsedTicks (a Stopwatch property).

    The stopwatch properties allow you to get to the raw High Resolution Timer values, whereas the TimeSpan provides convenient re-scaled versions of those values in various units of time. As I mentioned, I have never used the TimeSpan based versions, so wasn't even aware of using TotalMiliseconds or Ticks from the .Elapsed property.

    The Stopwatch ticks and frequency wrap the High Resolution Timer values that we would have used from our VB6 days, so it was a natural transition. I didn't explore beyond that, assuming that was as good as it got.

    In your case since the High Resolution Timer frequency matches the 100 ns unit time period that the TimeSpan uses as its base unit of time for all other units, ElapsedMilliseconds and StopWatch.Ticks represent the same amount of time.
    I suspect that could be the reason that on your computer, and my more recent laptop that a 10 Mhz counter is being used for the High Resolution Timer, in order for those values to match.

    But historically, with lower and somewhat flexible High Resolution Timer frequencies (i.e. see the 3.xxx Mhz values from my machine vs Inferrd's), you would have to calculate the period of the Stopwatch Tick to get the most accurate timer available. The TimeSpan.TotalMilliseconds or TimeSpan.Tick would be an aliased version of the Stopwatch Tick the majority of the time.

    By using a 10Mhz counter, they have removed the aliasing of the TimeSpan tick, and the TimeSpan.TotalMilliseconds values, so now TimeSpan.Ticks and Stopwatch Ticks are in sync and are now fully redundant (but not on everyone's machines).
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  25. #25
    Powered By Medtronic dbasnett's Avatar
    Join Date
    Dec 2007
    Location
    Pointless Forest 38.517,-92.023
    Posts
    9,226

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    ...By using a 10Mhz counter, they have removed the aliasing of the TimeSpan tick, and the TimeSpan.TotalMilliseconds values, so now TimeSpan.Ticks and Stopwatch Ticks are in sync and are now fully redundant (but not on everyone's machines).
    Wonder if there are any recent PC's that are not running with a frequency of 10,000,000? I do recall a time when that wasn't the case.

    Thank goodness that instances of Stopwatch have timespans.
    My First Computer -- Documentation Link (RT?M) -- Using the Debugger -- Prime Number Sieve
    Counting Bits -- Subnet Calculator -- UI Guidelines -- >> SerialPort Answer <<

    "Those who use Application.DoEvents have no idea what it does and those who know what it does never use it." John Wein

  26. #26

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    Yes, I guess so, and I didn't catch that you were referring to .Elapsed.Ticks (a Timespan property), where I was referring to .ElapsedTicks (a Stopwatch property).
    [ if anyone doesn't agree with me that this terminology is (undesirably/unnecessarily) confusing, then I'm not sure that they are on the same planet as me ]

    ... and don't forget that that was at a time when I hadn't grasped the concept of what TimeSpan ticks were (and were not) - so when you just wrote that you would use "elapsed ticks" (without specifying which 'ticks'), rather than TotalMilliseconds, I did not really know/understand what you were talking about, either!

    Quote Originally Posted by passel View Post
    The stopwatch properties allow you to get to the raw High Resolution Timer values, whereas the TimeSpan provides convenient re-scaled versions of those values in various units of time. As I mentioned, I have never used the TimeSpan based versions, so wasn't even aware of using TotalMiliseconds or Ticks from the .Elapsed property.
    Fair enough. Of course, as is being discussed, we seem to be moving into an era in which all new machines will have a 10 MHz timer, in which case the two versions of 'ticks' will (hopefully!) be the same - so much of this discussion will become moot (and a fair bit of the potential confusion should go).

    In this 'new (10 MHz) era', the only remaining difference between Elapsed.TotalMilliseconds and Elapsed.Ticks (both TimeSpan) and ElapsedTicks will presumably be that the former is Double whereas the latter two are Long - but that presumably makes no material difference unless one gets up to extremely large time intervals (see new thread I may start soon about capacity/resolution of Double!) - so, with very few exceptions, I see no obvious advantage in using any sort of ticks (and then 'converting' {trivially, with a 10 MHz timer} to time oneself) rather than using TotalMilliseconds (for which the computer has already done the {trivial} 'conversion').

    It is possible, as I think you go on to imply, that the 10 MHz clock in modern machines was introduced to bring it into line with things like TimeSpan units, but I'm not sure that hardware manufacturers necessarily take that much notice of what software development environments are doing (which, after all, could change 'overnight')!

    Kind Regards, John

  27. #27
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,619

    Re: Stopwatch Resolution

    Quote Originally Posted by JohnW2 View Post
    ...
    It is possible, as I think you go on to imply, that the 10 MHz clock in modern machines was introduced to bring it into line with things like TimeSpan units, but I'm not sure that hardware manufacturers necessarily take that much notice of what software development environments are doing (which, after all, could change 'overnight')!...
    While you could change software "overnight", I don't think even software developers would want API and Class definitions that they depend on to change in a manner that would break existing code very often.

    So, the TimeSpan Structure (its actually a structure, not a class as I've been calling it in previous posts), was defined 20 years ago, and "The value of a TimeSpan object is the number of ticks that equal the represented time interval. A tick is equal to 100 nanoseconds, or one ten-millionth of a second. The value of a TimeSpan object can range from TimeSpan.MinValue to TimeSpan.MaxValue."

    So, once defined, one hopes they wouldn't change the definition in later frameworks and break the existing code to date.

    And you're probably correct. While the previous hardware "standard" for the high resolution timer were based on 3.xxx Mhz, it probably wasn't to be compatible with the Color Burst frequency of NTSC or PAL, but just because crystal oscillators used for those standards were readily available at a very low cost because of the wide spread use in TVs and other video related equipment.

    It is also probably why the 3.xxx Mhz value varied a fair amount between various computers, because the crystals weren't actually being used for decoding color signals, the manufacture didn't have to go through the expense of tuning the circuit for a specific frequency, just use the crystal with a default set of supporting components, and if the resulting frequency varied between 3.2 Mhz and 3.6 Mhz, what did it matter. You use the API to get the frequency, then compensate in Software.

    Perhaps now, a 10 Mhz clock is a common component in a wide variety of inexpensive devices, so providing a 10 mhz tick is the cheap thing for a manufacture to do, and it has nothing to do with matching the 20 year old TimeSpan value definition. I guess that would be considered a lucky coincidence.
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  28. #28

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    While you could change software "overnight", I don't think even software developers would want API and Class definitions that they depend on to change in a manner that would break existing code very often. ... So, once defined, one hopes they wouldn't change the definition in later frameworks and break the existing code to date.
    True. On reflection, perhaps it's more likely that any future change will be 'the other way around' - i.e. in response to user demand for potentially higher resolution timing, maybe hardware manufactures might be persuaded to change to 1 GHz (or, less tidily, 100 MHz).

    If that happened, assuming the new timer frequency was reported to the software, I imagine that all the present conversions would still work (albeit Ticks and ElapsedTicks would become different again), but still only doing things to a 100 ns resolution. If/when the software developers wanted to take advantage of the potentially higher resolution then available, I suspect they would have to invent some 'new names' in order to preserve backward compatibility with legacy code.

    Kind Regards, John

  29. #29
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    5,619

    Re: Stopwatch Resolution

    Well, I guess if you would like to dig into the backstory behind all this, and you like graphs and math, then This paper from 2012 (updated in May of 2019 so covers Win 10 as well) about Microsecond Resolution Timer Services for Windows could be considered a good read, or something to help you get to sleep.
    "Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930

  30. #30

    Thread Starter
    Hyperactive Member
    Join Date
    Nov 2017
    Location
    Buckingham, UK
    Posts
    258

    Re: Stopwatch Resolution

    Quote Originally Posted by passel View Post
    Well, I guess if you would like to dig into the backstory behind all this, and you like graphs and math, then This paper from 2012 (updated in May of 2019 so covers Win 10 as well) about Microsecond Resolution Timer Services for Windows could be considered a good read, or something to help you get to sleep.
    Thanks. I've downloaded that and stored it away, in case I ever have the time and the need for some bedtime reading! At a glance, it certainly looks intellectually interesting - although, it will presumably never be of any practical relevance to any of us unless/until the things being discussed therein ever come to be routinely implemented in the hardware and software environments which most of us use.

    As for the discussion here, the important thing for me is that, thanks to you and others, and despite the attempts of vb.net to confuse me, I think I now understand enough to be able to deal with time intervals/differences using vb.net!

    Kind Regards, John

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width