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

[Dan Drown <[e-mail]>]

Quoting Miroslav Lichvar <[e-mail]>:
> 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.