Yeah, you've hit the nail on the head. I'd really like my NetApp to

Of course :-)

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

Of course (again) I don't see this happening in the near future, an implementation of RFC 1305 is not something lightweight. A good friend of mine did it for an Ericsson OS a 2-3 years back and he is a very good programmer. He staggered at the RFC and implemented the (client)parts that they really needed at that time, not the server functionality a.s.o. Don't know if what he did was "probe"able with ntpq ntptrace, but I suspect not.

I think about it this way: there is a reason the RFC that describes SNTP ("S=Simple", mmm?) was written...

A pain in the butt... I wonder if there's an SNMP trap for this type of info?

I think there is, but I've never used any SNMP stuff in connection with NetApp systems so I can't say at all. You can always download the latest SNMP MIB and search through the ASN.1 spec.

IMO the annoying thing with NetApp's SNTP implementation (in Java) is that it isn't very accurate due to a number of factors like the individual motherboards (internal clocks a.s.o.) the LAN, the delay in various places... all this stuff is taken in to account in the "real" regulation algorithm in RFC 1305, and so a UNIX xndtpd is able to keep the system clock very stable under a very wide variety of circumstances. I learns so to speak, and there are lots of stuff in there to make it as robust as possible even during external events that could affect the clock regulation.

SNTP is much more vulnerable. Since a Filer is often hit by a lot of traffic and load fluctuates quite a lot (at least in an R&D environment where I am) my experience is that this affects the SNTP daemon in ONTAP so that the clock skews and hence in practice flucutates in an unpredictable way around the correct value. To fine tune the parameters that are available to you in ONTAP is a very tedious task of trial and error. There can be a huge difference in the stability of the clocks (size in skew) depending on what you set those 2 I mentioned before to. This is the case in an old F840c system we have here.

Cheers, /M