Skip site navigation (1)Skip section navigation (2)
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>