[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
Commits:
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
Changes:
=====================================
devel/tour.txt
=====================================
--- 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
+dropped.
+
+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
=====================================
include/recvbuff.h
=====================================
--- 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.
*/
=====================================
ntpd/ntp_io.c
=====================================
--- a/ntpd/ntp_io.c
+++ b/ntpd/ntp_io.c
@@ -130,7 +130,9 @@ nic_rule *nic_rule_list;
#endif
/*
- * 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
input_handler(
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