4 ms·

This might be fixed by NTPv5; the proposed draft RFC I looked at (https://datatracker.ietf.org/doc/draft-mlichvar-ntp-ntpv5/05/ https://datatracker.ietf.org/doc

• toomuchtodo 4y ago
  Can the server provide both a smeared and non smeared response simultaneously, with the client electing which correction to apply? This would make the process more deterministic, versus the uncertainty of what time you’re being provided actually is.
• amluto 4y ago
  Oof, I feel like I should send a comment. This is bad: 1. There is no definition of what the leap smeared timescale means. This may prevent a client from usefully synchronizing with multiple servers using that timescale. 2. There’s enough information in the messages to compute leap smeared time. (The leap second indicator along with UTC is sufficient.). Chrony does this. As a result, it seems like it would never actually make sense for servers to synchronize to each other in smeared mode.