Announcement

**Manuel Valdes** · 28 May 2009, 09:23 PM

David:

It's a very interesting subject, and very useful in my area of concern.

Thanks you!

**David Roberts** · 2 Jun 2009, 05:43 AM

I'm glad to here that the above was useful for you Manuel but we should not reply with comments only in the Source Code forums.

-------------------------------------

On examining the behaviour of both the Standard Sleep, using the System Timer, and the Enhanced Sleep, using a Multi-media Timer via the TimeBeginPeriod/TimeEndPeriod pairing, the latter very much more often than not gives an actual sleep of the chosen value plus a value >= 0ms and < 1ms. Occasionally, the actual sleep is slightly less than the chosen value but I will ignore those for the moment.

It follows then that if we request 'Sleep n - 1' the actual sleep will be between 'n - 1' and 'n'.

On completion of 'Sleep n - 1' we can suspend execution further by querying the Performance Counter until a target value is achieved. The target value will, of course, correspond to an initial condition plus n-milliseconds. The initial condition will need to be got before executing 'Sleep n - 1' and then advanced to the target value, which I've called qTimeOut, via a simple equation involving the Performance Counter overhead, its frequency and, of course, 'n'.

This approach should give us the same accuracy as HiResPause, which has been rewritten - see later, but with very little CPU usage; unlike HiResPause. There is no CPU usage during the first phase, that is the Sleep phase, but there is some during the second phase, that is the Performance Counter phase.

Some tests were carried out using the 'Free Extended Task Manager by Extensoft' and CPU usage during the second phase occasionally peaked at 3%. I assume that these events occurred when the Performance Counter was being used at the high end of the >= 0ms and < 1ms range.

This approach then is unlikely to compromise anyone's system.

I mentioned above that occasionally, the actual sleep is slightly less than the chosen value. In these instances we could use 'Sleep n' as opposed to 'Sleep n - 1' but we cannot know, a priori, when they will occur so we must stay will 'Sleep n - 1'. In these instances the second phase will last for slightly more than 1ms.

Here is the macro, which I cannot call HiResSleep because it is a hybrid of the Enhanced Sleep and the Performance Counter.

Code:

Macro HiResHybridSleep(n)
MacroTemp qTimeOut, qNow
Dim qTimeOut As Quad, qNow As Quad
QueryPerformanceCounter qNow
qTimeOut = qNow - qOverhead + n*qFreq/1000
Sleep n-1
Do
  QueryPerformanceCounter qNow
Loop Until qNow >= qTimeOut
End Macro

Since both qOverhead and qFreq are required then I recommend including the timer macros even though you may not need them as qOverhead and qFreq are determined in the InitializeTimer macro.

Here is the result of one test; figures in ms.

Code:

200  200.000251
180  180.000270
160  160.000187
140  140.000217
120  120.000217
100  100.000161
 80   80.000184
 60   60.000277
 40   40.000221
 20   20.000232
 19   19.000105
 18   18.000236
 17   17.000146
 16   16.000330
 15   15.000221
 14   14.000247
 13   13.000247
 12   12.000165
 11   11.000262
 10   10.000127
  9    9.000105
  8    8.000255
  7    7.000259
  6    6.000180
  5    5.000255
  4    4.000251
  3    3.000319
  2    2.000124

The worst case here is where we overshoot 16ms by 330ns.

The accuracy, of course, is related the the Performance Counter frequency and a friend's PC with an old P4 managed only 3 to 4 µs accuracy. I say 'only' but 3 to 4 µs is still blindingly accurate. [1]

Notice that the table only goes down to 2ms. Here we are using 'Sleep 1' as the base and that is our limit.

If delays less than 2ms are required then use HiResPause(n) which has been rewritten as follows.

Code:

Macro HiResPause(n)
MacroTemp qTimeOut, qNow
Dim qTimeOut As Quad, qNow As Quad
QueryPerformanceCounter qNow
qTimeOut= qNow - qOverhead + n*qFreq/1000000
Do
  QueryPerformanceCounter qNow
Loop Until qNow >= qTimeout
End Macro

Don't forget that HiResPause expects µs input so 1.35ms will require HiResPause(1350).

I don't expect HiResHybridSleep to cause any problems but if it does then please, for the benefit of everyone, report such here.

[1] I originally wrote ms instead of µs. I got my minis and micros mixed up. Should I rephrase that? <grin>

**David Roberts** · 9 Apr 2010, 10:20 PM

I have been doing some work with my Timer Macros and finally advocated using a TIX version but only if the Performance Counter uses the Time Stamp Counter as does TIX.

The overhead with TIX is about 17% of the overhead with QueryPerformanceCounter.

The TIX statement in the manual looks at 'TIX QuadVar' and 'TIX END QuadVar'.

We will get the same result from the following:

TIX QuadVar
...
...
TIX QuadVar1

QuadVar = QuadVar1 - QuadVar

Of course, 'TIX END' simplifies matters but the point I am making is that TIX may be used for continual reading in the same way as QueryPerformanceCounter.

Becuase TIX has a much smaller overhead than the QPC it occurred to me that we may get a better resolution with the above macros.

With HiResHybridSleep now written as:-

Code:

Macro HiResHybridSleep(n)
MacroTemp qTimeOut, qNow
Dim qTimeOut As Quad, qNow As Quad
Tix qNow
qTimeOut = qNow - qOverhead + n*qFreq/1000
Sleep n-1
Do
  Tix qNow
Loop Until qNow >= qTimeOut
End Macro

I now get:_

Code:

200  200.000046
180  180.000031
160  160.000020
140  140.000016
120  120.000016
 80   80.000043
 60   60.000024
 40   40.000020
 20   20.000043
 19   19.000024
 18   18.000031
 17   17.000020
 16   16.000021
 15   15.000025
 14   14.000025
 13   13.000028
 12   12.000028
 11   11.000021
 10   10.000021
  9    9.000021
  8    8.000010
  7    7.000021
  6    6.000021
  5    5.000010
  4    4.000013
  3    3.000013
  2    2.000006

Using the QPC the worst case had an overshoot of 330ns. The worst case above is 46ns.

That is 46 one thousand-millionth of a second. Not bad for a PC.

All we have done is replace QueryPerformanceCounter with TIX and got a factor of 10 more accuracy and this is simply got by avoiding the API overhead and nothing else.

We can, of course, do the same with HiResPause:-

Code:

Macro HiResPause(n)
MacroTemp qTimeOut, qNow
Dim qTimeOut As Quad, qNow As Quad
Tix qNow
qTimeOut= qNow - qOverhead + n*qFreq/1000000
Do
  Tix qNow
Loop Until qNow >= qTimeout
End Macro

I must stress again that these new versions will only work if the Performance Counter uses the Time Stamp Counter as does TIX.

ADDED: You will, of course, need the TIX version of the Timer macros here.

Announcement

Forum Guidelines

More on Sleep - Yawn.

More on Sleep - Yawn.

Comment

Comment

Comment