NTP intro

selected/time.md

@@ -144,9 +144,26 @@ With all these concepts established, the question now is how to actually represe
 
 
 # What time is it actually: time synchronization
-    - NTP/chrony
-    - forkingpaths help you are the one who is the smart
-TODO: short intro
+
+Getting the time seems easy right? Someone has it, and you ask them, you set your wristwatch, done. Well, our boy Carlin nails it:
+
+> Pardon me, do you have the time? When do you mean, now or when you asked me? This shit is moving, Ruth.
+> <p style="text-align: right"><cite>&mdash; George Carlin, Again! (1978)</cite></p>
+
+So let's say you want to ask the time to your friend who is fortunate enough to own a radio clock. Now imagine voice takes a long, undeterminate (and variable) amount of time to travel between you and them (alternatively, imagine you want to know what time is it with an extreme precision). When your interlocutor hears your question, it is already too late. They can give you the time it was when the heard the question, but they have no idea when you asked. Now, when you receive their answer you have the same problem. You neither know when they heard your question, nor when they answered. You only know that the time you get corresponds to some point between the moment you asked and the moment you heard the answer.
+
+Now let's say you pick a random point in this interval, and adjust your own watch to that time. Maybe you make an error, but at least your synchronized _within some tolerance_ right? No luck! Since it is extremely unlikely both of your watches have exactly the same consistent speed, your watch will drift and wander away from your friend's clock. You could ask again and again. But each time you will get a different error, so your watch will be very noisy (and still drift in between exchanges).
+
+Fortunately for us humans, we don't typically require a high precision compared to the time it takes for sound to travel between two persons speaking to each other. For computers though, it can be crucial to be synchronized within a few microseconds, and network communications can take full seconds. Their clock are also drifting and jittery, sometimes at an astonishingly high rate. Clearly there has to be ways to mitigate the errors generated by such adverse conditions.
+
+## The Network Time Protocol
+
+The ubiquitous solution to time synchronization on computer networks is the Network Time Protocol. It allows to synchronize clocks to a common reference (usually Coordinated Universal Time) with an accuracy of a few milliseconds over the Internet, and can typically provide sub-millisecond accuracy on Local Area Networks.
+NTP was pioneered by Pr. David Mills, [whose webpage](https://www.eecis.udel.edu/~mills/) is a treasure trove of informations about time synchronization. The protocol was described in various RFCs, from its first version [(RFC1059)](https://datatracker.ietf.org/doc/html/rfc1059) to the current fourth [RFC5905](https://datatracker.ietf.org/doc/html/rfc5905).
+
+Other clock synchronization protocols exist, e.g. PTP (IEEE 1588-2019), and some implementations of NTP such as [Chrony](https://chrony.tuxfamily.org) include different error mitigation techniques than those described by the specification.
+
+I will focus here on NTP since it's the most documented and widely used, and it doesn't require specialized hardware like PTP.
 
 ## The NTP Network
 To maintain a consistent notion of time accross the internet, you first need some reference time signal, which is typically provided by atomic clocks. Since it is neiter practical nor desirable to connect every computer in the world to these atomic clocks, the time signal is distributed accross a network of peers organized in serveral strata. Primary servers sit at stratum 1 and are directly connected (through wire or radio) to a reference clock. Peers at strata 2 can synchronize on servers at strata 1 or 2, and act as a synchronization sources for peers at strata 3. The layering continues up to stratum 15. Strata 16 represents unsynchronized devices.
@@ -182,7 +199,7 @@ Note that peers also transmit the delay and dispersion statistics accumulated at
 
 Simple NTP clients that are only synchronized to one server, that don't act as a source for other peers, and that don't need a high precision, can implement only the on-wire protocol and directly use $\theta$ to correct their local clock. However this estimate is vulnerable to network jitter, delay asymetry, clock drift and wander. To get better precision, the samples produced by the on-wire protocol must be processed by a number of mitigation algorithms.
 
-Links: [Mills, Analysis and Simulation of the NTP On-Wire Protocols](https://www.eecis.udel.edu/~mills/onwire.html), [RFC5905 - section 8](https://datatracker.ietf.org/doc/html/rfc5905#section-8)
+Links: [Mills, Analysis and Simulation of the NTP On-Wire Protocols](https://www.eecis.udel.edu/~mills/onwire.html), [RFC5905 - section 8](https://datatracker.ietf.org/doc/html/rfc5905#section-8), [SNTP (RFC4330)](https://datatracker.ietf.org/doc/html/rfc4330) 
 
 ### Clock Filter