Re: Repeated timeouts period



On Thu, 13 Oct 2005 15:16:36 +0200, Nicolas George said:

> What I want is a displayed clock that *changes* precisely at the time the
> internal clock value changes. With careful programming, I can get that with
> "precisely" = the intrinsic system latency, which is pretty good (less than
> a CRT screen refresh, on idle modern systems).

Something to keep in mind - the system's *internal* clock is usually going
tick-tick-tick at some high speed (100HZ to 1000HZ for recent Linux kernels,
for example).  It also usually has a very good notion of "500 milliseconds from
now" and similar timeouts.  However, any conversion to "seconds" is more or less
entirely for the convenience of the liveware using the system.

Given that you already *know* there's up to 0.5 seconds of difference, it seems
that what you want *isn't* "precisely the same time the internal clock value
changes".  What you want is a guarantee that *this* change will be almost exactly
1 second since the last change - in other words, if the last time it changed was
actually at :45.34, you want the next one to be between :46.32 and :46.36 or so...

(I'm sure that Paul can talk in detail about getting *real* timestamps, such as
per-frame SMPTE timestamps, which is a *whole* different kettle of fish ;)

Attachment: pgpIvIYFK9v3D.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]