From 877d0e89b6520f52a7c7e2476b87bc7a4c7b01ad Mon Sep 17 00:00:00 2001 From: Martin Fouilleul Date: Sat, 4 Jun 2022 18:54:36 +0200 Subject: [PATCH] minor edits to NTP stuff --- selected/time.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/selected/time.md b/selected/time.md index fe78477..7909d7d 100644 --- a/selected/time.md +++ b/selected/time.md @@ -145,14 +145,15 @@ 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, and you ask them, you set your wristwatch, done. Well, our boy Carlin nails it: +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. +> — Pardon me, do you have the time? +> — When do you mean, now or when you asked me? This shit is moving, Ruth. >

— George Carlin, Again! (1978)

-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. +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. -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). +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.