Date: Thu, 15 Aug 2019 23:05:10 +0200 From: Per Hedeland <per@hedeland.org> To: Ian Lepore <ian@freebsd.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: <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> In-Reply-To: <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.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> <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-08-15 17:49, Ian Lepore wrote: > 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. The thing that made me hypothesize that the kernel clock *could* have *something* to do with the USB polling frequency was this observation in https://blog.dan.drown.org/pps-over-usb (link provided by one of the posters in the newsgroup, though he didn't refer specifically to this): Looking closer at the USB latency, you can see the PPS drifting relative to the host schedule of polling the USB device for its status. The system clock error was 2.215ppm during this time period, and this drift matches that error exactly. This probably means USB on this system shares the same clock as the system clock. This hardware is a Raspberry Pi 2, and I suspect it won't be true for other platforms. So at least on RPi 2, there appears to be a relation between the "normal" system/kernel clock and the USB polling frequency. But I have no idea if there is such a relation on the system you used, and even in that case, *I* certainly can't see how using a different source for the kernel clock could affect the USB polling frequency, which is why asked if you thought that it was a possibility... > 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. Yes, the transmission speed is obviously not a problem, the question is about varying latency due to the polling. > 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. In the newsgroup it was claimed that the polling frequency was 1 kHz for USB 1.1 and 4 kHz for USB 2.0, but it seems it should indeed be 8 kHz for 2.0 "high" speed. And your test used one USB 1.1 device and one 2.0 device. And "a lot" is a bit subjective, but for any polling at a frequency that isn't an exact integral number of periods per second, there will be a latency between the start of the PPS pulse and the detection in the host that *varies* in an interval the size of the polling interval. I believe that interval should thus be expected to be 1000 microseconds for 1.1 and 125 microseconds for 2.0. Your ntpq output showed an offset close to 200 microseconds for both devices, and I *assumed* that it was more or less constant and thus ntpd could trivially be told to correct for it - but maybe that assumption was incorrect, there was only one instance of ntpq output? If it actually varied in an interval per above, I would expect the jitter to be significantly higher though. And if it *is* more or less constant, can you explain how this is possible? Even the 2.0 125 microsecond case should be clearly visible in the offset reported by ntpd across a sequence of ntpq requests. > 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. Well, I guess a problem here is that it's my confused head that is butted between yours and those of the supposedly-experts that participate in the NTP newsgroup/maillist:-) - you already declined to participate there, and I don't expect that any of them will take the trouble to participate here. Maybe we'll just have to leave it at that... --Per
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16c91be1-6f2a-b26d-22c7-be8e4ba8eec0>