Thanks for the comments.
"Terry Moore" <tmm%mcci.com@localhost> writes:
> USB is not a very good way to do PPS synchronization if you're looking for
> usec resolution -- there are huge and unpredictable delays that can be
> introduced from a number of sources.
Agreed, but that's not the question on the table. It's "Should NetBSD
support gathering timestamps from DCD transitions on ucom(4) devices
using the RFC2783 API, or should it refuse to support that (on the
theory that we are certain that anyone who tries to use it is thereby
worse off, even though we do not understand their situation)?".
Thanks for the summary of issues. I did not know all of those details,
but did not find them too surprising. Still, it seems that there will
often be less than 1 ms of trouble in many situations.
> But using a serial port handshaking line over an emulated com port over USB
> is not likely to be terribly wonderful. Long-term accuracy (tick count)
> probably no problem, but jitter.... it will depend on how that's filtered. I
> suspect that the kernel's clock discipline loop is not likely to be happy if
> there's jitter on this particular reference.
The normal config would use ntp, which has filtering, and in my case it
seems decent, showing 155 us of jitter (it varies, but almost always
seems under 500 us).
remote refid st t when poll reach delay offset jitter
==============================================================================
oPPS(0) .BLOX. 0 l 9 16 377 0.000 1.359 0.155
+[redacted s1] .TRUE. 1 u 19 64 377 95.750 6.153 0.797
I should hook up a serial pps also, to compare, in addition to trying
this within a few network ms of a believed-ok s1. But the above seems
better than reading a serial timecode with a fudge.
Attachment:
pgpvEfPz5l84Q.pgp
Description: PGP signature