[fpc-pascal] timing again

["Vinzent Höfler"]

> On Tue, 01 Jun 2010 19:58:54 +0200
> "Vinzent Höfler" <JeLlyFish.software at gmx.net> wrote:
> 
> > "spir ☣" <denis.spir at gmail.com>:
> > 
> > > Thank you. Using dos.getTime (including its last arg), the following
> > > returns integer time in 10^-2s units:
> > [...]
> > > 
> > > This is the needed base for my uses. (A unit of 1s is too gross for
> > > timing, this leads to endless runs; more precision than 10^-2s is
> > > unneeded.)
> > 
> > Actually, the resolution is only about 55ms (or, to be precise, the
> > underlying clock ticks with a frequency of 1193182 / 65536 Hz).
> 
> Thank you for this precision. Where does getTime actually get its time?

Technically it should use a DOS function. Of course, on non-DOS systems it will be mapped to something different with a probably higher resolution, yet the old DOS time is all accuracy you can assume here.

> And where do these numbers come from; I mean why chose this time unit
> instead of plain 1/10 or 1/100 or 1/1000s? (1193182 does not look
> familiar to my eyes ;-)

Well, historically it's the frequency driving the programmable interval timer (an 8254). I don't know the exact reason, but it's probably 1/11 of the frequency of a 13.125 MHz quartz (at least that's what it looks like, CMIIW). Whatever the exact choices of base frequency and divider, that's where the 1.193 MHz value comes from.

The second part is due to the fact that the timer values are loaded with the value providing the largest divider value (and thus the least possible interrupt load). This value is actually a zero (16-bit), but having the effect of a divider of 65536), so that the abovementioned and quite strange interrupt frequency comes up.

> Do you have an idea on how to get one of those time units (ms would be
> perfect, since more precision can be rounded, while the contrary is a
> hard task!)

Actually, I would simply use "SysUtils.Now" as base clock and appropriate rounding. I used that in the past and it provides fairly accurate values while maintaining system portability. The DOS unit is provided for TP compatibility only and I wouldn't advise using it for new code.

Theoretically this clock has a millisecond resolution. IIRC, in practice, the tick behind this clock is about 15 ms under Win32, but under most Unices you'll get the full millisecond resolution.

If you want to get better than that, you need to get system specific, I'm afraid. But as you stated, you don't need more accuracy, so system dependent functions providing a higher resolution simply won't be necessary in your case.


Vinzent.

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01