Michael> What you'd ideally would want to do, is this (I too wish it Michael> was possible:
Yeah, you've hit the nail on the head. I'd really like my NetApp to be a full NTP server/client, just so I can query it and know that it's up with the proper time.
Michael> Unfortunately, but understandably, NetApp didn't implement Michael> the full functionality which is in xntp (for example). They Michael> just use SNTP to keep the clock "roughly" correct in ONTAP Michael> and it is almost always good enough, but far from perfect Michael> (well...). The "real" implementation of the regulation Michael> algorithm in RFC 1305 (NTPv3) which is in the xntp package I Michael> believe is much better, among other things the time is Michael> guaranteed to be continous -- not so when you use SNTP Michael> (correct me if I'm wrong here).
I still think it would be better to have a proper implementation, and just not act as a server to other clients. Though that would work too, since according to the man pages, in a Cluster, they use (S)NTP to keep the time between the heads sync'd, so it's not that big a step for them.
Michael> As far as I know, the SNTP client in ONTAP is just a Java Michael> thread. Perhaps this has changed in 7.x.
I don't think so, but I could be totally wrong.
Michael> The only way you can check how well that Java thread is Michael> keeping the Filer clocks in sync is to do just this -- turn Michael> on the logging and examine the logs after a while and keep Michael> doing that for a day or two. If things look good, turn the Michael> logging off again. Often the skew you see can be reduced by Michael> changing the option
A pain in the butt... I wonder if there's an SNMP trap for this type of info?
Ah well, thanks for the info.
John