[ntp:questions] Garmin LVC 18x jitter problem
Michael Haardt
michael at moria.de
Sun Aug 11 12:03:12 UTC 2019
Jakob Bohm <jb-usenet at wisemo.com.invalid> 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 everything easier
to understand.
> Wishlist issue 2: Maybe also make fudgeminjitter available for network
> clocks, e.g. to describe a non-uniform packet jitter in a network path
> or non-uniform hardware jitter in a preferred site local higher stratum
> server.
Well, I would be rather surprised if the developers accepted the patch
as it is due to the described issues, and likely there is a better
place in the code to perform this function.
But it does show the problem analysis holds and I am quite happy with
the result:
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd 4.3.99 at 1.3699-o Wed Aug 7 17:29:04 UTC 2019 (3)",
processor="armv6l", system="Linux/4.19.50-1-ARCH", leap=00, stratum=1,
precision=-18, rootdelay=0.000, rootdisp=0.344, refid=PPS,
reftime=e0fa8018.c9990f56 Sun, Aug 11 2019 13:52:56.787,
clock=e0fa8020.9fe6beb8 Sun, Aug 11 2019 13:53:04.624, peer=48734, tc=4,
mintc=3, offset=0.000287, frequency=-9.938, sys_jitter=0.003815,
clk_jitter=0.004, clk_wander=0.000, tai=37, leapsec=201701010000,
expire=201912280000
Stable operation with these values is not possible without this change.
Now the question is how to do implement it in a better way.
Michael
More information about the questions
mailing list