[ntp:questions] ESR looking for good GPS clocks

Dennis Ferguson dennis.c.ferguson at gmail.com
Tue Mar 6 03:26:05 UTC 2012


On 5 Mar, 2012, at 14:44 , Chris Albertson wrote:
> On Sat, Mar 3, 2012 at 10:11 AM, Terje Mathisen <"terje.mathisen at
> tmsw.no"@ntp.org> wrote:
> 
>> The idea is of course to NOT use the USB-RS232 emulation driver, instead (or
>> on top of) you want a private command to poll for the latest PPS timestamp.
>> 
>> The reply you get from this command can then contain the actual time at the
>> point of polling, instead of just what it was at the latest PPS.
>> 
>> OK?
> 
> No.  That can't work.  the whole point of the time stamp is to sample
> the PC's clock so that it ca be corrected.   When the PPS happens it's
> the computer's INTERNAL time that we need to snapshot.

No, what he wants can work very well, much better than anything that
involves interrupt processing.  It just requires support from the GPS
chipset, support which doesn't exist.

Think about what a GPS receiver knows about time.  A GPS receiver has
an internal clock derived from a (generally free-running) oscillator
on the board, against which it measures the arrival times of GPS
satellite signals.  What it computes from this is its location and
the relationship between its internal clock and GPS time (and, with
a bit more math, UTC) so, while the receiver may not have a clock which
is synchronized to UTC (or GPS time) it knows how to do the arithmetic
required to convert a timestamp from its internal clock to a corresponding
estimate of UTC.  What you need to measure the computer's clock against
the GPS receiver is (minimally) a sample of computer's internal clock
and a sample of the GPS receiver's internal clock (converted to UTC)
taken at as close to the same time as possible.  These samples don't
have to be taken at the on-time second, any time will do.

So suppose the GPS receiver provided a way for the computer to ask
what time it is, which will cause the GPS receiver to sample its internal
clock, convert that time to UTC and return the result.  Since the time
required to complete a USB transaction on a full speed interface is
quite large compared to the likely resolution of the GPS receiver's
clock we'll also reduce the ambiguity by specifying exactly when in
the transaction the GPS receiver should acquire the timestamp, in
particular by having the GPS receiver acquire a timestamp whenever
it observes its incoming signal pair transition from idle state at
the very start of every transaction.  If the transaction turns out to
be one asking for the time the receiver will convert that timestamp
to UTC and return it to the host, otherwise it will toss that timestamp
and wait for the first bit of the next transaction.

If it works like this then the computer can poll the time by executing
the minimal instruction sequence to do the following:

(1) take a local timestamp (this could be a rdtsr instruction)
(2) start the USB transaction to read the GPS clock

If you are really lucky you might do that with just two instructions.
The time ambiguity is the time it takes to execute those instructions
(probably nanoseconds) plus the time it takes the hardware to deliver
the first bit of the resulting transaction to the GPS' USB interface.
If the GPS receiver is directly attached to the host hub and nothing
else is going on at the time the latter might be 10's of nanoseconds,
so a single sample should generally get you to a fraction of a
microsecond.  If you need frequent samples for noise filtering you can
repeat this as often as you want (i.e. you aren't limited to one sample
per second).

In addition, if you can afford to wait for the transaction to complete
(you probably can't with USB, but you can with a higher-speed bus) you
can do even better by having the device take a second timestamp at
the end of the transaction, say when it puts the last bit of data in
the response onto its outgoing wire, and storing that where the host
can read it later.  If the host takes a second timestamp when the
operation completes you now have 4 timestamps, the before- and after-timestamp
from the host and the early- and late-timestamp from the device.  This
gives you a direct measurement of the time ambiguity the same way that
NTP processes its timestamps, and gives you additional data for noise
filtering.  While the second pair of timestamp probably doesn't help
with USB (the two early timestamps are probably as good as it gets) it
does if you use PCI instead.  I have a PCI-X card which is timed like
this; the before- and after- host timestamps are generally 80 ns
apart while the card early- and late- timestamps are 66 ns apart,
leaving an ambiguity of +/- 7 ns.  I hope to be able to measure PCI
Express (which has a lot in common with USB) soon.

In any case, an approach using host polling is much, much better than
anything involving once-per-second interrupts, but it requires carefully
done support in the device.  The only way to get a device like that now
is to build it yourself, but it would be nice if GPS chipset manufacturers
would provide this for computer synchronization.  The PPS output is a
poor way to transfer time to a computer.

> The problem with USB is the large uncertainty in the time data goes in
> to when the interrupt happens.   The serial port works well because it
> is very simple with no buffering.

If you are timing interrupt latency you are incorporating a large
uncertainty compared to what you could do with a well-done polling
interface.

> 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.

Which also has you measuring interrupt latency, not to mention dealing
with the difficulty (depending on the computer's clock source) of arranging
for an interrupt at the on-time second.  If you have an output available,
however, you could forget about both the interrupt and the time interval
counter if you bought a uBlox GPS timing chipset, since I think these will
timestamp transitions on an input pin.  When you feel the urge to
acquire a timestamp just take a local clock timestamp, toggle the
output pin and ask the GPS unit for its timestamp.  Absent special
purpose I/O, however, having the device timestamp bus transitions
isn't a bad way to do it.  If the device is carefully done you
can certainly get sub-microsecond time sampling with USB.

Dennis Ferguson



More information about the questions mailing list