tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pulse-per-second API status



>> [...PPS..."real" serial hardware....]

> Not just PPS on serial ports, but PPS on other hardware.

Well, a serial port is the only hardware I'm familiar with that gets
used for getting PPS into general-purpose computers; while of course
there are lots of other possibilities, I don't recall hearing any
others mentioned on the timekeeping lists I'm on.  (Not that I've gone
looking, mind you; this is just what I've heard mentioned.)

> I don't know this API.  But my first reaction when I saw the designation "PP$

As I understand it, that - especially the GPS version - is exactly
what's under discussion here.  The PPS line gets hooked to a
serial-line pin that can be configured to generate an interrupt
(carrier detect is a popular one, AIUI) and the kernel captures the
relevant timestamp off that interrupt.

In normal operation, interrupt latency is the major source of jitter by
the time the PPS signal (which is often, as you note, accurate to the
level where wire length is important) makes it through to the
timekeeping code.  With a bit of care (such as capturing a timestamp in
the hard interrupt handler), this error can be kept relatively low -
well below millisecond levels on many machines.  But USB's "the host
drives everything" design, while fine for a lot of things, fails badly
here, introducing an unavoidable and (in this context) large delay
between the line changing and the kernel noticing the change.

This could be corrected for.  But that requires designed-for-PPS USB
hardware, which normal serial ports don't have.  (For example, if the
USB device had a high-frequency oscillator sampled when the signal
changed and when communicating with the host, with all timestamps
passed up to the host, this could be used to compute an accurate
timestamp despite USB's issues.)

> It seems rather confusing to have another interface that goes by the same na$

Because it's not really another interface.  The "6 orders of magnitude
worse" is exactly the reason I think it shouldn't look to a naïve user
like "PPS works on ucom".  Inaccuracy to somewhere around the
microsecond level is unavoidable without special-purpose hardware,
simply because of interrupt latency.  I'm worried that USB will make
that a lot worse, and most people will not be competent to expect that.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index