On Wed, 2 Aug 2000 brice@gnac.com wrote:
The NTP daemon that's built into ONTAP 5.x works perfectly well in spite of the fact that it is apparently implemented in Java. And,
Actually, we've found the time to be kept pretty horribly on our filers, even with the timed options enabled. We see time skews of upto a few *seconds* with NetApp's implementation of NTP. Being out of sync that much royally blows up our software builds.
# grep skew mess* | awk '{print $15}' | sort -nr | head -5 +2.851 +2.514 +2.406 +2.146 +2.135 # egrep skew mess* | awk '{print $15}' | sort -n | head -5 -2.705 -2.456 -2.244 -2.146 -2.051
I was under the impression that NTP very gently slews the time to keep it in sync, rather than skewing the time in quantum jumps. It's almost as if NetApp's implementation is just a regularly scheduled cron-like ntpdate via Java rather than a robust xntpd daemon continually running and continually adjusting the clock.
I have an RFE open on this issue, which support claims will be fixed in 5.3.7.
24614 RFE: NTP/timed: knob for minimum skew requested
(Thanks Dave Z. and Rod B.!)
This will make the threshold of 50 ms adjustable, the threshold between when the filer's time is "close enough" and when it needs to be reset. However, it does not solve the problem of having, for lack of a better adjective, a "true" NTP daemon running. Perhaps that is very difficult in a realtime OS as opposed to the time sharing desktop or server UNIX OS's to which we are accustomed. 50 ms is pretty reasonable as is, but even at that setting we are getting multi-second skews.
Oh, I also have an RFE/burt/case (I can't find it in my notes) to improve the syslog messages when a time adjustment is made. For instance, we had to do a head swap and the time on the new head was way off:
Wed Jul 5 12:05:25 EDT [Java Thread]: TimeDaemon: NTP server 'time' reports that the time is Wed Jul 05 20:05:53 EDT 2000, but the filer thinks the time is Wed Jul 05 12:05:25 EDT 2000. This time offset is too large to cause us to modify the time automatically (max allowable skew: 600.000 secs). If the time reported by the time server is correct, set the filer time using the 'date' command.
Wed Jul 5 20:06:31 EDT [rc]: Time changed (via "rdate time") to Wed Jul 5 20:06:31 EDT 2000
The "time changed" message is...ah...nearly useless. How big was the time change? It would be more useful to have the timestamp be the *old* time, and the new time recorded; the difference is then the skew induced by rdate.
Okay, two complaints per post is enough. I won't get into the fact that the timed service litters the messages file with notifications. I think someone else pointed out recently the desire for a more robust syslog facility logging. I'd like the ability to put these into messages.info or messages.non-critical or something.
However, taking a historical, big-picture view, having the timed options is a significant improvement from the "old days" of having our admin host rsh the rdate command via cron. <*cough*Kludge!*cough*>
Until next time...
The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---