Re: [gpsd-dev] NO_HZ Avoidance

[Fred Wright]

On Fri, 1 Jul 2016, Gary E. Miller wrote:
> On Fri, 1 Jul 2016 20:33:38 -0700 (PDT)
> Fred Wright <address@hidden> wrote:
>
[...]
> > > Nope.  That is due to the sidereal day effects of the sat orbits.
> > > My
> >
> > That seems unlikely.  Each satellite has a different path through the
> > sky during its period of visibility, and of course satellites come
> > and go over periods of around six hours.  The probability that thwt
> > complicated mess could just happen to turn into something looking
> > very much like a daily sinusoid seems *very* unlikely.
>
> The GPS sats return to the exact same positions, as a group, every
> sideral day.

I'm perfectly aware of that.  But the notion that the cacophony of
satellite orbits could result in a simple sort-of-sinusoidal diurnal
variation is akin to expecting a kazoo to sound like a tuning fork.

You snipped the paragraph where I suggested an ionospheric explanation,
but it shows up in a paper here:

        http://tf.nist.gov/general/pdf/879.pdf

It notes that even observations of *single satellites* show variations
correlated with a diurnal cycle, rather than with the satellites' orbital
movement. It concludes that it's some combination of ionospheric errors
and ephemeris errors, without further breaking it down.  There's brief
mention of tests with a dual-frequency receiver, which should have been
able to exclude the ionospheric effect, though it doesn't look like that
was looked at very closely (and see the next section).

There's also a page from a metrology textbook showing GPS time variations:

https://books.google.com/books?id=80p7AgAAQBAJ&pg=PA510#v=onepage&q&f=false

Note that the single-frequency graph shows diurnal variations while the
dual-frequency graphs don't, which is entirely consistent with its being
an ionospheric effect.  In a dual-frequency receiver, the frequency
dependence of the ionospheric delay can be exploited to remove about 99.9%
of the variation.

In fact, the effect of ionospheric delays on GPS is used as a means of
*measuring* ionospheric variations, e.g.:

https://earth-planets-space.springeropen.com/articles/10.1186/s40623-015-0206-2


However, the real elephant in the room is the *magnitude* of the frequency
errors.  Your data shows frequency variations on the order of 1ppm p-p
(and I see something similar here).  Based on a frequency of ~1/86400 Hz,
that integrates to an offset variation of 13.75 *milliseconds* p-p.  I
seriously doubt that the PPS signal is wandering by that much with respect
to the UTC/GPS second boundary (and it would be several orders of
magnitude out of any typical published spec if it did).  Also, look at the
offset errors in the documents referenced above.  The largest variation
was on the order of 300ns.  So either:

1) The bulk of the variation is in the frequency of the clock oscillator
rather than GPS (as I'd originally suggested).

or

2) NTPd is lying about the relationship.

> This has been discused on time-nuts.  They consider it settled fact.
>
> If you want clarification, I suggest you go over there.

Math trumps time-nuts.

> > One would expect DGPS to help with that,
>
> I have a WAAS signal.  That provides the same corrections as DGPS.

I'm perfectly aware of that.  It's actually not exactly the same
corrections, but it's similar.  But *if* such corrections are in play,
then that would compensate out most of the GPS errors regardless of
origin, making the "it's GPS's fault" explanation even less likely.
However, I wouldn't put it past the manufacturers not to bother
incorporating differential corrections into the method of generating the
PPS signal (and ditto regarding dual-frequency-derived ionospheric
corrections).  Anything related to time is usually an afterthought in the
receiver design.

> > > Actually, if you look further down my URL, you'll see that a 20
> > > microSec offset between my local RasPi's is normal.  Or, you would
> > > se it, except for a reboot swamping the graph there.  Another
> > > generation or two of RasPi and it might be that it will get PTP.
> >
> > Highly unlikely unless they switch to a better processor.  I'm pretty
> > sure the NIC in the Pi has no hardware timestamping capability, and
> > of course it's a totally lame crock that's connected via USB.  An
> > undocumented USB controller with a binary blob for a driver, no less.
>
> I stand by my data.  I encourage you to replicate the experiment.

Huh?  I was responding to "Another generation or two of RasPi and it might
be that it will get PTP."  Not likely as long as they stick with Broadcom.
The only "data" that's relevant is "datasheets". :-)

> > > The RasPi also has some counter timers in it and some people have
> > > been connecting those to the CPU clock.  Way down on my todo list,
> > > but making the RasPi a cheap GPSDO , with variable frequency
> > > output, is a possibility.
> >
> > I'm pretty sure the Pi has no ability to time a GPIO signal with
> > hardware. If you know otherwise, feel free to post the section of the
> > documentation.
>
> Check out PWM mode:
>
> https://www.npmjs.com/package/raspi-llio
> https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

That's for *outputting* signals in a configurable way.  It's of no use in
timing an input signal.

BTW, it appears that FreeBSD already has full support for timing the PPS
signal with hardware on the BBB, but I see no equivalent for Linux:

http://web.mit.edu/freebsd/head/sys/arm/ti/am335x/am335x_dmtimer.c

> > > > To measure it less invasively, I'd want to patch the KPPS driver
> > > > to *output* a PPS signal right at the time that it timestamps the
> > > > incoming PPS event, so that one could observe the latency on a
> > > > 'scope.
> > >
> > > I believe that kernel driver exists.  I'd love to hear your
> > > results.
> >
> > It would have to be part of the KPPS driver itself to be useful.
>
> That was also my understanding.

I see an "echo" option in the KPPS driver, but that appears to output a
text message in response to the PPS event, not drive a GPIO.  And the way
the driver is configured has no way to specify a second GPIO for the
purpose, anyway.

Fred Wright