tech-kern archive

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

Re: pulse-per-second API status



>>> * ucom(4) needs pps support
>> It does?  I thought USB introduced delays which are both uncertain
>> and, in this context, large, [...]
> The delays introduced by USB are said to be on the order of 1 ms.

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.

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

[in another message]

> This patch to netbsd-5 adds pps support to ucom(4), [...]

> I have tested it with a GR301-W and the in-tree (-5) ntpd.  I am
> seeing offsets of about -100ms [...]

100ms is a lot worse than 1ms, and surely bad enough that stamping the
implicit approval of "it's in the tree" on this is a bad idea.  Or do
you really think your network is bad enough that 99ms of that is coming
from network asymmetry?

PPS with a lot of wobble in it may be better than a crappy network
connection.  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.  You, Greg, know better.  J-randoms who see what
looks to them like PPS support on ucom won't.

[back to the first message]

> So it depends on whether 1 ms of fuzz is "doesn't work".

Not quite: it also depends on how close (your impression of) what "[is]
said to be" is to reality.

> 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.

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.

My worry is not that it's not the best time available in some
circumstances.  My worry is that putting it into the tree will lead to
its getting used as if it were as good as PPS on anything else, leading
both to timeservers that claim stratum 1 but give bad chime and to
people blaming NetBSD for its crappy PPS support when the real problem
is that they don't understand the USB issues and it _looks_ like any
other PPS support until you test the resulting time carefully.

/~\ 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