[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