I am currently working on making sure NTP works according to the RFC 5905 and we use NTP.org implementation of ntpd. I have been going through the RFC and NTP.org’s documentation and have a query regarding the use of iburst and burst options.

Extract from RFC-5905 (RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification (rfc-editor.org))

13.2. Poll Process Operations

As described previously, once each second the clock-adjust process is
called. This routine calls the poll routine for each association in
turn. If the time for the next poll message is greater than the
seconds counter, the routine returns immediately. Symmetric (modes
1, 2), client (mode 3), and broadcast server (mode 5) associations
routinely send packets. A broadcast client (mode 6) association runs
the routine to update the reach and unreach variables, but does not
send packets. The poll process calls the transmit process to send a
packet. If in a burst (burst > 0), nothing further is done except
call the poll update routine to set the next poll interval.

If not in a burst, the reach variable is shifted left by one bit,
with zero replacing the rightmost bit. If the server has not been
heard for the last three poll intervals, the clock filter routine is
called to increase the dispersion. An example is shown in
Appendix A.5.7.3.

If the BURST flag is lit and the server is reachable and a valid
source of synchronization is available, the client sends a burst of
BCOUNT (8) packets at each poll interval. The interval between
packets in the burst is two seconds. This is useful to accurately
measure jitter with long poll intervals. If the IBURST flag is lit
and this is the first packet sent when the server has been
unreachable, the client sends a burst. This is useful to quickly
reduce the synchronization distance below the distance threshold and
synchronize the clock.

