On Mon, 2004-05-10 at 18:16, Post, Mark K wrote: > Do you have the "on demand" timer patch enabled? If so, turn it off, and > see if this changes.
My apologies for not jumping into this at earlier time, but I was too busy presenting at the zSeries Technical Conference in Noordwijk - on keeping time in Linux on z/VM. I doubt the timer has anything to do with it. Even with the on-demand timer we stay locked to the hardware TOD clock. My first guess is that the system running ntpdate landed in the eligable list and thus observed a huge delay, but that would make it step back with the next transaction. So maybe the ntp server got confused and sent wrong data. If you want it like this (and are willing to accept the clock stepping back in some cases) you should use 'ntpd -q' rather than 'ntpdate' since that is more robust in obtaining time. You probably should not use the -g and similar options to avoid sudden jumps like this, except for the very first call after reboot. Rob ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
