RE: pulse-per-second API status

["Terry Moore" <tmm%mcci.com@localhost>]

I wasn't commenting on advisability of putting it into NetBSD. Just
responding because I had, for a change, something relevant to contribute.
(I actually know, in this case, what I'm talking about!)

If the time info is presented into NTP using the same interface that network
packets use, then jitter will be pretty well damped (and will be less, in
any case, than typical network packet transport jitter). It is totally an
application question as to whether this is good enough. I was assuming that,
since the jitter on local interrupts is much less than on network packets,
that there might be a different PLL tracking the data, as there are lots of
tradeoffs here. But if it works well, by all means use it.

And I know Mouse is more careful than I tend to be about terminology and so
forth; he is, if I understand correctly, arguing that PPS directly connected
is a lot different than PPS over USB, and so should be called something
else. I don't have an opinion on that. I believe that for critical
applications you'll get much less jitter using PPS directly connected; but
I'd have to do experiments and my day job calls....

Best regards,
--Terry

> -----Original Message-----
> From: tech-kern-owner%NetBSD.org@localhost 
> [mailto:tech-kern-owner%NetBSD.org@localhost] On
> Behalf Of Greg Troxel
> Sent: Friday, November 01, 2013 15:30
> To: Terry Moore
> Cc: tech-kern%NetBSD.org@localhost
> Subject: Re: pulse-per-second API status
> 
> 
> 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.