[ntp:questions] ESR looking for good GPS clocks

unruh unruh at invalid.ca
Tue Mar 6 18:58:26 UTC 2012

On 2012-03-06, Dennis Ferguson <dennis.c.ferguson at gmail.com> wrote:
> On 5 Mar, 2012, at 18:33 , Terje Mathisen wrote:
>> Chris Albertson wrote:
>>> How to measure?   You need to modify the interrupt handler to raise a
>>> pin on a (say) parallel port. then measure the time from PPS to that
>>> pin going high with a time interval counter.  Such counters are cheap
>>> now on eBay.
>> What I'm asking for is GPS unit with such an interval timer embedded on it, said counter to be restarted on every PPS signal.
>> The query protocol then becomes, as seen from the host:
>> while (1) {
>>  before = gethirestime();
>>  gps_time = poll_gps();
>>  after = gethirestime();
>>  if (after - before < MAX_LATENCY)
>>    use_timestamp(after, gps_time);
>>  sleep(1);
>> }
>> I.e. polling the GPS (at any time) returns the current time in NTP 32:32 format directly. There is no need to ever interrupt anything with a clock source you can poll at any time.
> Note that the problem with the above is that you are asking poll_gps()
> to complete a transaction which is going to require more than 100 bits
> to be exchanged on a full-speed USB interface (I've not seen a GPS chipset
> that provides higher speed USB than that) which only delivers
> 12 bits per microsecond.  (after - before) is nearly certain to
> exceed 10 microseconds, so you are going to get no where near
> sub-microsecond timing unless you have some idea of where in the
> (after - before) interval the gps_time timestamp was actually acquired.
> More than this, the nature of the transaction is such that the gps_time
> timestamp is much more likely to be acquired earlier in the (after - before)
> interval rather than later, so using the `after' timestamp as a match probably
> maximizes the error.  The best arrangement is to have the GPS device
> acquire the timestamp just as early in the transaction as it can (ideally
> by acquiring a timestamp speculatively when it sees the first bit of
> any incoming transaction), use the `before' timestamp for comparison
> and forget about 'after'.
> The two timestamps will still allow you to do error filtering, you just
> need to acquire more samples and compare them to each other.  That is,
> any additional delays which occur will cause the difference
>     gps_time - before
> to increase, never decrease, so if you take multiple samples the best
> of them will be the ones with the relatively smallest (i.e. most negative)
> values of that difference.  Figuring out which samples are the best is
> more complicated if you also need to assume there might be a significant
> frequency offset between the GPS clock and the host clock, but even
> this can be handled with a least median of squares filter if it can
> be assumed that less than half the samples suffered a significant
> additional delay.  You needn't limit the sample rate to once per second,
> either, if more frequent sampling helps.

This was all thought about in the development of ntp, and the process
they settled upon is probably as good as it gets. ie, you timestamp just
after the
receipt and  just before the the transmission, the client timestamps
just before the transmission and just after the reciept. Assuming that
the receipt and transmission times are the same, give the ntp procedure. 

> Dennis Ferguson

More information about the questions mailing list