Announcement

Collapse
No announcement yet.

Comments re: More on Sleep - Yawn

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Comments re: More on Sleep - Yawn

    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.

  • #2
    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 )
    Code:
    '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

    Comment


    • #3
      Thanks John.

      For a more accurate clock speed calculation we could use
      Code:
      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?
      Last edited by David Roberts; 4 Jun 2009, 02:57 PM. Reason: Added Tix overhead

      Comment


      • #4
        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

        Comment


        • #5
          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:-
          Code:
          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.

          Comment


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

            Comment


            • #7
              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.

              Comment


              • #8
                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.

                Comment

                Working...
                X