Date: Thu, 15 Aug 2019 09:49:08 -0600 From: Ian Lepore <ian@freebsd.org> To: Per Hedeland <per@hedeland.org> Cc: freebsd-arm@freebsd.org Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. Message-ID: <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> In-Reply-To: <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org> References: <alpine.BSF.2.21.99999.352.1908071046410.98975@autopsy.pc.athabascau.ca> <69a9bed3-4d0a-f8f6-91af-a8f7d84ee307@hedeland.org> <345bae77417c2495f55799b4c7ca2784f4ece9ed.camel@freebsd.org> <7312032d-2908-9414-0445-6b442c3a02e5@hedeland.org> <523b6f0a0fa5f2aeec298fa74df25d3c4af66acc.camel@freebsd.org> <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2019-08-15 at 13:46 +0200, Per Hedeland wrote: > On 2019-08-09 22:17, Ian Lepore wrote: > > On Fri, 2019-08-09 at 21:36 +0200, Per Hedeland wrote: > > > On 2019-08-09 17:28, Ian Lepore wrote: > > > > On Thu, 2019-08-08 at 22:26 +0200, Per Hedeland wrote: > > > > > On 2019-08-07 18:53, Ross Alexander wrote: > > > > > > In Message-ID: < > > > > > > B9EFA4D4-C1AD-4181-B421-F6BD53434FA5@dons.net.au>, > > > > > > someone wrote [sorry, attrib trail is a little blurry ed.]: > > > > > > > > > > > > > > Most people are not worried about their kernel clock > > > > > > > > being > > > > > > > > 200 > > > > > > > > microseconds off from UTC, even if they're using the > > > > > > > > PPS > > > > > > > > signal > > > > > > > > from a > > > > > > > > GPS receiver. So I think most people should feel > > > > > > > > completely at > > > > > > > > ease > > > > > > > > using a USB serial adapter as the input device for a > > > > > > > > PPS > > > > > > > > signal. > > > > > > > > > > > > Some people do worry, although getting PPS to work over USB > > > > > > is > > > > > > a > > > > > > fine > > > > > > first step and I'm grateful for the breadcrumb trail. > > > > > > > > > > For those that do worry, you can of course tell ntpd to > > > > > correct > > > > > for a > > > > > semi-fixed offset (via the 'time1' option to the 'fudge' > > > > > command) > > > > > - > > > > > once you know how large the offset is... More important is a > > > > > low > > > > > jitter, and 20-30 microseconds seems quite good. > > [snip] > > > > Would you object to > > > me posting an article with a *link* to your message > > > (i.e. > > > https://lists.freebsd.org/pipermail/freebsd-arm/2019-August/020263.html > > > ) > > > in the newsgroup? > > > > It might be better to use the link to the copy I sent to the > > freebsd- > > usb list, since it's more directly on-topic: > > > > https://lists.freebsd.org/pipermail/freebsd-usb/2019-August/016078.html > > > > I also think it would be wise to add a caveat that the results are > > for > > FreeBSD. I would expect linux performance to be similar. But for > > Windows, all bets are off; Windows drivers for usb-serial devices > > are > > said to vary wildly in quality depending on the vendor. > > OK, I took it to the newsgroup, and while the initial comments were > pretty much "it's impossible to get good results via USB" even though > your test seemed to show that it wasn't, after some discussion it > seems quite strange to me too that you get a pretty much fixed offset > and low jitter, since the USB communication including DCD/CTS > detection is apparently based on polling from the host. > > I have a theory that your making the kernel clock be based on the 10 > MHz clock also ended up locking the USB poll frequency to that clock, > and thus to the PPS signal - this would certainly explain the result. > Do you think this is a possibility? Would it be possible for you to > re-run the test without modifying the kernel clock? (I do understand > that the results will be harder to interpret with the drift, and > ntpd's correction of it, coming into play.) > > --Per > I'm not sure what you mean by "modifying the kernel clock". The kernel clock always runs on some frequency source. Typically it's derived from the cheap 24 MHz crystal that clocks the SoC, sometimes after being scaled up to 66 MHz by a phase-fractional PLL within the SoC. I arranged to use a very stable nearly-drift-free frequency source instead of a cheap crystal for counting time in the kernel. The kernel clock has nothing to do with usb, including polling intervals; the usb controller hardware handles that, and the root source clock for that is the cheap 24 MHz crystal. I think people are massively confused by usb. A usb 2.0 bus runs at 480MHz. That means the time to transmit a packet describing a usb serial pin-change event takes literally a dozen or so nanoseconds. The time it takes to transmit an entire sector of disk data is 2 microseconds; even if continuous disk data is flowing, the usb serial adapter gets its round-robin opportunity to send a packet on the bus in between them. A USB 2.0 bus spends most of its time idle. The devices on the bus are polled, but the polling happens in time slots that are 125 microseconds wide. There's just no reason for a lot of jitter or latency. I'm not on a crusade to change the minds of people who make judgements based on gut feelings and reject objective measurements. I put the measurements out there, and I described the measurement methodology. (Precision timing is what I do for a living, btw.) I'm perfectly willing to explain the methodology in more detail or help interpret the results, but I'm not going to butt heads with people who just reject data they don't like for emotional reasons. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24b0eaf25b64d6098b390df092866c69e352d859.camel>