tech-kern archive

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

Re: pulse-per-second API status



Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

I now think the 100ms was due to the wrong polarity on the pps signal
From this device.  After fixing that, I'm seeing times that are within 5
ms (well within expected network asymmetry), and currently the jitter is
0.169 ms.  (I still need to figure out if I have a bug in the code that
inverts the DCD sense, vs the device being odd.)

> I find "said to be" somewhat less than reassuring.  It's been a while
> since I read the relevant doc, but I think this depends heavily on how
> often the host interface is configured to poll the device.  The fuzzy
> memory also reports that there are different intervals configurable; I
> don't remember what they were, but I also don't know what NetBSD does
> for that, so that doesn't mean much.

By 'said to be', I meant people on the gpsd list who are using this on
other operating systems and looking at what happens.

> Also, see below - 1ms strikes me as pretty bad for PPS.

Sure, but it's vastly better than nmea timecode, which is what the other
choice is.

> But if NetBSD enables PPS on ucom, there's going to be an expectation
> that it is good enough for stratum-1 timekeeping, like PPS on real
> serial ports.

I don't think there's any such expectation created.

>> I would say that if the next best option is worse than that (nmea
>> timecode over the same USB, or asymmetic delays over the Internet),
>> then it does work, even if a real serial port would be better.
>
> It does work in the sense that it's the best chime available in that
> dismal a situation.

It's not that dismal - it's pretty typical.

> But it still may not work in the sense of living up to the expectations
> people have come to have for PPS on serial ports.

People who expect the same as serial PPS are confused, and we are not
responsible for that.  1 ms (if it is that, and it seems to be) is
decent compared to non-local networks.  And it's better than
interpreting NMEA or some other timecode on serial, and one can
configure that to be s1.  If the facility were such that no reasonable
person would ever use it, that would be something else, but it's far
better than that.

I'll also try this on -6 at work, and compare to s1 at MIT that's only
2ms RTT away.

Attachment: pgpHlhKgMgpUr.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index