Hal Murray wrote: > [EMAIL PROTECTED] said: >>> Most systems use the 32 KHz battery backed TOY (Time-of-Year) clock >>> for timekeeping rather than the CPU crystal. > >> Wrong, few systems do. Most systems use the 32.768 kHz xtal to run >> their battery-backed Real Time Clock, but this is only consulted on >> boot to get an initial fix on time. > > Thanks for the heads up. > > >>> This is good because it's generally farther from the heat >>> generating CPU than the CPU crystal. > >> This has no hold in reality. > > It's not what I was expecting. Several years ago, I was trying to match the > temperature of the crystal with the observed drift. The data looked a lot > better after Dave Mills pointed out that I was measuring the temperature of > the wrong crystal. > http://www.megapathdsl.net/~hmurray/ntp/drift.gif > http://www.megapathdsl.net/~hmurray/ntp/drift-ex.gif > > I think he said it was done that way in order to support SMP systems. I'm > pretty sure it works that way on this old Linux box. I probably jumped to > the conclusion that it was more common than it is.
x86 Linux uses the Programmable Timer Module, which has existed on all PC's since the very first, as its time slicer. Time is accumulated by a small task that gets called once per tick of the Programmable Timer Module. This task simply increments a large variable. The battery backed RTC can be consulted by means of a cron script for correction. My system consults an NTP server to get its fix of realtime. It takes a rather convoluted sequence of Inputs and Outputs to a specific I/O port to interrogate the RTC. It isn't something that the kernel could afford to do very often. -Chuck _______________________________________________ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
