I've found the drift file maintained and used by hwclock practically unusable, as too many different pieces of software keep on overwriting it, or the CMOS clock. This drift file is for the CMOS clock only, the drift info maintained by the NTP daemon is for the CPU clock only (my understanding anyway).
Also, I've seen distros today to save the kernel time into the CMOS on shutdown. When the system starts up, the CMOS is loaded into the kernel, so you get time continuity, which isn't actually bad. > The other thing I have found is that if one dual boots with that other o/s, > while on the 'Net it interferes with the crystal with out any authorization, > whatsoever setting it to the PST8PDT timezone. Yeah, when it comes to timekeeping, you keep on wanting to nuke redmond off the face of the planet. They don't have any idea of a difference between kernel time and CMOS time, they're always both the same, i.e. the CMOS keeps on getting overwritten. Dorks. Add to that that timezones are not Billy's strongpoint, fat fs & Co can't even handle them. Practical considerations though with worldwide networking have pushed UTC down Billy's throat - doesn't affect CMOS clocks though. > It causes untold strife to clock settings. Tell me about it! Luckily I nuked redmond, (well off my computer), and it's not doing harm in vmware if you're rich enough to have a copy. If I was getting seriously p**ed off, I'd solder a cutoff switch into the CMOS-clock's write-data line. Perhaps that's a business idea?? Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
