I've been trying to find some documentation on NOW about this, but it's pretty schetchy. Basically, I need to confirm that my NetApp boxes, all running 7.0.1R1, are correctly syncing their time to our NTP servers.

What you'd ideally would want to do, is this (I too wish it was possible:

./ntpq -p mbn

remote refid st t when poll reach delay offset disp ============================================================================== +uabsx1 proxy 3 u 725 1024 377 0.58 16.550 6.55 +uabsx2-blue ns2.ericsson.se 3 u 477 1024 377 0.43 1.330 4.21 -uabsx3 ns1.ericsson.se 3 u 536 1024 377 0.43 -11.058 4.38 *uabsx4 ns1.ericsson.se 3 u 440 1024 377 1.22 9.186 5.75

Unfortunately, but understandably, NetApp didn't implement the full functionality which is in xntp (for example). They just use SNTP to keep the clock "roughly" correct in ONTAP and it is almost always good enough, but far from perfect (well...). The "real" implementation of the regulation algorithm in RFC 1305 (NTPv3) which is in the xntp package I believe is much better, among other things the time is guaranteed to be continous -- not so when you use SNTP (correct me if I'm wrong here).

As far as I know, the SNTP client in ONTAP is just a Java thread. Perhaps this has changed in 7.x.

Running 'ntptrace filer' just gives me stuff like this:

# ntptrace filer1 filer1: stratum 15, offset -0.519726, synch distance 0.00000 0.0.0.0: *Timeout*

Right, just as ntpq won't get an answer either.

timed.proto ntp

This is equvialent to setting it to 'sntp', see the 'options'.man page.

Tue Jan 3 14:38:49 EST [kern.timed.adjust:info]: server 'x.y.2.2' reports the appliance date is slow by 0.513 seconds which is more than timed.min_skew (0.010 seconds). Adjusting date.

The only way you can check how well that Java thread is keeping the Filer clocks in sync is to do just this -- turn on the logging and examine the logs after a while and keep doing that for a day or two. If things look good, turn the logging off again. Often the skew you see can be reduced by changing the option

timed.min_skew 10 timed.sched 9m

but exactly how is very trial-n-error. It certainly depends on the individual Filer HW and your LAN between the filer and the NTP server(s) what the optimal value for sched is. I once sat and did such adjustments during 2 whole days trying to minimise the fluctuation with positive and negative skew I could see in the log, but finally I gave up and did something more fun.

Cheers, /M