Murdock results

✔️ PASSED

acf10d9 sys/net/ntp_packet: add ref to SNTP, fix time

Artifacts

• Documentation preview

Do we really need microsecond precision for that? Wouldn't ztimer_msec (and 32-bit accuracy) be enough for the type of time-synchronization that SNTP offers?

To be honest: I don't know 🤷

Indeed RFC 5905 only mentions millisecond accuracy, so it indeed seems overkill to allow for microsecond precision here. However, the current implementation indeed gives microsecond accuracy so it is out of scope for this PR to change it IMO.

A follow-up could introduce a millisecond precision (pseudo)module and deprecate the old API to be removed following the usual deprecation process.

Indeed RFC 5905 only mentions millisecond accuracy, so it indeed seems overkill to allow for microsecond precision here. However, the current implementation indeed gives microsecond accuracy so it is out of scope for this PR to change it IMO.

Well this PR changes from xtimer to ztimer. While with xtimer the timing-precision does not have any influence on power consumption, with ztimer it does. The millisecond timer is much more power-saving, while the 64-bit accuracy microsecond timer is very power-consuming. If one wants to migrate, why not make it properly. So yes, I think this is in scope of this PR.

Indeed RFC 5905 only mentions millisecond accuracy, so it indeed seems overkill to allow for microsecond precision here. However, the current implementation indeed gives microsecond accuracy so it is out of scope for this PR to change it IMO.

A follow-up could introduce a millisecond precision (pseudo)module and deprecate the old API to be removed following the usual deprecation process.

The abstract

NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend
the potential accuracy to the tens of microseconds with modern
workstations and fast LANs.

> grep -ni millisec rfc5905.txt
211:   servers and clients are precise within a few tens of milliseconds
> grep -ni microsec rfc5905.txt
28:   the potential accuracy to the tens of microseconds with modern
208:   few tens of microseconds.  Typical secondary servers and clients on
209:   fast LANs are within a few hundred microseconds with poll intervals
1170:   corresponds to a precision of about one microsecond.  The precision
4103: * 32-bit words in seconds and microseconds (timeval) or nanoseconds

should be

... 1900-01-01 00:00:00 UTC 

maybe you can fix that

The millisecond timer is much more power-saving, while the 64-bit accuracy microsecond timer is very power-consuming. If one wants to migrate, why not make it properly. So yes, I think this is in scope of this PR.

Sure, but the xtimer was also power-consuming wasn't it? I would only say this is strictly in scope of this PR if it would introduce a (power consumption) regression. That said, I wouldn't mind having the change to millisecond precision in here already :)

I had to put this on the backburner for some time.
As a compromise I can add a note to the documentation that sntp currently is not power efficient. We want to use it in future projects, so additional improvements are planned and one of them could be to improve the power efficiency.

Changing from Microsecond to Millisecond precision would also require an API extension (because get microseconds would be pointless if we don't actually get microseconds) and a deprecation of the other function etc.

I agree that moving to milliseonds is out of scope.

There actually is another benefit in moving to milliseonds: Better frequency stability of RTT compared to periph_timer in many cases, as RTT is often backed by a 32.678 kHz watch crystal, while the high frequency clock domain is typically generated from some DCO / PLL that has a lot of drift.

If we were to e.g. sync only a few times a day, using ZTIMER_MSEC will provide a major improvement in accuracy.

I'm personally fine with either adding a note that SNTP is not power efficient / accurate, or merging as is. Hopefully someone can find time soonish for the us --> ms shift.