Comments re: More on Sleep - Yawn

[David Roberts]

I don't expect any problem with HiResHybridSleep at More on Sleep - Yawn but since it has only been tested on two machines I cannot be certain.

For the benefit of everyone, if you have any weird and wonderful doings then please report them here.

Ta much.

[John Gleason]

I think this repeats code from your post Dave, but it also allows short timings on machines where PerformanceFrequency <> clock speed. (my machine for instance )

'PB9
#COMPILE EXE
#DIM ALL
#INCLUDE "win32api.inc"

FUNCTION PBMAIN () AS LONG
      LOCAL f, f2, f3, t, t2 AS QUAD, printStr AS STRING, exprCalc AS DOUBLE
      LOCAL delay, delayCalc, ii, offTime AS LONG, clockSpeed AS QUAD
      PROCESS SET PRIORITY %REALTIME_PRIORITY_CLASS 'can't guarantee 100% accuracy, but does improve it. There
                                                    'can be context shifts increasing delay times significantly.
      queryPerformanceFrequency f
      queryPerformanceCounter   f2
      TIX t                     'calculate clock speed
      DO                        'if you know PerformanceFrequency = clock speed for your CPU,
                                'then just use PerformanceFrequency. No need to calculate approx clock speed.
         queryPerformanceCounter   f3
         IF f3 - f2 >= f THEN EXIT DO
      LOOP
      TIX END t
'
      ? "Processor clock speed: " & FORMAT$(t, "0,") & " Hz",,"Cpu Speed" 'well within 1% on my machine (.1% actually)
      f = t                     'save CPU speed for below

      FOR ii = 1 TO 300 STEP 10 'try various microsec delays
         
         delay = ii             'microsecs you want to delay; here it varies with ii
         clockSpeed = f
         delayCalc = clockSpeed / (1000000 / delay)
                      
         '-------------------delay loop---------------------------------------
            TIX t
         DO
            TIX t2
            IF t2 - t >= delayCalc THEN
               exprCalc = (t2 - t) / (clockSpeed / 1000000)
               printStr &= "Delay requested: " & FORMAT$(ii, "000") & "   Actual delay: " & _
                           FORMAT$(exprCalc, "0,.000") & " µSec" & $CRLF
               IF ABS(exprCalc - ii) > 1 THEN
                  printStr = LEFT$(printStr, LEN(printStr) - 2) & CHR$("*",$CRLF)
                  offTime = 1
               END IF
               EXIT DO
            END IF
         LOOP
         '---------------end delay loop---------------------------------------
      NEXT
      
      IF offTime THEN
         ? printStr & $CRLF & "* off by over 1 µSec",,"MicroSec Delay"
      ELSE
         ? printStr,,"MicroSec Delay"
      END IF
END FUNCTION

[David Roberts]

Thanks John.

For a more accurate clock speed calculation we could use

Tix overhead
Tix End overhead

QueryPerformanceFrequency f
f = [COLOR="Red"]n[/COLOR]*f
QueryPerformanceCounter   f2
Tix t                     'calculate clock speed
  Do                        'if you know PerformanceFrequency = clock speed for your CPU,
                                'then just use PerformanceFrequency. No need to calculate approx clock speed.
    QueryPerformanceCounter   f3
  If f3 - f2 >= f Then Exit Do
  Loop
Tix End t
      
t = (t - overhead)/[COLOR="Red"]n[/COLOR]

Where n = 2, 4, 8 or whatever, depending upon how much time you can afford. The greater the value of n the better the estimate.

Added the Tix overhead calculation. At this level of play it is not insignificant.

BTW, what is your QPF and clock speed at your current windows session?

[John Gleason]

Where n = 2, 4, 8 or whatever, depending upon how much time you can afford. The greater the value of n the better the estimate.

Yes, I see what you mean: longer test, hopefully more accuracy. Just thought of something--I wonder if context switching, ie. cpu cycles going to other threads might affect longer tests more. Also, maybe I'll try shorter tests to, like n = .5, .25 etc. I think overhead is pretty constant at what, 100 ticks if a CPUID is tossed in?

BTW, what is your QPF and clock speed at your current windows session?

qpf is 1193180 @464Mhz

[David Roberts]

Mr Gleason, you are leading me into bad habits! We should be taking account of the QPC overhead as well, as I do with both the Timer and Sleep macros, since it is greater than the TIX overhead having the AP Interface to wade through as opposed to dropping straight into the machine level with RDTSC.

The FPV (Full Pedantic Version) may be written as:-

Tix TixOverhead
Tix End TixOverhead
 
QueryPerformanceFrequency f
QueryPerformanceCounter   f2 ' Wack it twice
QueryPerformanceCounter   f2 ' as suggested by an Intel engineer
QueryPerformanceCounter   f3
QpcOverhead = f3 - f2
 
Tix t                     'calculate clock speed
Do                        'if you know PerformanceFrequency = clock speed for your CPU,
                          'then just use PerformanceFrequency. No need to calculate approx clock speed.
  QueryPerformanceCounter   f3
  If f3 - f2 - QpcOverhead >= f Then Exit Do
Loop
Tix End t
 
t = t - TixOverhead

I think that you will be surprised at the accuracy of the timings now before introducing an 'n'.

I wouldn't go for an 'n' < 1; I'd give it a sporting chance with a full second.

> I wonder if context switching ... might affect longer tests more.

I've got no idea but I bet Paul Dixon has.

[David Roberts]

Oh, dear! TixOverhead should also be taken into account in the delay loop as well.

[John Gleason]

You'll probably be pleased to hear that, using the full pedantic version, I get 99.9994% precision measuring CPU speed over 20 runs. That seems like it will be "adequate" for most users microsecond delay needs.

[David Roberts]

Yep, that is better than a poke in the eye with a sharp stick alright.

Here is an idea. Rather than have each and every application which requires the clock speed have the task of calculating it you could have a little application running from the StartUp folder which does so and then dumps the value either into the registry or an Ini file. The collection time from either deposit will be less than the 'crunch' time used in the calculation.

We need to do this at each boot, of course, since the clock speed is only guaranteed not to vary during a Windows session.

Those that have their performance counter frequency equal to their CPU frequency should feel positively ruined.