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

[Gary E. Miller]

Yo Miroslav!

On Mon, 15 Aug 2016 13:55:53 +0200
Miroslav Lichvar <address@hidden> wrote:

> On Fri, Aug 12, 2016 at 11:29:48AM -0700, Gary E. Miller wrote:
> > On Fri, 12 Aug 2016 11:52:34 +0200
> > Miroslav Lichvar <address@hidden> wrote:  
> > > As ntpd reads SHM only once per second,  
> > 
> > No.  Minimmum read on an unpatched ntpd is 8 seconds.  See
> > minpoll.  I prefer to have it at 16 or 32 for better stability.  
> 
> The minpoll and maxpoll options control how often ntpd polls the
> refclock driver, not how often the driver polls its source. The SHM
> driver reads the SHM segment once per second. E.g. if minpoll and
> maxpoll are 3, there will be 8 samples collected and filtered between
> clock updates. If you increase the polling interval, more samples will
> be collected between updates and that can improve the stability of the
> filtered offset.

I just dug into the code with ddrown.  I had no idea ntpd was
oversampling faster tham minpoll.  A very bad design, with a conceptual
error similar to the one that was recently in ntpshmmon.  This now
explains some of the defects I have seen for a long time in ntpd.  Like
a bias to slow ticks over fast ticks.  Asymetrical convergence and
osciilations in the convergence.

Nyquist is very clear, you can't sample a one second signal at one
second.  The results in ntpshmmon were aweful.  To see how awful, just
recompile ntpshmmon with a one second sample rate, then jiggle the sys
clock.  This explains a lot why PPS on ntpd behaves as badly as it does.

I have been looking at other software, like Lady Heather, that gets far
better PPS results than ntpd does.

Sadly I don't see this on the NTPsec timeline for a while, so much cruft...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

pgpJwi5_guwTD.pgp
Description: OpenPGP digital signature