New Sub-Forum

In an effort to help make sure there are appropriate categories for topics of discussion that are happening, there is now a sub-forum for databases and database programming under Special Interest groups. Please direct questions, etc., about this topic to that sub-forum moving forward. Thank you.
See more
See less


  • Filter
  • Time
  • Show
Clear All
new posts

  • TimeBeginPeriod

    For those of you who have not been reading my ramblings of late, probably most of you, here is a tip you may like to consider if you use TimeBeginPeriod.

    I have been using:
    Local Time As TIMECAPS
    TimeGetDevCaps( Time, SizeOf(Time) )
    but I have noticed many of you using
    Whatever, the point is that it seems that the increased resolution does not take until two ticks have elapsed at the resolution prior to TimeBeginPeriod(1). By that I mean the time to the next tick followed by a full tick. This may not be an issue but either way we can ensure that code following executes at the increased resolution by inserting Sleep 16 immediately after TimeBeginPeriod.

    Since the maximum resolution is 15.6ms then Sleep 16 will cover any prior resolution. Sleep 16 will force at least two ticks.

    Strictly speaking we should follow TimeEndPeriod(1) with Sleep 2 but I don't think we need do that.

    That is it.
    Last edited by David Roberts; 22 Aug 2014, 03:48 AM.

  • #2

    You may think that provided there is at least two ticks worth of 'crunching' between TimeBeginPeriod and the code that the higher resolution is intended for then all should be well. Not so. I replaced Sleep 16 with a pause utilizing the Performance Counter and paused for 100ms. The code requiring the higher resolution still needed two ticks to work properly so Sleep 16 is the way to go.


    • #3
      Here is a simple example to illustrate this phenomenon.

      Running as is we get the first reading at the next tick, then we get 9 ticks at 15.6ms.

      When we uncomment TimeBeginPeriod we get the first reading at the next tick, then a full tick at 15.6ms followed by 8 * 1ms.

      When we uncomment Sleep 16 we get 10 * 1ms.

      Don't try this with a Chromium browser open - it sets the resolution to 1ms as soon as it opens. IE is more intelligent and will set to 1ms as required.

      The APIs affected by this are:


      With this simple example we do not need to employ TimeEndPeriod - the system revokes our request when the process terminates. (Source: Mark Russinovich)

      #Compile Exe
      #Dim All
      #Register None
      #Include "WIN32API.INC"
      Function PBMain
      Local qFreq, qStart, qStop As Quad, i As Long, msg As String
      'Sleep 16
      QueryPerformanceFrequency qFreq
      For i = 1 To 10
        QueryPerformanceCounter qStart
        Sleep 1
        QueryPerformanceCounter qStop
        msg += Str$((qStop-qStart)*1000/qFreq) + $CrLf
      MsgBox msg
      End Function
      Last edited by David Roberts; 22 Aug 2014, 08:33 PM.


      • #4
        We are, of course, not limited to just TimeBeginPeriod(1).

        With TimeBeginPeriod(n), on Win7 for certain, here are the values available.
        n = 1  => 1ms
          = 2  => 1.25ms
          = 3  => 2.5ms
          = 5  => 5ms
          = 10 => 10ms
          = 16 => 15.6ms
        MSDN states
        Return value
        Returns TIMERR_NOERROR if successful or TIMERR_NOCANDO if the resolution specified in uPeriod is out of range.
        On Win7 this is untrue, we get TIMERR_NOERROR whatever we choose. If we choose an intermediate value then we will get the value below. Choosing 7, for example, will give us 5.

        If we choose 10, say, then we only need to follow TimeBeginPeriod with Sleep 11 and so on but Sleep 16 will cover any chosen value.


        • #5
          very slick investigative work under-the-hood, Dave!

          I guess it'd be handy if MSDN provided this sort of info without us having to find it out for ourselves, but that'd be no fun right?


          • #6
            Enjoying a good bug hunt, which non-programmers may see as being a little perverse, is one thing but hunting for something which we should have been told about should be another but it wasn't. You are right, Wayne, it was fun.