>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

Solely from an NTP perspective, trading off reduced latency and (more
importantly) reduced jitter for lower serial throughput is Always Good.

Since the CHU signal doesn't itself have a PPS signal, you cannot get
around latency variations by using a PPS.

You're proposing we test the line discipline in the hard-interrupt
service routine, and for ``NTP'' disciplines, handling the ldisc stuff
immediately rather than deferring?

I think the real question is, can this NTP optimization be done
without adversely affecting the quality of the serial driver(s)
concerned.  I'd run this by whoever maintains the relevant serial
drivers.

> (however, I'm
>running this on a 25MHz 386, so maybe it wouldn't :-) ).  Comments?

NetBSD's interrupt latency on a 133MHz Pentium is about 8-9 usec (vs
FreeBSD's quoted 6 usec).  On a 33MHz 486 its about 60 usec. (check the
xntpd html on pps for more quotable numbers.)

I understand this is "for cheap", but spending the $$$ to get either a
PPS signal or a faster CPU (or both) is going to make a *huge*
difference to NTP quality.  Five or ten years ago this would be an
obvious win, but with lowend GPS handhelds as low as $99 and sure to
drop further, I really wonder if this is worth it.

Umm,  I just realized: are you asking about for  your own machine,
or as a change to be pulled into the NetBSD tree?