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