gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] Garmin 18X-5Hz


From: Miroslav Lichvar
Subject: Re: [gpsd-users] Garmin 18X-5Hz
Date: Mon, 15 Aug 2016 15:43:48 +0200
User-agent: Mutt/1.6.2 (2016-07-01)

On Fri, Aug 12, 2016 at 11:37:22AM -0700, Gary E. Miller wrote:
> On Fri, 12 Aug 2016 10:52:02 +0200
> Miroslav Lichvar <address@hidden> wrote:
> > Yes, the stability of the clock is the most important factor here. If
> > the machine is just sitting idle all day, longer update intervals may
> > work better, but when the temperature starts changing rapidly due to
> > CPU or other components with variable power consumption, even 8 second
> > update interval may be too long to keep the kernel PLL locked. In such
> > case giving ntpd more samples by increasing the PPS rate would be
> > pointless.
> 
> Not my experience.  And not possible without patching your ntpd.

> For exammple:  https://pi3.rellim.com/day/
> 
> You'll notice I'm also graphing temps, at the bottom.
> 
> I would encourage you to setup some graphs and prove your point.

I think your graphs demonstrate the problem very well. The periodic
excursions of about 30 microseconds are exactly what I'm talking
about. When the cron job heats up the CPU, the loop is too slow to
handle such a rapid change in the frequency of the clock and a large
offset accumulates before it can catch up.

Halving the polling interval (which sets the time constant of the
loop) should halve the excursion. So, if you wanted to reduce it from
30 microseconds to 1 microsecond, you would need to lower minpoll by
5. Of course, this would hurt the accuracy when the frequency is
stable and add a huge amount of noise.

Ideally, the loop should be able to adjust the polling interval
automatically. The minpoll and maxpoll options can be set to different
values, but unfortunately the adaptation doesn't work very well. With
reference clocks the problem may be even more difficult to solve than
with NTP sources.

FWIW, chrony works much better in such conditions. Here are some
graphs from one of my machines when ntpd and chronyd were running with
polling interval of 8 seconds and operated in similar conditions.

http://i.imgur.com/0ma3Bdj.png
http://i.imgur.com/zh1YTia.png

While on the first graph (ntpd) the offset swings to about 12
microseconds, on the second graph (chronyd) there are only barely
visible blips of about 2 microseconds. You can also see one or two
places where the GPS signal was lost for a minute. Note that this is
the offset from the refclocks log, which is better for comparing with
the ntpd's loopstats offset than the tracking offset.

-- 
Miroslav Lichvar



reply via email to

[Prev in Thread] Current Thread [Next in Thread]