Forums Developers $ticks, hi res timing

is $ticks based on timegettime, or on queryperformancecounter? in any way, the later is better because one call takes less cpu, and it has better than 1 microsecond accuracy on both windows 9x and NT.
timegettime has only about 15ms accuracy on NT (2000/XP)

this is about as much as the lag i have to some irc servers <grin> so i can't measure it.

if queryperformancecounter is used, $ticks will always be true 1msec accuracy, and there can be another $ticks for microseconds.

lol

If I understand you correctly, you're asking what $ticks is based on.

*Gets out his API Booklet*
Well I can't find my API booklet, but if I remember correctly, it's something like GetWindowsTicks (?). It is a built in API to the Windows Platform SDK.

I'd say it must be pretty accurate.

Regards,

The QueryPerformanceCounter function retrieves the current value of the high-resolution performance counter, provided one exists. It may not exist on a system.

On the other hand, GetTickCount() works on all PC compatible computers, as it's based on the timer hardware interrupt IRQ0.

My bet is that $ticks is a wrapper around GetTickCount().

it is based on the 1.1 MHz clock which is in every PC. you know, 18.2*65536. nothing fancy.
you can find out if it is suppored. if not, it returns 0 and you can use a different way.

On modern PCs it actually uses the CPU's internal performance counter. I've heard of some cases when QPC() returned zero (i.e. failed) due to some hardware issues.

But you're right, it's not a big deal to try QPC() and fall back to GTC() should it fail. Khaled may have used GTC() because it was supported both on Win 3.1 and Win 95 (just a guess).

One thing I know from using QueryPerformanceCounter (and the PSDK mentions it) is if you are on a multiprocessor system, oddities may occur. You can solve this by telling it to always use a specific processor, but then you run into the problems of, which processor should be used? Some may keep time more accurately than others, so mIRC may choose the wrong one.

Minor problem, but could still be a problem.

in that case you can just take first CPU, and (i think) have the accuracy of a single cpu. i think the error will always be well under 1 ms, and not 8 ms like with the ugly 60Hz tick on winNT/2000.