On Mon, 2007-03-19 at 08:17 +0100, Roger Oberholtzer wrote: > No offence taken. Not a design oversight. Systems evolve over time. New > things get added that need to be integrated. It would be great if one > could retro-design existing hardware based on new requirements. In fact > we have two independent time sync methods. One is based on our own > hardware. We are trying to move away from that as we move to a COTS > solution. Or, at least, 95% COTS. There are few solutions for this that > do not simply change the problem to a different one. We are trying to > keep problems limited to those we understand and can explain, it not > actually solve. > > Also, the original question I had was not so much about not being able > to sync. It was that it makes quality control ever so much more reliable > when dates on files somewhat (within some minutes of tolerance) match > the real time. The sync/accuracy thing was also an aside. We just want > the damned PC clock not to change random amounts at reboot. Well, I hope "man hwclock" and the other links lead you to the problem.
Thanks for bringing it up, BTW. This pc seldom gets re-booted, other than kernel updates. I haven't set the time since installing 10.2, and "hwclock --show" indicates I have a 40 second drift in the past 6 days. Guess I'll spend the next few days "walking" the correction factor into range. Good luck to you! Tom in NM -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
