Well, we use gnu make, and sntp seems to have sorted the problems we had.
Our netapp is set for 30 mins max skew, Timed Schedule Hourly.
Maybe we're just lucky, and everything is drifting about the same... (This could be because our ntp server sync's with the internet, but everything internal points at our local ntp server)
Cheers
Nige
-----Original Message----- From: Michael Haller [mailto:michael.haller@uk.lionbioscience.com] Sent: 30 April 2003 09:48 To: toasters@mathworks.com Cc: Nigel Barker Subject: Re: rdate and time keeping.
sntp doesn't seem to be good enough for gnu make. We often see:
gmake: warning: Clock skew detected. Your build may be incomplete.
when building on filer exports. When building on exports from systems running (x)ntp we don't run into this problem at all.
- Michael
Nigel Barker wrote:
Gavin
We couldn't get rdate to work at all, but ntp does the business no bother.
Cheers
Nige
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Gavin Kelman Sent: 29 April 2003 16:37 To: toasters@mathworks.com Subject: rdate and time keeping.
We're using rdate to keep our Filer's clock in sync to prevent clock skew errors when compiling things on NFS mounts.
There seems to be a bug in OnTap 6.3.1R1. The clock works it's way out of sync, (hence why we use rdate), and we get:
Tue Apr 29 15:25:18 BST [Java Thread:notice]: TimeDaemon: Rdate (rfc868) server 'dali.lionbio.co.uk' reports that the time is Tue Apr 29 15:25:21
BST
2003, but the filer thinks the time is Tue Apr 29 15:25:18 BST 2003. This time offset is too large to cause us to modify the time automatically (max allowable skew: 1.000 secs). If the time reported by the time server is correct, set the filer time using the 'date' command.
So, to clear this, I set the time by hand using "date". This works fine and we occasionally see:
Tue Apr 29 16:04:06 BST [Java Thread:info]: TimeDaemon: Time offset within tolerance [dali.lionbio.co.uk]: actual -0.640 secs, tolerance 1.500 secs, not changing time.
And after a time we get the first out-of-sync message. In effect, rdate is doing nothing at all to change the time, as the Max Skew rdate will change over is 1 second, but won't bother changing until it's at least 1.5 seconds out of sync. Surely, this is broken?
Cheers, Gavin.
-- Gavin Kelman Unix Administrator Email : gavin@metahusky.net