[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-hackers
Subject:    Re: [ntp:hackers] Further to the timestamping issue
From:       "David L. Mills" <mills () udel ! edu>
Date:       2008-06-19 19:13:52
Message-ID: 485AAFF0.7020904 () udel ! edu
[Download RAW message or body]

Todd,

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.

Dave

TSG wrote:

> Dave
>
> ----- Original Message ----- From: "David L. Mills" <mills@udel.edu>
> To: <hackers@ntp.org>; <ntpwg@lists.ntp.org>
> Sent: Tuesday, June 17, 2008 7:08 AM
> Subject: Re: [ntp:hackers] Further to the timestamping issue
>
>
>> Poul,
>>
>> 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.
>
> Todd
>
>>
>

_______________________________________________
hackers mailing list
hackers@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/hackers
[prev in list] [next in list] [prev in thread] [next in thread]