> 
> >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.
> 
> Uh, but *which* char should it be timestamping? (All of them?)
> 
> Ken Hornstein says the gadget box doesnt give a PPS signal from CHU.

All of them.  CHU sends a ten or twelve byte string using standard
300 bps modem tones, 10 times per minute.  Each byte is transmitted
at a precise, well-known time with respect to the on-time second, so
the arrival of each byte represents a time-of-day sample, the collection
of which the xntp driver filters into an offset estimate applied every
minute.

The line discipline only does two things.  It records a timestamp
when each character arrives, and it sanity checks the 10 or 12 bytes
before delivering them, in a clump with the timestamps, to user
space.  The timestamps could be taken at interrupt level to very
good effect, but it makes no sense to run the sanity checking there,
the latter is really only done for efficiency (to decode CHU you
effectively plug the serial port into the speaker output of a short
wave radio; it isn't uncommon to receive long strings of garbage when
the signal is weak, and it is cheaper to toss it away in the kernel
rather than delivering it to user space to toss away).

I'd note that there are other serial time codes which do want the
time taken only on a particular character (say, the newline at the
end of the string).  Even for these, however, it is probably simpler
and less trouble overall just to timestamp every character that
arrives in the hardware interrupt handler, and then throw away
all of them except the one you want to keep at soft interrupt time.
microtime() is pretty cheap on a lot of machines.

> >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.
> 
> I thought so too, but without PPS, I dont see how it helps, and if Ken
> did have PPS, hed just use DCD timestamps directly.

You can compute accurate time from events independent of whether they
occur on the on-time second or not, just as long as you can timestamp
the event consistently and you know the time they were expected to
occur.  For CHU the events you want to timestamp are character arrivals,
rather than DCD transitions, and they don't happen to occur at an
on-time second, but the argument for getting as-accurate-as-possible
timestamps for the events when they do occur is the same in any
case.

It is the case that you can't use the data from CHU to directly drive
the in-kernel PPS steering code, as it needs to be filtered through
user space, but that issue is sort of orthogonal to the mechanism for
taking timestamps in the serial handler (I also don't think the in-kernel
PPS steering gives a better result than can be obtained by adjustments
from user space, but that is a different discussion).

Dennis Ferguson