Miroslav Lichvar writes:
> I think you do. To prevent the source from being rejected as a
> falseticker it needs to have a larger root distance. That could be from
> a larger dispersion or delay. You modified the refclock jitter, which
> ends up in the peer dispersion (after some weighting). Anoth
Miroslav Lichvar writes:
> On 2019-08-12, Michael Haardt wrote:
> > I would appreciate if we could focus on the major issues first, like
> > why the modified jitter is not shown by ntpq.
>
> I think the explanation is that you are modifying jitter of individual
> samples
Jakob Bohm writes:
> If this is done by setting all bytes of the memory to 0, this doesn't
> necessarily map to 0.0 in the floating point formats of all machines.
Correct. But it does work for modern systems, which is why the code works.
I already mentioned a flag should be used, which avoids th
Jakob Bohm writes:
> Minor issue 1: You seem not to initialize fudgeminjitter if not
> configured. Probably to 0.0
All values are initialized to 0 when the structs are allocated, I
checked that. That's why it works without a flag bit at all. I
still like the flag bits more, because they make e
By now I hacked ntpd for allowing to override the lower jitter bound,
which fixes the problem properly. The attached patch shows the current
state.
Good: It works! ntpd no longer drops the GPS as false ticker, which in
turn does not drop PPS that depends on the preferred peer, so everything
works
> ntpd was happy with 3.70, I haven't looked at later firmware version.
> (Garmin is up to version 4.20 now.)
I am using 4.20 due to the GPS week rollover.
> The graph shown in http://www.moria.de/~michael/tmp/offset.svg also shows
> high drift & jitter, though not as severe as the old
> release
David Woolley writes:
> On 12/07/2019 11:32, William Unruh wrote:
> > Do not use nmea as a time source. It it has a long delay ( hundreds of
> > ms) which depnds on the speed of connection, on length of the nmea
> > sentance, etc. EAch character takes from 100 of usec to ms to be
> > delivered, an
Hello David,
I trust the clock, because with constant temperature crystals perform
pretty good. The clock is disciplined with PPS, but no adjustments
happened during the measurement, so it runs with a constant frequency
offset. It took a few days to reach that state.
My point is that NMEA on th
I use a Garmin LVC 18x with a Raspberry Pi, process NMEA with gpsd
(SHM driver) and acess PPS by GPIO (kernel PPS driver). gpsd allows
monitoring and passing PPS right into ntpd avoids gpsd conversion of PPS.
Sometimes this works, but then there are times where both clocks are
thrown out as false
