No announcement yet.

Tix and QueryPerformanceCounter/Frequency

  • Filter
  • Time
  • Show
Clear All
new posts

  • Tix and QueryPerformanceCounter/Frequency

    I was reading about Timers at MSDN and what it said led me to a few questions.

    Does the PowerBASIC tix function return the same answer as the QueryPerformanceCounter() API? In my tests, they seem to work that way, but Help doesn't clarify.

    And does QueryPerformanceFrequency return the number of tix counts per second (for whatever system makes the call)?

    And why does MSDN say "If a high-resolution performance counter exists on the system ...". Does QueryPerformanceCounter not work on all systems?

  • #2
    >Does the PowerBASIC tix function return the same answer as the QueryPerformanceCounter() API?

    Strictly speaking, No. That is if Tix, which uses the Time Stamp Counter (TSC), and QueryPerformanceCounter (QPC) were queried at the same time then they would have different values. They have the same frequency but are initialised at different times during the system start up. 'TIX END' and the difference between two QPCs based upon the same time interval would then give the same results which, I guess Gary, is what you were really asking.

    Have a look at the following:

    ' PBCC 5.01
    #Compile  Exe
    #Register None
    #Dim      All
    #Tools    Off
    %NOMMIDS = 1
    %NOGDI = 1
    #Include "WIN32API.INC"
    Function PBMain() As Long
    Local qFreq, qQPC, qTSC, TixValue As Quad
    Local GTC as Dword
    ' [COLOR="Red"]If you have a single core remove the next three lines[/COLOR]
      Local hProcess As Dword
      hProcess = GetCurrentProcess()
      SetProcessAffinityMask( hProcess, 1) ' ie CPU 0
      QueryPerformanceFrequency qFreq
      QueryPerformanceCounter qQPC
      !lea esi, qTSC
      !mov [esi], eax
      !mov [esi+4], edx
      Tix TixValue
      Print "QPC Frequency";qFreq
      Print "QPC:";qQPC
      Print "TSC:";qTSC
      Print "Difference ";qQPC - qTSC;Using$("#####.######",(qQPC - qTSC)*1000/qFreq) + "ms"
      Print "TIX:";TixValue
      !lea esi, qTSC
      !mov [esi], eax
      !mov [esi+4], edx
      QueryPerformanceCounter qQPC
      Print "TSC:";qTSC
      Print "QPC:";qQPC
      Print "Difference ";qTSC - qQPC;Using$("#####.######",(qTSC - qQPC)*1000/qFreq) + "ms"
      QueryPerformanceCounter qQPC
      GTC = GetTickCount  
      Print "QPC Age:";Using$("#####",qQPC*1000/qFreq) + "ms"
      Print "GetTickCount Age:";Using$("#####",GTC) + "ms"
    End Function
    It is worth noting that qFreq may vary between system restarts but is, says Microsoft, guaranteed not to vary during a Windows session.

    > Does QueryPerformanceCounter not work on all systems?

    It does nowadays but not on all earlier machines.
    Last edited by David Roberts; 18 Mar 2009, 12:46 AM.


    • #3
      I wrote the essence of the above before I increased my system timer's frequency to slow it down - it was drifting quite badly - well, badly for a pedant like me.

      Anyway, the upshot is that we should not take much notice of GetTickCount. MSDN says "It is limited to the resolution of the system timer." It would appear that the tick count is the system timer tick count as the above shows that 'GetTickCount Age - QPC Age' is very much greater now than when I last booted. Actually, it is greater than I would have expected.

      Of course, comparing two GetTickCounts over short durations is OK subject to its resolution of just over 15½ms for a 64Hz interrupt.

      Just checking the QPC Age it would seem that my QPC is running slightly slow as well. So, for long durations our PCs are quite useless. The best bet for long durations is to get the times from a Time Server.

      Added: Blast it, that has just given me an idea - I was having a rest - a long one.
      Last edited by David Roberts; 18 Mar 2009, 05:55 AM. Reason: Spelling


      • #4
        The Time Stamp Counter as read by TIX is internal to the CPU and runs at CPU clock frequency, in the GHz range for modern computers.
        The Performance counters are external to the CPU and on most of the computers I've checked they run at either 3.579545MHz or half that speed.
        Both timers are synchronised to crystals via phase locked loops or dividers so their long term accuracy is that of the timing crystal in the computer which is typically 50 - 100parts per million (100ppm = 8seconds per day). They may be run from the same crystal which would make both clocks drift at the same rate.

        The timer on old computers ran with a 14.318180MHz crystal. The value was chosen as it was the crystal used in colour television in the USA. Divide by 4 to get quadrature 3.579545MHz (the NTSC colour subcarrier frequency) used to extract the colour information. That frequency was chosen because, being mass produced, it was cheap.
        That clock was passed through a 16 bit counter giving 3579545/65536 = 54.6Hz (18.3msec) interrupts used by the original PCs.
        In early computers there was no access to the bits of that counter, only to the resulting output.

        Later computers were designed to allow access to the timer bits in the 16 bit counter allowing Windows performance counters to be implemented.



        • #5
          Thanks Paul, as always, for the definitive answer.

          I rejigged NIST-Time to give the corrected time in FileTime ms and also the QPC ms which was got anyway prior to a server query as it is used to estimate the latency. The readings are taken at different times and there is some number crunching but that will be eliminated when we subtract two sets of readings.

          At 12:11:22 PM GMT I got

          12881851882098 ms
          24386651 ms

          and at 4:06:58 PM GMT I got

          12881866018474 ms
          38522195 ms

          giving differences of

          14136376 ms
          14135544 ms

          with QPC slow then by 832 ms.

          Everything else being equal, famous last words, a linear extrapolation puts the QPC at about 5 seconds slow a day and, therefore, inside of Paul's envelope.


          • #6
            Did another run close to the 12 hour mark at 12:11:23 AM GMT and got a 24 hour estimate of QPC running 4.7 seconds slow.


            • #7
              it'll vary with time and temperature so don't rely on it being constant.
              Accuracy of those clock crystals is not considered important so the crystals are left on their own and give the 50-100ppm I mentioned. For a few pennies they could be tuned to 10-20ppm but motherboard manufacturers don't see that as a priority.



              • #8
                External checks will result in latency

                internal (or what you THINK are internal) will result in less latency, but still there

                Thats why sub Ms timers I have no faith in them...tooo many unknowns in the mix

                Engineer's Motto: If it aint broke take it apart and fix it

                "If at 1st you don't succeed... call it version 1.0"

                "Half of Programming is coding"....."The other 90% is DEBUGGING"

                "Document my code????" .... "WHYYY??? do you think they call it CODE? "


                • #9
                  > it'll vary with time and temperature so don't rely on it being constant.

                  I know.

                  I've been using a TimeAdjusment of 156241 for a while now, as opposed to the default of 156250, and getting about 200ms/day accuracy on my System Timer. A recent examination has seen a slowing down indicating that pushing the adjustment back toward 156250 may be in order. The only thing which has changed over that time is ambient temperature. Who knows I may be looking at going beyond 156250 in the middle of the summer. I may end up going back to my previous m.o. i.e. Get the time from a Time Server at boot and update a couple of times a day.