In a recent note, Binyamin Dissen said: > Date: Thu, 11 May 2006 22:19:27 +0300 > > On Thu, 11 May 2006 14:13:16 -0500 Mike Bell <[log in to unmask]> wrote: > > :>At a previous employer - they designed a external time reference that had > :>some special features - It could adjust the speed of the clock to adjust to > :>time changes. > :>DST coming - run clock double time until you get to an hour ahead. > :>fallback - run clock half speed till you match up. > :>every so often they would dial out to somewhere to sync but it kept good > :>enough time, it didn't happen very often. > ETR does likewise, only at a max of 2 seconds/day, rather than your 12 hours/day. I had always assumed there was some electronic reason that clocks couldn't be steered by more. You demonstrate otherwise.
Was it more costly than IBM's ETR, in proportion to the greater steering range? But this is dead wrong for DST adjustment -- the TOD clock should be on UTC, not local time. OTOH, it provides a clever way to adjust for leap seconds without idling the processor for a second that may be important to some applications (How many time out values are less than 1 second?) > :>I always wondered why IBM didn't provide equivalent functionality > > I thought the ETR did that. > > You tell it to set the clock ahead, it will run the clock fast. > > You tell it to set the clock back, it will waste cycles. > Why waste cycles? The adjustment is continuous; the clock runs monotonically. It should be nondisruptive. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
