> Hum ... what if ntp correct the clock with ntp_adjtime() ?
> I suspect that after a long uptime, the RTC may have drifted significantly
> from the kernel time.

My reading of the code indicated that the RTC was set every time
ntp changed the system clock.

OTOH I've not used ntp.

I'm also not sure how it can set the RTC more accurately that the
elapsed time to get a message reply from the time server.  If
there is a loaded network segment (ie one that sometimes builds
up a queue of packets) then the round trip time will vary
considerable, also all the error will be in one arm (out or back)
of the request.  I'm sure this will mean that ntp keeps hunting
the system time back and forwards.

The local RTC (or system) clock crystal will give a much better
short term timekeeping.  The remote time should only really be used
to adjust the clock frequency slightly (as a PLL) to stop drift.

But that is my thoughts, the ntp beanies assume they can set
a system clock with ns accuracy...

	David

-- 
David Laight: david@l8s.co.uk