Subject: Grrr: Small delays
To: None <firstname.lastname@example.org, email@example.com>
From: Gordon W. Ross <firstname.lastname@example.org>
Date: 08/16/1995 11:05:42
> Date: Wed, 16 Aug 1995 04:16:16 -0700
> From: "Erik E. Fair" (Time Keeper) <email@example.com>
> The subject of good timing (or lack thereof) in the MacOS came up in a
> discussion I had with some colleagues on Monday, and we all bemoaned the
> fact that the clock hardware in all Macs just plain sucks (you may consider
> yourself lucky if the TOD clock doesn't gain a minute or two per day).
> However, one of them remembered that some precision timing could be derived
> from the serial interface chips (after all, if you have to transmit those
> bits serially at some specific baud rate, you'd better have your clocking
> right), and that this had been used in an application which required fine
> resolution interval time (don't recall just what). I did not inquire about
> the exact technique, but if it's not obvious from the chip documents, I can
> ask for more detail. Lucky us, the Macs and the Suns (as I understand it)
> use the same on-board serial chips.
> I know it's slightly perverse, but you take your useful hacks where you can
> find 'em. The alternative suggested here (timing loops) is fraught with
> peril - different cycle time DRAM SIMMs can bite you, as well as what the
> state of the CPU cache is, etc., etc. Quite aside from doing an accurate
> system identification (e.g. is this a 3/50? a 3/60? etc. - same chip,
> different MHz) in order to set the basic timing loop values.
> Erik E. Fair firstname.lastname@example.org
One problem with using the serial chips is that (on the sun3 at least)
you need a delay function when touching the chip, to ensure that you
do not touch it again within its recovery time.
The old-fashioned CPU loop has accuracy problems, but it need only
be accurate enough to take at least as long as the requested delay.
That can be accomplished fairly easily (even with cpu independent
code) using a parameterized delay whose delay factor is computed
during initialization. The Linux kernel uses such a delay tuning
trick. (cute: prints out the resulting "BogoMips?" factor too 8^)
The sun3 port uses a parameterized delay, but currently just sets
the parameter based on the CPU type (which is easily determined).
Some day it should be computed instead, but that's a low priority.