[time-nuts] Time stamping with a PICPET

[Tom Van Baak]

> If the system were to try and create a PPS then it would have to be based
> on the nanosecond clock  or a hardware count down register based on it.  I
> just cannot see how a count down timer interrupt can have less jitter than
> a DCD line interrupt.

Right. The key is not to use count-down timers and interrupts at all. The key is no interrupts; nothing asynchronous. What you do is:

1) About once a second (it doesn't really matter), with hot cache and interrupts disabled, record the s/w time before and after you output a pulse. If your PC/SBC has a low-latency DTR or GPIO pin code path, you're golden.

2) Then use external h/w to timestamp that pulse at the sub-microsecond level.

3) And then you compare the s/w timestamp of when the pulse was thought to be generated against the h/timestamp of when the pulse was known to be actually received. This allows you to compare s/w "pretend" time against "actual" h/w time. This jitter-free delta is what NTP can use for its discipline algorithm, to smoothly bend s/w virtual time to match real h/w time.

> A few people have  gotten around this by moving the computer's timing clock
> off the CPU chip.  Then you can use hardware latches and such that have
> very predictable timing.  I think this is the only way to improve the
> current system.  You have t remember that there is a large and active
> community of researchers who have been working on this for just over 30
> years now in the latest development version that are talking about
> nanosecond level time keeping.

If the CPU/PC/SBC has h/w counter/capture latches, you're all set. Then there's no jitter and NTP should be as accurate as the ADEV(tau 1s) of the LO that clocks the CPU and the ADEV(tau) of the external (GPS) 1PPS source.

But h/w counter/capture is something no legacy PC has had AFAIK. If the new breed of SBC have this capability, NTP should show a one or two orders of magnitude jump in precision on those platforms.

/tvb