[ntp:hackers] Further to the timestamping issue
David L. Mills
mills at udel.edu
Thu Jun 19 19:13:52 UTC 2008
As of this morning the development branch can accept hardware
timestamps. However, the kernel clock apparatus is still necessary in
order to interpolate time betwen timestamp capture. This limits
potential accuracy to a couple of microseconds due to the kernel clock
swish and sway. It would in principle be possible to implement the
kernel clock as an external clock device of higher quality and we once
did that with a purpose-built bus peripheral. P-H has done that using a
rubidium oscillator. Provisions for that are in the precision kernel code.
Provision for multiple primary standard oscillators requires a means to
develop a synthetic timescale, which is usually done after the fact.
Primary standard oscillators provide only a frequency; they have to be
calibrated to establish the seconds epoch. I calibrate mine by
physically transporting it to USNO, where a technician brings a BNC
cable to the truck and pushes the calibrate button. A candidate NTP
timescale including multiple standard oscillators and intended for
possible implementation and deployment is described in my book. It is
based on the ARIMA scheme used at NIST.
> ----- Original Message ----- From: "David L. Mills" <mills at udel.edu>
> To: <hackers at ntp.org>; <ntpwg at lists.ntp.org>
> Sent: Tuesday, June 17, 2008 7:08 AM
> Subject: Re: [ntp:hackers] Further to the timestamping issue
>> It might not be clear from the documentation, as most folks might
>> consider it an overly pedantic issue, but there is a serious formal
>> model here. I consider three disciplined oscillators with respect to a
>> primary server. First is the remote source, such as the WWV antenna.
>> Second is the local reference oscillator in the GPS receiver or in the
>> WWV case the audio codec. Third is the system clock disciplined by NTP.
>> The device driver interface design is intended to allow contributions
>> from the first two sources to be budgeted.
> meaning that while the budgeted sources are weighted in how they are
> applied the OS Clock is not and this is the core problem with a
> Software Only Clock system.
> I would propose that NTP doesnt really need to be tied to a SW only
> clock and in fact the NTP Server Package and not the NTP protocol is
> what ties it to a SW based clock model.
> That said, it seems totally reasonable that in instances where there
> is an embedded HW based timekeeping system like a 1588MC or similar,
> that the NTP calls should be able to point to it rather than only
> getting time off the local host-based OS Clock through the local NTP
> Service Daemon.
More information about the hackers