Re: [Ntp] comments on draft‑mlichvar‑ntp‑ntpv5‑03

Root dispersion should have the same resolution as the time stamp.
With today's 16-bit field the smallest root dispersions are 0,   15.3,
30.5 ... microseconds.
What should an NTP server having 1 microsecond uncertainty return?

On Wed, Nov 24, 2021 at 10:18 PM Dan Drown <dan-ntp@drown.org> wrote:

> Quoting Miroslav Lichvar <mlichvar@redhat.com>:
> > On Wed, Nov 24, 2021 at 08:32:09AM +0100, Ulrich Windl wrote:
> >> I wonder: Up to NTPv3 floating-point math was avoided, but starting in
> NTPv4
> >> floating-point math is used.
> >
> > That is up to the implementation. The specification doesn't require
> > floating-point math, but it is easier to implement if you can use it.
>
> Floating point hardware is pretty common in embedded devices with an
> internet connection.  For example esp8266 and esp32 have single
> precision FPU hardware.  Cortex-M4/M7s have optional FPU hardware as
> well.
>
> > For internal calculations, you could keep everything in the 64-bit
> > format. Even in the NTPv5 packet we could do that, if we don't mind
> > wasting 16 octets per packet. The specification would certainly be
> > simpler.
>
> I don't see the value in 64 bits of root delay/dispersion.  Maybe the
> timescale offset field would benefit from more precision, but at the
> moment I prefer to keep it at 16 bits.
>
> > I implemented recently some of the NTPv5 ideas in chrony in an
> > experimental extension field. I noticed there is a minor compatibility
> > issue with the proposed time32 format and NTPv4. The maximum value is
> > not really 16, but slightly less than that. That means it cannot reach
> > the MAXDISP value from RFC5905. To avoid having to work with two
> > different MAXDISP values, we could specify an infinite value for the
> > maximum 32-bit value of the type.
>
> Defining 0xFFFFFFFF (15.999999996) to mean MAXDISP makes sense to me.
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>