Extract from NTP.org (https://www.ntp.org/documentation/4.2.8-series/poll/)

As an option of the server command, instead of a single packet, the poll process can send a burst of several packets at 2-s intervals. This is designed to reduce the time to synchronize the clock at initial startup (iburst) and/or to reduce the phase noise at the longer poll intervals (burst). The iburst option is effective only when the server is unreachable, while the burst option is effective only when the server is reachable. The two options are independent of each other and both can be enabled at the same time.

For the iburst option the number of packets in the burst is six, which is the number normally needed to synchronize the clock; for the burst option, the number of packets in the burst is determined by the difference between the current poll exponent and the minimum poll exponent as a power of 2. For instance, with the default minimum poll exponent of 6 (64 s), only one packet is sent for every poll, while the full number of eight packets is sent at poll exponents of 9 (512 s) or more. This insures that the average headway will never exceed the minimum headway.

I am confused about how exactly the iburst and burst options work. My questions are:
1. How many packets are sent from the client when we are using iburst option? 6 OR 8?
2. If the IBURST flag is lit and this is the first packet sent when the server has been unreachable, the client sends a burst. How many packets are sent in this situation?
3. How many packets are sent from the client when using the burst option?
4. When using burst option, does the client send 8 packets in a burst at each poll interval? Or does it follow this “for the burst option, the number of packets in the burst is determined by the difference between the current poll exponent and the minimum poll exponent as a power of 2.”?
5. The BCOUNT variable count is 8 according to RFC5905? Does this apply to iburst as well or only when using burst?
6. If possible, can you please give me an example to explain the operation of iburst and burst and numbers of packets being sent using each option?

I would be grateful if anyone from the experts here could please provide your advice on this and help me understand the protocol better so that we follow the correct protocol rules.

Thank you.

On 02/06/2023 18:17, Mohammed Siddiqi wrote:
> I am currently working on making sure NTP works according to the RFC 5905 and we use NTP.org implementation of ntpd. I have been going through the RFC and NTP.org’s documentation
If you want a definitive implementation of the RFC, you need the ntp.org
version that was current at the time of its publication, and represents
the reference implementation. The current source code will include
improvements.
I suspect Dave Mills considered the RFC to be more like a research
paper, describing things as they were at the point at which it was
written, rather than as a standard, frozen for all time.

On 6/2/2023 5:03 PM, David Woolley wrote:
> On 02/06/2023 18:17, Mohammed Siddiqi wrote:
>> I am currently working on making sure NTP works according to the RFC
>> 5905 and we use NTP.org implementation of ntpd. I have been going
>> through the RFC and NTP.org’s documentation
>
> If you want a definitive implementation of the RFC, you need the ntp.org
> version that was current at the time of its publication, and represents
> the reference implementation.  The current source code will include
> improvements.
>
> I suspect Dave Mills considered the RFC to be more like a research
> paper, describing things as they were at the point at which it was
> written, rather than as a standard, frozen for all time.

That is pretty much all true, David.

To be slightly picky about it, please see:

https://support.ntp.org/Dev/ReleaseTimeline

The first alpha code release of ntp4 was in September of 1997, and the
first production release was in August of 2001.

There were 3 major ntp4 code releases before
draft-ietf-ntp-ntpv4-proto-00 in July of 2005, and 3 more major code
releases before RFC 5905 and 5906 were published, in June of 2010.

The process of reconciling the code and the Standard took 5 years, and
as I recall that when there was a discrepancy between the code and the
proposed Standard, about 90% of the time the Standard was changed.

We've had one major release of the code since then, and are in
preparation for another.

Dave Mills has ALWAYS been more interested in performance and behavior
than in following the Standard. This makes perfect sense to many of us,
as we're more interested in good timekeeping and behavior than we are in
"following a specification".

I don't know if anybody has ever audited the code and RFCs 5805 and 5806
to "find the closest match."

I know there have been some diversions between the Standard and the
code. From "our" POV, the code does a better job of timekeeping than
the Standard.

Oh, and Dave also considers the 2nd edition of his book, "Computer
Network Time Synchronization", to be a better specification than the RFCs.

An example of the above would be
https://bugs.ntp.org/show_bug.cgi?id=2085, which took nearly 2 years'
time to resolve. In particular, the comments contain a lot of
information about the intricasies and subtlety involved.
--
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!
--
This is questions@lists.ntp.org
Subscribe: questions+subscribe@lists.ntp.org
Unsubscribe: questions+unsubscribe@lists.ntp.org

On Saturday, June 3, 2023 at 6:48:02 AM UTC-4, Harlan Stenn wrote:
> On 6/2/2023 5:03 PM, David Woolley wrote:
> > On 02/06/2023 18:17, Mohammed Siddiqi wrote:
> >> I am currently working on making sure NTP works according to the RFC
> >> 5905 and we use NTP.org implementation of ntpd. I have been going
> >> through the RFC and NTP.org’s documentation
> >
> > If you want a definitive implementation of the RFC, you need the ntp.org
> > version that was current at the time of its publication, and represents
> > the reference implementation. The current source code will include
> > improvements.
> >
> > I suspect Dave Mills considered the RFC to be more like a research
> > paper, describing things as they were at the point at which it was
> > written, rather than as a standard, frozen for all time.
> That is pretty much all true, David.
>
> To be slightly picky about it, please see:
>
> https://support.ntp.org/Dev/ReleaseTimeline
>
> The first alpha code release of ntp4 was in September of 1997, and the
> first production release was in August of 2001.
>
> There were 3 major ntp4 code releases before
> draft-ietf-ntp-ntpv4-proto-00 in July of 2005, and 3 more major code
> releases before RFC 5905 and 5906 were published, in June of 2010.
>
> The process of reconciling the code and the Standard took 5 years, and
> as I recall that when there was a discrepancy between the code and the
> proposed Standard, about 90% of the time the Standard was changed.
>
> We've had one major release of the code since then, and are in
> preparation for another.
>
> Dave Mills has ALWAYS been more interested in performance and behavior
> than in following the Standard. This makes perfect sense to many of us,
> as we're more interested in good timekeeping and behavior than we are in
> "following a specification".
>
> I don't know if anybody has ever audited the code and RFCs 5805 and 5806
> to "find the closest match."
>
> I know there have been some diversions between the Standard and the
> code. From "our" POV, the code does a better job of timekeeping than
> the Standard.
>
> Oh, and Dave also considers the 2nd edition of his book, "Computer
> Network Time Synchronization", to be a better specification than the RFCs..
>
> An example of the above would be
> https://bugs.ntp.org/show_bug.cgi?id=2085, which took nearly 2 years'
> time to resolve. In particular, the comments contain a lot of
> information about the intricasies and subtlety involved.
> --
> Harlan Stenn <st...@nwtime.org>
> http://networktimefoundation.org - be a member!
> --
> This is ques...@lists.ntp.org
> Subscribe: questions...@lists.ntp.org
> Unsubscribe: questions+...@lists.ntp.org

Thanks a lot for your replies!