Date: Sun, 18 Aug 2019 15:45:54 -0600 From: Ian Lepore <ian@freebsd.org> To: Ross Alexander <rwa@athabascau.ca>, freebsd-arm@freebsd.org Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. Message-ID: <804cfca3edf6d8d40a72257b4f1e876200721c48.camel@freebsd.org> In-Reply-To: <alpine.BSF.2.21.99999.352.1908151522260.30858@autopsy.pc.athabascau.ca> References: <alpine.BSF.2.21.99999.352.1908151522260.30858@autopsy.pc.athabascau.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2019-08-15 at 16:02 -0600, Ross Alexander wrote: > In <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org>, > Ian Lepore writes: > > > [... ed.] I arranged to use a very stable nearly-drift-free > > frequency source instead of a cheap crystal for counting time in the > > kernel. > > You have my complete and focussed attention. Say on. > I detailed the design of the measurement system in the original message. Basically it involves feeding a very stable external clock signal to a block of timer hardware within the imx6 SoC and using that timer hardware as the kernel clock. The source of the stable external clock has these specs: https://www.microsemi.com/product-directory/gps-instruments/4152-syncsystem-4380a I'm a software engineer for the division of Microsemi that makes those devices. If it wasn't the clock source you wanted to hear more about, then let me know in more detail what you'd like to know. > > [WRT USB 2, ed.] the polling happens in time slots that are 125 > > microseconds wide. There's just no reason for a lot of jitter or > > latency. > > 125 microseconds is a lot of jitter. Latency is a don't care, you can > fudge that out. Looking at a Pi 1b+, running some consumer grade > Ublocks GPS module, a five year old Linux, and with a view of only > half the sky (but using PPS on a GPIO pin): > It's negligible jitter for everyday computer use. It's a lot if you're doing something like timestamping financial transactions, or recording radio-astronomy observations, but the people doing that sort of thing usually aren't using ntpd to sync their clocks (they're using ieee- 1588, or custom solutions such as PCI irig input cards). But, as I detailed in the previous followup to Per Hedelund's post, I don't think there is a 125us latency or jitter introduced due to the usb bus frame rate. At least on the FTDI usb-serial chips I tested with, usb bulk transfers are used, and those are not limited to one transfer per bus frame or microframe. I'm still trying to find more info on the low-level usb part of this, because I was expecting to see average latency and jitter on the order of 50-60us each. That was based on an assumption I held until recently that on a usb 2.0 bus any given device would get an opportunity to deliver new data at most once every 125us, but now I don't think that limitation exists, at least for bulk transfers. > > autopsy:/u0/rwa > ntpq chime > > > > ntpq> lpee > > remote refid st t when poll reach delay offset jitter > > ============================================================================== > > oPPS(0) .PPS. 0 l 8 16 377 0.000 0.001 0.002 > > *SHM(0) .GPS. 5 l 6 16 377 0.000 419.464 310.013 > > > > ntpq> rl &1 > > associd=10146 status=911a conf, reach, sel_falsetick, 1 event, sys_peer, > > srcadr=PPS(0), srcport=123, dstadr=127.0.0.1, dstport=123, leap=00, > > stratum=0, precision=-20, rootdelay=0.000, rootdisp=0.000, refid=PPS, > > reftime=e1005453.fffff7a5 Thu, Aug 15 2019 15:59:47.999, > > rec=e1005454.debc0ef4 Thu, Aug 15 2019 15:59:48.870, reach=377, > > unreach=0, hmode=3, pmode=4, hpoll=4, ppoll=4, headway=0, flash=00 ok, > > keyid=0, ttl=0, offset=0.001, delay=0.000, dispersion=0.233, > > jitter=0.002, > > filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, > > filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, > > filtdisp= 0.00 0.24 0.48 0.72 0.96 1.20 1.44 1.68 > > > > ntpq> rl > > associd=0 status=0413 leap_none, sync_uhf_radio, 1 event, spike_detect, > > version="ntpd 4.2.7p397@1.2483-o Sun May 3 05:32:19 UTC 2015 (1)", > > processor="armv7l", system="Linux/4.1.12-v7+", leap=00, stratum=6, > > precision=-19, rootdelay=0.000, rootdisp=733.955, refid=SHM(0), > > reftime=e1005456.debbfb5d Thu, Aug 15 2019 15:59:50.870, > > clock=e100545c.084cd64c Thu, Aug 15 2019 15:59:56.032, peer=10147, tc=4, > > mintc=3, offset=0.000921, frequency=0.047, sys_jitter=310.013202, > > clk_jitter=0.000, clk_wander=0.000 > > The jitter is expressed in units of 1 millisecond, unless I am badly > mistaken; for which possibility I apologize in advance. > Yes, it's reported in milliseconds. The jitter number is the RMS of the differences between the offset from the measurement with the lowest delay for that peer and the other 7 offsets for that peer in the 8-step filter. That is, it finds the lowest delay, then it does, roughly: jitter = 0; for offset in {the other 7 samples that aren't the lowest delay} jitter += SQUARE(offset - lowest_delay_offset) then the final number is jitter = SQRT(jitter / 7) > (as an aside, has editing quotation text gone utterly out of style? > Present company excepted, of course.) > I tend to err on the side of not trimming away too much context when replying, so that people finding the thread from a web search some day will have enough context to interpret the hit they found without having to track down the entire thread and start from the beginning. > regards, > Ross >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?804cfca3edf6d8d40a72257b4f1e876200721c48.camel>