hmn
/
education-2022
2
Fork 0
Code Issues 1 Pull Requests Projects Releases Wiki Activity

minor edits to NTP stuff

This commit is contained in:
Martin Fouilleul 2022-06-05 11:38:08 +02:00
parent 877d0e89b6
commit bd48150d27
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
selected/time.md
View File

@ -145,17 +145,17 @@ With all these concepts established, the question now is how to actually represe
# What time is it actually: time synchronization
Getting the time seems easy right? Someone has it, you ask them, you set your wristwatch, and you're done. Well, Georges Carlin really nails it here:
> — 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>
To elaborate, let's say you want to ask the time to your friend who is fortunate enough to own a radio clock. But also 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.
Getting the time seems easy right? Someone has it, you ask them, and you're done. Well, it's a little more complicated than that.
Let's say you want to set your watch, so you ask the time to a friend. But also imagine voice takes a long, undeterminate 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 friend 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 with your friend _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). Furthermore it seems like a big waste of your... time.
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.
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 hundreds of milliseconds. 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