Mark Rages wrote: > On 5/8/05, Olin Lathrop wrote: > >>phil B wrote: >> >>>I should have been a bit clearer. I am checking when >>>I sync up the time. At that point the PC clock should >>>be pretty close. >> >>No, that was my point. Take a look at the clock when you sync up. It >>doesn't jump suddenly, unless maybe it's way off. In some cases anyway, the >>system appears to try adjusting it smoothly. It may take a while for it to >>get to the "correct" time. You'll be much better off checking with a real >>reference. > > No, his method is fine for the accuracies he's talking about. At work > I have a bunch of servers that syncronize time using NTP. They stay > within a few milliseconds of each other. This is becuse the NTP > daemon continuously varies the hardware clock speed to keep in sync > with the reference, kind of like a very slow-running PLL. You sure about that? More likely it adjusts the software clock tics by adding or dropping them as needed. The HARDWARE tic clock is not tweakable in a PC. (Ok, it is, but not very granular, and not with a system API. It is VERY hardware specific. 14.31818 Mhz/12/65536 =18.20650736 Hz system tic rate.) ( My > machines run Linux, but I've noticed Windows XP comes with an NTP > daemon too, now. I assume it works equally well. ) Nope, it doesn't. There is NO 'varying the hardware clock speed'. You get what you get. The software makes NO effort to correct for drift errors. It just jams the new time into the clock if the error is not too large. There was a really old DOS shim that doubled the clock timer rate and then added or dropped tics as it learned the error of both the CMOS clock and the SYSTEM clock. It learned the error for the system clock AND it also added a compensating offset for the CMOS every boot. It did NOT use NTP (since back when it was written, network connectivity (mail, news, etc. was DIALUP). I have yet to find anything like that for Winblows. (anyone have a lead?). > P.S. Phil, to get a quick fix on the time, issue "rdate time.nist.gov" > on a Linux box. Error should be less than a second, because NTP takes > network latency into account. Yes, but Winblows happily lets the system lock out interrupts for extended periods, and the 'date/time' counter drops tics quite IRREGULARLY as a result. I'm involved in a couple of radio astronomy projects, so I've learned to NOT trust winblows time call AT ALL. You want accurate time stamps, you use a board designed for the task. Robert -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist