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

Sorry, forgot to replay to all:
---

Hi!

That might be an issue, even though our GPS server has a root dispersion in
the 200µs range (DCF-77 in the 2000µs range).
Related question: What is the smalles amount added to the root dispersion? If
it's more than the resolution, the resolution seems unimportant.
PHI being 15PPM means 15µs added per second.

So for the GPS sampling might look like this:
ntpq> rl
rootdisp=0.140
ntpq> rl
rootdisp=0.140
ntpq> rl
rootdisp=0.155
ntpq> rl
rootdisp=0.170
ntpq> rl
rootdisp=0.230
ntpq> rl
rootdisp=0.245
ntpq> rl
rootdisp=0.140

Regards,
Ulrich

>>> Steven Sommars <stevesommarsntp@gmail.com> schrieb am 25.11.2021 um 18:24
in
Nachricht
<CAD4huA7h7eGcGe1o+vbnDe4DVgrGCQKCXf=J1nV07gSW_6=QSA@mail.gmail.com>:
> 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 
>>