Subject: Re: NTP pulse-per-second timestamp diff
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
From: Dennis Ferguson <dennis@juniper.net>
List: tech-kern
Date: 03/26/1998 16:57:23
> So, on this vein ...
> 
> I've just built a CHU decoder, and naturally I want to use it as a stratum
> one NTP source (if you don't know what CHU is, look at the NTP distribution
> documentation and http://www.inms.nrc.ca/inms/ctse.html; it's the
> cheapest way I found of getting a NTP source at home).

This is a good thing.  CHU decoders are cheap as dirt if you're a bit handy,
and it works pretty good if your location is such that reception is reliable.
In general I think the short wave and (V)LF time services are also way more
interesting; GPS has made this much too easy.

> To do this with the best accuracy possible requires using a special line
> discipline; that's easy enough to add.  However, I'm wondering if there's
> any gain in giving the serial port driver the ability to short-circuit
> the soft interrupt processing and feed the data directly to the
> line discipline routines, to help reduce latency and jitter.  The CHU
> signal is supposed to be accurate to within 1ms, so I don't know if
> doing this optimization would be lost in the noise (however, I'm
> running this on a 25MHz 386, so maybe it wouldn't :-) ).  Comments?

I think what you want is to just take a timestamp in the interrupt
routine at character reception time, and then have the line discipline
use that timestamp rather than taking its own in the soft interrupt
handler.  You certainly don't need to run all the line discipline code
at high priority, just get the timestamp.  This is in fact just a
generalization of the DCD thing just added; in both cases you want a
timestamp soon after an interrupt, you just need to get them when a
character is received rather than when DCD toggles.  You also need
fifo-less serial hardware, or at least have a way to make it interrupt
as soon as a single character is received.  This would also cover the
needs of other older radio time hardware, most of the earlier stuff
wanted you to take subsecond timing by measuring the time at which
serial messages were received.

Not that it is necessarily going to improve the time you get a whole lot,
even the 1 ms is optimistic for CHU (we used to measure more than 1 ms
difference between the 14 MHz and 3.5 Mhz signals, with the difference
being propagation differences; day-to-night variation on any single
frequency is probably worse).  Since the DCD thing adds most of the
logic you need already, however, I seems like it would be a fine thing
to use it for this too.

Dennis Ferguson