Date: Sun, 18 Aug 2019 15:57:52 -0600 From: Ian Lepore <ian@freebsd.org> To: Per Hedeland <per@hedeland.org> Cc: freebsd-arm@freebsd.org, Hans Petter Selasky <hselasky@FreeBSD.org> Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. Message-ID: <cd1b38bb0b8873af96a41bce1b03676f735ae3f9.camel@freebsd.org> In-Reply-To: <fe2c2d77-3030-6734-e1d8-c1375f231a24@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> <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> <72a964c78cbfc36be2345919633ca2196f0783e3.camel@freebsd.org> <fe2c2d77-3030-6734-e1d8-c1375f231a24@hedeland.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2019-08-18 at 22:53 +0200, Per Hedeland wrote: > > > > I probably should have been clearer that I meant there was no > > correlation between the kernel clock and the usb polling on the system > > I was using as a testbed. On most SoCs, and probably even modern x86 > > systems, the same frequency source (typically a 24MHz crystal) will be > > the root clock for both the usb controller hardware and the timer > > hardware from which the kernel clock is derived. However, the kernel > > clock is numerically steered to be more stable in frequency and > > accurate in phase, so once ntpd has been running for long enough to > > capture and disipline the kernel clock, the situation will change. The > > usb polling will still be happening at the drifting frequency of the > > underlying crystal, while the kernel timestamps used to mark the PPS > > pulse time will not be drifting at that rate. > > Understood. What I don't understand is if, and if so how, your > "replacing" the kernel clock with an "exact" frequency from your 10 > MHz clock might affect the USB polling. I don't think there is any connection at all. As I vaguely understand it, the usb ehci driver sets up lists of transfers to be done in memory and hands the ehci hardware a pointer to that list, and the hardware executes everything based on its own internal timers (which are ultimately sourced from the 24mhz clock). It's not like the OS has to periodically wake up and tell the ehci hardware "now is the time to do some polling". > > I think there is some confusion around the concept of usb 1.x devices > > on a usb 2.0 bus. I think there may even be some confusion when a 1.x > > bus is involved. And then adding to the confusion is the likelyhood > > that different usb-serial adapters use different usb transfer types > > (bulk vs interrupt)_to communicate line-state changes. > > > > A usb 1.x bus is divided into 1ms frames. A 2.0 bus is divided into > > 125us (micro-)frames. For interrupt endpoints, a usb 1.x bus limits > > devices to 1 interrupt transfer per frame, and that may imply that > > there is up to 1ms of latency for reporting a DCD change on such a 1.x > > bus. A 2.0 bus allows up to 3 interrupt transfers per microframe, > > implying latency of up to 125us. > > > > However, there is no limit on either 1.x or 2.0 busses for how many > > bulk transfers can happen to a given endpoint during a frame. The > > controller needs to fill a frame with transactions in a way that first > > provides all the g'teed bandwidth that is promised to control, > > interrupt, and isochronous transfers. It is then free to fill all the > > remaining time with bulk transfers. > > > > To me, this implies that you may end up with nearly no latency (and > > negligible jitter) if you have a usb 2.0 bus that has just one or two > > devices on it which are communicating via bulk-transfer endpoints. The > > controller would be continuously sending BULK IN tokens to the one or > > two devices, so that as soon as one of them has data, it gets an > > opportunity to deliver it almost immediately (meaning within a few > > microseconds). > > > > The results I see with FTDI usb-serial adapters which use bulk > > transfers provide some evidence that my theory may be correct. I think > > the bus looks like this: > > > > BULK IN token to usb 1.x device (do you have anything to say?) > > 1.x device NAKs > > BULK IN token to usb 2.0 device > > 2.0 device NAKs > > <no significant amount of time elapses here> > > BULK IN token to usb 1.x device > > 1.x device NAKs > > ... (repeat forever) > > > > In other words, the device(s) aren't getting 1 chance per frame to > > transfer data, they are getting many thousands of chances per second. > > I think the bus overhead of the BULK-IN token followed by a NAK from > > the device, along with the various framing bits and crc and all that > > probably adds up to less than 64 bytes per poll. But assuming it took > > as much as 64 bytes to do that, if there was one usb-serial device on a > > usb 2.0 bus, it would be getting asked about 1 million times per second > > whether it had anything to say. > > This is extremely interesting - if it really is the case that the > will poll "as fast as it can", as opposed to always doing it with a > fixed frequency, it would definitely change the picture. Unfortunately > I haven't seen any documentation to support that this is the case. > > I'd welcome input from low-level USB gurus about the bus and controller > > behavior in this regard. > > I'm afraid we have lost freebsd-usb@ in this sub-thread (it was actually > the case before my first comment, but it would probably have happened > anyway, since I'm not subscribed to that list). Unless you know that > "low-level USB gurus" are also subscribed to freebsd-arm@, it might make > sense to forward your message to freebsd-usb@. I think HPS reads the arm@ list, but I'll cc him directly on this reply, just in case he has time to weigh in on this stuff. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cd1b38bb0b8873af96a41bce1b03676f735ae3f9.camel>