Date: Mon, 19 Aug 2019 11:26:17 -0600 (MDT) From: Ross Alexander <rwa@athabascau.ca> 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: <alpine.BSF.2.21.99999.352.1908191107500.53123@autopsy.pc.athabascau.ca> In-Reply-To: <804cfca3edf6d8d40a72257b4f1e876200721c48.camel@freebsd.org> References: <alpine.BSF.2.21.99999.352.1908151522260.30858@autopsy.pc.athabascau.ca> <804cfca3edf6d8d40a72257b4f1e876200721c48.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 18 Aug 2019, Ian Lepore wrote: > 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-syncsyst= em-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. No, the clock source is the ticket. I've got a TAPR clockblock lying around somewhere, and have been meaning to pick up a precision 10 MHz source from eBay (or equiv.) for some time. In the meantime I've just ovenized the whole Pi, all you need is a shoebox and an old towel :). > [...] I said: >> 125 microseconds is a lot of jitter. [...] > 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). I'm measuring packet roundtrip times to regional campii and that sort of thing. We're linked to various tier-3 carriers via a provincial gov't MPLS network that makes QOS questions rather opaque, and this is one of the things I do to probe it. I wrote: >> [...] >> 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 =3D 0; > for offset in {the other 7 samples that aren't the lowest delay} > jitter +=3D SQUARE(offset - lowest_delay_offset) > > then the final number is > > jitter =3D SQRT(jitter / 7) That is a fine thing to have clarified. I've dug into the code, but only because I wanted to run multiple sound card radio modems (two WWV and two CHU) to deal with varying HF propagation and path dropouts. Obviously those patches were a long way from the actual PLL logic at the core of the protocol. regards, Ross =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Ross Alexander, (780) 675-6823 desk / (780) 689-0749 cell, rwa@athabascau.c= a 54.71593 N 113.30835 W, ve6pdq Order is simply a thin, perilous condition we try to impose on the basic reality of chaos. -- William Gaddis, _J R_ -- This communication is intended for the use of the recipient to whom it is a= ddressed, and may contain confidential, personal, and or privileged informa= tion. Please contact us immediately if you are not the intended recipient o= f this communication, and do not copy, distribute, or take action relying o= n it. Any communications received in error, or subsequent reply, should be = deleted or destroyed. ---
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.21.99999.352.1908191107500.53123>