RFC 5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification", June 2010

Note: This RFC has been updated by RFC 7822, RFC 8573, RFC 9109

Errata ID: 5604
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Takashi Nakamoto
Date Reported: 2019-01-15
Held for Document Update by: Erik Kline
Date Held: 2022-09-26

Section 11.2.3. says:

                  | s.rootdisp  <-- p.epsilon_r + p.epsilon + |
                  |                 p.psi + PHI * (s.t - p.t) |
                  |                 + |THETA|                 |

It should say:

                  | s.rootdisp  <-- p.epsilon_r + p.epsilon   |
                  |                 + 5 * p.psi +             |
                  |                 + PHI * (s.t - p.t)       |
                  |                 + |THETA|                 |

Notes:

In addition to the correction proposed in Errata ID 5601, I think that the formula to calculate the dispersion should be revised. The term "p.psi" should be multiplied by not one, but a larger value.

This is because the dispersion is defined as the statistics that represent the maximum error, so when it is calculated, it should take into account the maximum errors in the offset estimation. However, the jitter p.psi is defined as the RMS average of the offset values theta_j relative to theta_0, so the term "p.psi" does not represent the maximum error caused by the distribution of the offset values.

If we assume that the offset value follows the uniform distribution, the error bound is represented as sqrt(3) * p.psi. So, at least, the term "p.psi" should be multiplied by sqrt(3). There is arbitrarity in choice of the distribution type, so depending on the distribution type the factor may change. For example, if the normal distribution is assumed, 5 * p.psi gives us 99.99994% confidence. Assuming that the system variable is updated every 16 seconds, the actual offset may be outside the range [theta_0 - 5 * p.psi, theta_0 + 5 * p.psi] approximately once a year. It should be sufficient for usual Internet applications, though someone may think that the factor "5" may not be sufficient depending on the application.

---

[INT AD notes]

See also https://mailarchive.ietf.org/arch/msg/ntp/Cbg3sOhChyfenYoj7UG5wCymFMU/ :

"""
...That makes some sense to me, but I'd say it really depends on the model of the clock and that's arbitrary...
"""

Report New Errata