I have a clustered pair of 840s running DOT 6.1.1R2. I also have a clustered pair of 760s running the same version of DOT. I'm talking about the 840s below, but I see the exact same behavior on the 760s.
I am attempting to enable ntp on the filers, but it doesn't appear to be working.
Here's my "timed" options:
cf.timed.enable on (same value in local+partner recommended) timed.enable on (same value in local+partner recommended) timed.log on (same value in local+partner recommended) timed.max_skew 1h (same value in local+partner recommended) timed.min_skew 50 (same value in local+partner recommended) timed.proto ntp (same value in local+partner recommended) timed.sched 30m (same value in local+partner recommended) timed.servers ntp (same value in local+partner recommended)
(The host 'ntp' is in the hosts file)
Although it reports timing discrepancies, it doesn't actually change the time on the box...at least not the one reported by 'date':
fatman> date Fri Mar 15 17:56:45 EST 2002 fatman> Fri Mar 15 17:56:47 EST [fatman: Java Thread:info]: CfTimeDaemon: timed: adjusting time: filer thinks time is Fri Mar 15 22:56:47 GMT 2002. Time reported by time server ntp is Fri Mar 15 23:05:20 GMT 2002 (skew +513.246 secs).
fatman> date Fri Mar 15 17:57:00 EST 2002
Behavior is the same on both cluster boxes:
littleboy> date Fri Mar 15 17:41:15 EST 2002 littleboy> Fri Mar 15 17:41:22 EST [littleboy: Java Thread:info]: CfTimeDaemon: timed: adjusting time: filer thinks time is Fri Mar 15 17:41:21 EST 2002. Time reported by time server cluster is Fri Mar 15 17:47:06 EST 2002 (skew +345.099 secs).
littleboy> date Fri Mar 15 17:41:27 EST 2002
As I mentioned before, the 760s are doing the exact same thing. Is there something here that I'm missing?
-=-
In addition to this, I observed some additionally disturbing behavior on one of these boxes. After rebooting the box, the clock didn't advance for over 5 minutes:
fatman> date Fri Mar 15 17:46:29 EST 2002 fatman> date Fri Mar 15 17:46:29 EST 2002 fatman> date Fri Mar 15 17:46:29 EST 2002 fatman> date Fri Mar 15 17:46:29 EST 2002 fatman> date Fri Mar 15 17:46:29 EST 2002 fatman> date Fri Mar 15 17:46:29 EST 2002 fatman> date Fri Mar 15 17:46:29 EST 2002 ...
(Those were typed in over several "real" minutes, then miraculously for no *apparent* reason, it started updating):
fatman> date Fri Mar 15 17:46:29 EST 2002 fatman> date Fri Mar 15 17:46:32 EST 2002 fatman> date Fri Mar 15 17:46:57 EST 2002 fatman> date Fri Mar 15 17:46:59 EST 2002 ...
I've only seen this with one of the boxes and only once - since the box is in semi-production I can't afford to keep rebooting it to see if the behavior is consistant.
Anyone else seen this?
I checked NOW for a bug on my version of DOT with 'ntp' or 'date' in the title - no dice. Next up is opening a case with NA, I suppose.
Oz
+-- Ozzie Sabina ors@cimedia.com once said: | I have a clustered pair of 840s running DOT 6.1.1R2. I also have a | clustered pair of 760s running the same version of DOT. I'm talking | about the 840s below, but I see the exact same behavior on the 760s.
Well, now the 760s appear to have caught up to the ntp server's time (I seem to remember that ntp does gradual updates to get to the actual time - maybe it just took them a while).
The 840s, however, are still about as far off as they were an hour ago (which is about 5-7 mins).
Very strange.
Oz