[Git][NTPsec/ntpsec][master] Explain some assumptions.

Eric S. Raymond gitlab at mg.gitlab.com
Sun Sep 25 10:01:48 UTC 2016

Eric S. Raymond pushed to branch master at NTPsec / ntpsec

d00da566 by Eric S. Raymond at 2016-09-25T06:01:33-04:00
Explain some assumptions.

- - - - -

3 changed files:

- devel/tour.txt
- include/recvbuff.h
- ntpd/ntp_io.c


--- a/devel/tour.txt
+++ b/devel/tour.txt
@@ -140,6 +140,28 @@ and pool hostnames.  This is intended to avoid adding startup delay
 and jitter to the time synchronization logic due to address lookups
 of unpredictable length.
+Input handling used to be a lot more complex.  Due to inability to get
+arrival timestamps from the host's UDP layer, the code used to do
+asynchronous I/O with packet I/O indicated by signal, with packets
+(and their arrival timestamps) being stashed in a ring of buffers that
+was consumed by the protocol main loop.
+This looked partly like a performance hack, but if so it was an
+ineffective one. Because there is necessarily a synchronous bottleneck
+at protocol handling, packets arriving faster than the main loop could
+cycle would pile up in the ring buffer and latecomers would be
+The new organization stops pretending; it simply spins on a select
+across all interfaces.  If inbound traffic is more than the daemon
+can handle, packets will pile up in the UDP layer and be dropped at
+that level. The main difference is that dropped packets are no
+longer visible in the statistics the server can gather.
+There was internal evidence in the NTP Classic build machinery that
+asynchronous I/O on Unix machines probably hadn't actually worked for
+quite a while before NTPsec removed it.
 === Refclock management ===
 There is an illuminating comment in ntpd/ntp_refclock.c that begins

--- a/include/recvbuff.h
+++ b/include/recvbuff.h
@@ -14,9 +14,9 @@
 #define RECV_TOOMANY	40	/* this is way too many buffers */
- * Format of a recvbuf.  Back when this code did true asynchronous
+ * Format of a recvbuf.  Back when ntpd did true asynchronous
  * I/O, these were used by the asynchronous receive routine to store
- * incoming packets and related information. Now, with faster processor
+ * incoming packets and related information. Now, with faster processors
  * and lower latency in the synchronous I/O loop, that complexity
  * has been dropped.

--- a/ntpd/ntp_io.c
+++ b/ntpd/ntp_io.c
@@ -130,7 +130,9 @@ nic_rule *nic_rule_list;
- * We do asynchronous input using the SIGIO facility.  A number of
+ * This code is a remnant from when ntpd did asynchronous input using
+ * the SIGIO facility.  Most of that complexity is gone now.
+ *
  * recvbuf buffers are preallocated for input.	In the signal
  * handler we poll to see which sockets are ready and read the
  * packets from them into the recvbuf's along with a time stamp and
@@ -3458,7 +3460,7 @@ io_handler(void)
- * input_handler - receive packets asynchronously
+ * input_handler - receive packets
 static void

View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/d00da5661208e1f647e4bbf2524f0cfb96c56c09
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/vc/attachments/20160925/967c4538/attachment.html>

More information about the vc mailing list