Re: Display more digits for NTP packet's root dispersion

[Martin Burnicki <martin.burnicki () meinberg de>]

Guy Harris wrote:
> On Aug 6, 2018, at 2:19 PM, Guy Harris <guy () alum mit edu> wrote:
>
> > On Aug 6, 2018, at 4:20 AM, Martin Burnicki <martin.burnicki () meinberg de> wrote:
> >
> > > As far as I have seen, proto_tree_add_double() seems to add a double
> > > value to the output tree,
> >
> > *All* doubles use the same format string.  The part of the format string for the number is

This doesn't seem to be quite correct. At least the peer clock
precision, which is an 8 bit integer in the packet is displayed with a
fixed floating point format with 6 fractional digits, e.g. (from
different packets):

Peer Clock Precision: 0.000977 sec
Peer Clock Precision: 0.000004 sec

This is very clear, IMO.

> >      "%." G_STRINGIFY(DBL_DIG) "g"
> >
> > DBL_DIG is 15 with macOS/Xcode, so that should be %.15g, which should show more than 4 digits.
>
> At least on macOS, a root delay the octets of which are 0x00 0x00 0x00 0x01 displays, in the dissected NTP packet, as
>
>       Root Delay: 1.52587890625e-05 seconds
>
> Does it not do that on your machine?

I've investigated a little bit more, and in fact it turned out that I've
been using an old version of Wireshark which displayed the root
dispersion in a fixed format 0.0000 s.

Same seems to be the case for a customer with whom I've discussed a root
dispersion issue, and who told me the root dispersion he saw was 0 in
the Wireshark capture, even though it was not really 0, but just very small.

After I've updated Wireshark to the current version I can confirm that
both the root delay and the root dispersion are now shown in an
"automatic" floating point format, e.g. (from different packets):

  Root Delay: 0 seconds
  Root Delay: 0.0009765625 seconds
  Root Delay: 0.0035552978515625 seconds

  Root Dispersion: 7.62939453125e-005 seconds
  Root Dispersion: 0.0001983642578125 seconds
  Root Dispersion: 0.944107055664063 seconds
  Root Dispersion: 0.0693359375 seconds

This avoids displaying a value as 0 when in fact it is very small, but
not 0. However, on the other hand

 - it's harder to compare values when you quickly inspect different packets

 - it may pretend a much higher resolution (10 or even more fractional
digits of a second) even if the resolution in the protocol is limited.
E.g. 1 LSB of the root dispersion is ~15 microseconds, so it doesn't
make much sense to display femtoseconds with random numbers from the
scaling.

So IMO it would make more sense to display such values with a fixed
floating point format similar to the Peer Clock Precision field, e.g.

0.000000 instead of 0
0.944107 instead of 0.944107055664063
0.000076 instead of 7.62939453125e-005

Just my thoughts, though.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki () meinberg de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe