David Woolley <david@ex.djwhome.demon.invalid> 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, and the lengthof sentences is variable, and the gps sends out
> > a sentence only when it is not terribly busy ( which depends on how many
> > sattelites it is trying to handle, etc) It is good for setting the
> > seconds (sometimes-- if you ask it to send too many sentences it can be
> > out by more than a second totally messing up your timing).
> > One sentence (RMA) and a high baud rate make it useful for setting the
> > second.
>
> I believe the OP is using it for seconds. The problem is, I think, that
> ntpd will only use it, and only accept the PPS, if it is a true chimer.
Exactly. I need NMEA for seconds only _and_ it must be accepted as
true chimer, otherwise PPS does not work.
> Moreover, I think the OP's problem is that the NMEA timing is too
> repeatable, so its root dispersion is too small to cover the static
> error, although, if they had a lot of jitter, they would then advertise
> a root dispersion that doesn't give credit to the PPS accuracy.
Almost: The NMEA timing is too repeatable, so its root dispersion is too
small for covering the /actual dynamic/ error, so once the jitter center
moves, which it does in unpredictable ways, I get a falseticker.
The static error is already configured:
fudge 127.127.28.0 time1 0.518 refid GPS
The time1 was measured by peerstats for some days and agrees with the
value documented in other installations.
Of course the root cause is awful NMEA jitter behaviour by the device,
but I can't change that, and the LVC 18x is already one of the better
devices. If the jitter was gauss distributed or equally distributed,
ntp would estimate the jitter correctly. The window had to cover a few
days as it is, which is not feasible.
I would prefer setting a minimum instead of a fixed NMEA jitter to allow
ntpd still calculating the jitter value and kicking NMEA out as false
ticker in case of malfunction. I just need ntpd not to believe the low
NMEA root dispersion it often sees. :) Some examples, just a minute
apart:
remote refid st t when poll reach delay offset jitter
==============================================================================
*SHM(0) .GPS. 0 l 6 16 377 0.000 -17.468 18.600
*SHM(0) .GPS. 0 l 6 16 377 0.000 21.772 20.134
*SHM(0) .GPS. 0 l 3 16 377 0.000 13.032 8.446
In the second and third example, the GPS jitter window around the GPS
offset no longer covers the PPS jitter window around the PPS offset,
because the GPS jitter value does not react quickly enough.
Without setting "tos mindist 0.1", once PPS is used, the root dispersion
of my clock is determined by PPS and very low - until the falseticker
problem kills it.
I noticed chrony allows to set a "precision" value, but from the
documentation it was not clear if that's the jitter value and if it just
enforces a minimum or sets it fixed. That option does not exist in ntpd.
Michael
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
