Tix and QueryPerformanceCounter/Frequency

[Gary Beene]

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?

[David Roberts]

>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
  
  !cpuid
  !RDTSC
  !lea esi, qTSC
  !mov [esi], eax
  !mov [esi+4], edx
  
  Tix TixValue
  
  Print "QPC Frequency";qFreq
  Print
  
  Print "QPC:";qQPC
  Print "TSC:";qTSC
  Print "Difference ";qQPC - qTSC;Using$("#####.######",(qQPC - qTSC)*1000/qFreq) + "ms"
  Print
  Print "TIX:";TixValue
   
  !RDTSC
  !lea esi, qTSC
  !mov [esi], eax
  !mov [esi+4], edx
  
  QueryPerformanceCounter qQPC
  
  Print
  Print "TSC:";qTSC
  Print "QPC:";qQPC
  Print "Difference ";qTSC - qQPC;Using$("#####.######",(qTSC - qQPC)*1000/qFreq) + "ms"
  Print
  QueryPerformanceCounter qQPC
  GTC = GetTickCount  
  Print "QPC Age:";Using$("#####",qQPC*1000/qFreq) + "ms"
  Print
  Print "GetTickCount Age:";Using$("#####",GTC) + "ms"
  
  Waitkey$

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.

[David Roberts]

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.

[Paul Dixon]

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.

Paul.

[David Roberts]

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.

[David Roberts]

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.

[Paul Dixon]

David,
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.

Paul.

[Cliff Nichols]

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

[David Roberts]

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