[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:
@@ -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
@@ -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.
@@ -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
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/d00da5661208e1f647e4bbf2524f0cfb96c56c09
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vc