I also saw this problem on a suite of machines that were being used for distributed performance testing. We had xntpd running but the clocks still lost too much accuracy too quickly. We ended up setting up a process that automatically ran ntpdate every 10 seconds on each of the machines. It solved our immediate problem, but it also demonstrated that time was definitely being lost hand over fist on some machines but not on others as ntpdate was succeeding and was showing that the clocks could lost around a millisecond every second which would come to 20 minutes every 13 days. We never tracked down the cause though.
-----Original Message----- From: Bill Moseley [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 11:19 PM To: James Tappin; [EMAIL PROTECTED] Subject: Re: Clock running slow At 07:03 AM 12/05/02 +0000, James Tappin wrote: >Does the machine have a SCSI bus or a device running under ide-scsi? I >have seen clocks run extremely slow (less than half speed) when using SCSI >devices with disconnects disabled. NTP can fail to correct if the shift is >too big. Yes it does. The machine is used for burning CDs and they are ide-scsi. Can you recommend a way to test this? Any work-arounds? Time is not critical on this machine -- I suppose I could just crontab ntpdate. Thanks James, Hum... So, how does cron keep from running things twice if the clock gets set back before the cron period? -- Bill Moseley mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
