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.
On Tue, Apr 29, 2003 at 04:36:32PM +0100, Gavin Kelman wrote:
We're using rdate to keep our Filer's clock in sync to prevent clock skew errors when compiling things on NFS mounts.
I don't know why this was sent 6 times to the list :(
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?
options timed.max_skew 30m
will update it to have a skew difference of 30 minutes.
And that should help you.
Type 'options' from the command line to see the different items available.
drechsau@visi.com (Mike Horwath) writes:
On Tue, Apr 29, 2003 at 04:36:32PM +0100, Gavin Kelman wrote:
We're using rdate to keep our Filer's clock in sync to prevent clock skew errors when compiling things on NFS mounts.
I don't know why this was sent 6 times to the list :(
From (the differences in) the "Received" headers it looks as though this hiccough was internal to mathworks. Maybe the list maintainer can comment?
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),
It's much better to use ntp if you can. The rdate protocol is limited to working in whole numbers of seconds.
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?
options timed.max_skew 30m
will update it to have a skew difference of 30 minutes.
And that should help you.
Having a timed.max_skew of 1 second is unreasonably small even if you are using ntp, and for rdate it will mean that no correction will ever work (as min_skew is effectively forced to 1.5 seconds for that protocol). It would be interesting to have a history of how it got like that. Do you track registry changes at all? You can look at snapshots or backups of /etc/registry if you are sufficiently motivated...
Type 'options' from the command line to see the different items available.
Useful and apparently undocumented trick: "options timed" will show you all the options that begin with the string "timed".
Chris Thompson Email: cet1@cam.ac.uk
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
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
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
-
Chris Thompson -
Gavin Kelman -
Michael Haller -
Mike Horwath -
Nigel Barker