It's one of the things so robust it almost never breaks and you never need to deal with it. However, I think the protocol will fall apart when passed through RFC1149
The reason why you back off the polling interval is to allow the effect of the frequency error between the two NTP peers to accumulate enough phase error that can be detectable. There's also some cool algorithms at work here, where as you get closer to the synchronizing the correct local clock frequency, you '"tighten up" the phased-locked loop that's corrected by measured clock offsets (after going through a filter). The clock offset computation also needs to have half of the measured delay time accounted for (which was missing in the video.) Of course, this assumes that the network latency across the network path is symmetric... which isn't always the case. Along with the NTP peer stratum number, another metric, "dispersion" is measured between NTP peers which is roughly how noisy the measurement is. An NTP peer will include the "root dispersion" which is the sum of the dispersions of that peer to the root of that synchronization hierarchy and a measurement of the quality. NTP is great fun. Along with Mike Petry, he and I built the first UNIX NTP implementation of the protocol, doing so only from the draft protocol document and peeking at the PDP-11 assembly code that Dave's implementation was built in. Mike and I were students of Dave's at the University of Maryland and enjoyed many time synchronization experiences ourselves. I built the NTPv1 UNIX implementation on a NeXT workstation in my office. One of the things the NTP program does is compute the intrinsic frequency error of the clock in your computer. It saves this in a file, so that in the event you lose connectivity to your synchronization peer, you can continue to apply the frequency correction, so at least your clock advances at a more correct rate than it would otherwise. From this, I could indirectly measure the temperature of the room as the cheap crystal on the computer's board had a relatively poor temperature coefficient, and it became clear that that the air conditioning in the office got turned off over the weekends and the ambient temperature would rise. And then there were the exciting New Year's Eve experiences! Will the code that handles leap-second insertion work correctly? A leap second is most frequently inserted at 23:59:59 UTC on 31 December, so about 7pm local time. I would disappear into my home office and watch NTP to see if the right thing would happen.. And then struggle to explain to family and friends why this had to happen right now.. Nice video! How novel to see NTP make an appearance on UA-cam!
I studied under Dr Mills. People would occasionally look at a file system / database protocol and say "But what if the client isn't sync'ed to the server?" He'd say "We solved that problem. Let's move on."
Beyond NTP, for high precision time for science experiments and such (e.g. the LHC, or radio telescopes doing VLBI), there's White Rabbit developed at CERN. It can synchronize clocks to under a nanosecond over local distances (tens of km). I used to work in a place that had a dedicated optical fibre running 50 km from the national lab with atomic clocks to sync some radio telescope clocks.
How about those joint radio telescopes that have multiple station and global footprint? How do you sync them? Just reference to GPS clock? Sorry I don’t know the correct terms for this.
I work in high frequency FX, and NTP was a bit problematic, but so far, chrony suffices with no issue. We only need mics, so nowhere near as sensitive as astronomy use cases.
@@edmondhung6097 GPS reference for long term stability in LOFAR and rubidium clocks for short term. In WSRT / APERTIF its hydrogen maser (atomic clocks) for short term stability and still GPS. You have to have some global reference so almost always GPS but want that to be more stable so you combine them
Brilliant! One of the things I love about computer science is that a lot of the people who worked on all these methods and algorithms are still around. Getting information straight from the source is always amazing, especially when its produced and presented as well as you do!
A few years ago I moved from pure networking to networking/system administration in a very small company. Server care and maintenance hadn't happened for a while when I arrived and everything was a bit tottery and unstable. I wasn't quite sure what the best approach was but got NTP working across all servers, whether they talked to the outside world or not. This was the crucial first step to stabilising servers and their (inter-server) services. Thanks NTP, you are a winner!
I worked for ISPs, so I had to make sure that servers were synced, as we had to track down issues at times, be it an attack, or just odd network packets, or the occasional P2P notice of copyrighted material being shared. The time stamps on all the devices needed to match.
Back in the early 90s, I'd just started getting into Linux. I was running an Yggdrasil distribution on a 80486 (kernel versión 0.99PL14R). And I started hanging out with a local user's group - Unix Users of Minnesota. NTP clients had just started showing up for Linux, and all us geeks were busy getting things configured. So I'm waiting for the meeting to start, chatting with folks, and the moderator gets up behind the podium to kick things off. And then it turned 7:00 o'clock, and everybody's watch beeped. This was, of course, back in the day when people still thought digital watches were a pretty neat idea. There must have been thirty of us, perhaps twenty had watches with hour-beeps turned on, and we all of us beeped at exactly the same time. We'd all synced to our computers, and our computers were all synced to Internet time.
@@BattousaiHBr "Far out in the uncharted backwaters of the unfashionable end of the western spiral arm of the Galaxy lies a small unregarded yellow sun. Orbiting this at a distance of roughly ninety-two million miles is an utterly insignificant little blue green planet whose ape-descended life forms are so amazingly primitive that they still think digital watches are a pretty neat idea." - Douglas Adams, "The Hitchhikers' Guide to the Universe"
It's really great that at 0:32 and 6:55 you can see a drawing of an 8 bit BBC Micro computer from the 80's. I have build a WiFi board for this computer and a friend of mine, Timo, wrote a program that fetches the time from a NTP server 🙂 Thanks for this explanation Mr Onions.
I remember people arguing about whose watch had the correct time. The only way to truly settle the argument was to fire up the shortwave radio and tune it to WWV in Fort Collins. Thanks to NTP and smartphones those tedious arguments are a thing of the past
In Britain we had a special phone number you could call in the 80s & 90s. The phone number was 123 and it was called, I think, the speaking clock. It was before speech synthesis so used lots of recording of a bloke with a posh English accent. I can still remember the voice “At the third stroke, the time, sponsored by Accurist, will be… eight twenty four pm beep beep beep”
I've only found out a while ago that at least on Android NTP isn't used at all but only cellular network. You can download apps that provide you with NTP and check how far off you are ;)
@@tetbundy5683 I think most phones use “network time”. i.e. they get their time from the mobile phone network. You notice it when you travel abroad and it connects to a new mobile network and your time gets updated. Happens on iPhones anyway and I suspect it makes sense from a technical point of view
The underlying architecture for the global NTP Pool is a really interesting as well. It was one of the first instances of GeoDNS to silently get clients connected to the closest regional servers
NTP came out in 1985. Prime computers didn't have crystal clocks. It was quite a chore to synchronize the clocks. The clock could only be set at the console. When time was set, it started at the indicated minute; there were no seconds. I wrote a program to query the other computers on the ringnet and set the clock. Some computers had more accurate clocks than others. The program had a list of computers from best to worst. If the best computer was unavailable, it would drop to the next. There was also code to do a sanity check if times were too divergent from each other. The time synchronization was added to the backup script because it was run daily from the console.
A student in my uni class did his dissertation that included a case of using NTP in a method of DDOS attack around 2014 (the "derp trolling" group, if that rings a bell for anyone). At the time it broke records on both total bandwidth used up in an attack and the return they got for every bit they sent (I think it was in the 400 bits per bit sent amounts?)
I've been involved with the NTP Hackers team for 25+ years, wonderful to see such a nice explanation of what/why/how it works! A few small details: In ntp infinity equals 128 ms! I.e. if a local clock has a time offset larger than this limit, it will reset (typically by jumping the clock) and start the protocol engine from scratch. I.e. the combination of multiple seconds of offset and skewing to correct this doesn't actually occur, unless you have configured ntpd with non-default settings. The protocol will always assume the round trip delays to be symmetrical, but with the huff-puff algorithm, it can also handle temporary one-way overloading, i.e. when the round trip increases so much that the measured clock offset can be explained by such a one-way delay.
NTP is so awesome. I love that Canada has an official NTP time server. It's run by the NRC and is extremely accurate! Been syncing all my computers with NTP for many many years.
The UK National Physical Laboratory (NPL), who operate the national radio time signal, also provide an NTP service. As does the London Internet Exchange (LINX).
In years past I really enjoyed looking at the delay-offset scatter plots from ntp's peerstats data. It reveals interesting network details like the asymmetry in DSL links, or big changes in global routing. A "network weather monitor" of sorts. Search for the great write up on a focus on NTP in Slovenia to see some of these scatter plots.
And when you dig into the ntp configuration files, you can set up 2nd order correction files for your computer and get the drift down to +/- 1 ms. Diurnal drift is mostly removed (effects of daily solar heating). Plotting the drift files shows that the correction coefficients are established in a few days. Now that is something you can set your Swiss watch to. (+6 to - 4 seconds drift per day).
This will be useful for a weather station I am building - it has multiple agents, and these need to be synchronised in time; I am still researching ways to do this - this is a good starting point; thanks for this video. I had not thought of this; I am not a computer scientist but more of a mathematical interest. Thanks again!
I use a USB GPS connected and when running chrony it's VERY accurate and becomes its own Stratum1 time source. This gives me a 'known' standard that I can reliably sync other data to.
@@patrickssj6 it drifts out of sync. that's the point of NTP. for example, on linux you may want to run this once a month to sync the RTC with the network time you currently have. hwclock --systohc --utc
Iirc, in some datacenters where synchronized clocks are critical, they'll have servers with their own little atomic clocks as PCIe cards to maintain high precision and reduce drift.
Wonderful, thank you! I used to assume that my computer sent a "what time is it?" question and the server replied. I wondered how they accounted for the transit time (although I was never so curious that I looked it up!). Now that I've seen this video the solution seems obvious.
Before NTP there was a timeserver protocol that works much as you describe. A client opened a connection to port 37 on the server and the server sent the time as a 4 byte value. Some machines still implement this as part of inetd, although I don't think there are many clients left.
The NTP client on Windows NT6 has mind of its own. If I need to synchronize a computer without a CMOS battery, it's hard to get it to coax into running on startup, keep working, and not reject the time. And when I need it again, I have forgotten what I needed to do.
The max offset can be adjusted. But there's more to it. The first time request may be discarded because the data was "stale", or the service shuts down without a clear reason. It works on winxp. I distribute time from my network router, and want it to use that.
Too bad, I think the important part of the synchronization algorithm was left out. How should the client update its clock to be the same as the server's? Aiming for t1 - t0 = 0 is clearly not the answer since propagation delay is never exactly 0. What actually happens in NTP is that it aims to get the "midtimes" equal. i.e. make the difference (t2 + t1)/2 - (t3 + t0)/2 equal to 0. Under the assumption that propagation delays are equal in each direction, this quantity will be 0 for a well-synchronized server-client pair.
What if the propagation delays are different in each direction? Is there any way to account for that? This seems like it could be a real problem especially if you're synchronizing with two different servers with different propagation delays, and could gain/lose 50ms every time you switch servers or something.
At 4:31 Dr Onions says that "the difference in clocks is t1-t0". But isn't that ignoring the time it takes for the round trip? If we assume the trip time is the same both ways then I'd think the difference in clocks would be t_1-t_0 - ((t_3-t_0) - (t_2-t_1))/2 . Or to simplify (t_1 + t_2 - t_0 - t_3) / 2 .
NTP! One of my fav's and most used...and also one of the things even super nerds don't generally know about. I have microcontrollers running everywhere that need their time synced to my server, and it's amazing how simple a thing can be so useful....and so often forgotten...
I'm sure people will disagree but this is one of the most important protocols in network engineering. Certificates, RADIUS, logs, IPSEC etc.. On and on, you lose alot of important things should this fail in a network and things get out of synch.
@@BattousaiHBr Yes in IPSEC a security association is formed. It expires based on packets, data or time expired. In order for the SA to form and be correct, timestamps must be the same or the rekeying will fail. The new key has to be generated before the old one fails, if a new one can't be formed and the old one expires then the VPN will drop. Edit* yes you can zero out the lifetime but most companies don't. Also you can read RFC 3585 to read more about IPSEC. I'm by know means an expert, I've just been on the outage when NTP breaks and it kills many things. If for example a power cut happens and dates go back to default and the NTP is down, all hell will break lose because many things will be time expired. Hopefully that makes sense.
Way back I worked at a antarctic station and setup a server (debian linux) as a level 1 NTP server using data from a gps receiver. I would not be surprised if it is still running 20 years later.
In my experience comparing NTP time to a much more precise GPS time source NTP has usually been good only to within 6-10 ms. That's pretty good for most things, but I'm working with scientific equipment that we need to synchronize to within a few nanoseconds ideally, hence the GPS.
I routinely get sub millisecond sync with normal ntp. It all depends on what you’re syncing to and how stable the latency is in your network. I can get within nanoseconds syncing to GPS 1PPS.
The professor is obviously a very good teacher just a little camera shy so he speeds up in some segments, I did the same thing during many presentations. The calculation was very simple: adjustment = server time - client time + round trip time. For example 10:10:30 - 10:10:20 + 0:0:2 = my clock is 12 seconds slow.
@@Jono4174 Yes but the value actually used is a statistical mean of the various values it has got, with outliers filtered, so in practice this doesn't matter.
saw a guy uneasily sitting over the table in the thumbnail...... that told me instantly that this dude is obscenely intelligent and will be able to explain why exactly this gobbeldygoop is necessary for everyday life
Since there is latency in the packets getting to the server, why would you want t1 and t0 to be equal? Wouldn't you want t2-t1 to equal t1-t0? Wouldn't that mean that (assuming the packets have the same latency each way), the clocks are in sync? Otherwise if you targeted t1=t0, then your clock would be ahead since you are assuming the latency is 0?
No, that's not what's happening. The *only* things you are assuming are (1) that all clocks involved advance at the same *rate* even though there may be offsets between them; and (2) that the time (t3-t2) taken for the response to come back is equal to the time taken (t1-t0) for the request to get there. (This also interferes with attempts to measure the speed of light; either you have to make a return journey which you can time with one clock, and then you only know the average speed of light in both directions there and back, or you have to use two separate clocks, and then yeah, let's just not go there.) (t3-t0)-(t2-t1) is the total packet transit time, irrespective of any offset between the client and server end clocks (since both t3 and t0 were recorded at the same end, and so were t2 and t1); so t0 + ((t3-t0)-(t2-t1))/2 is what your clock would have been showing when the other end recorded t1, and from that you can work out how much you need to move your clock forwards or backwards so it shows the same time as the other clock.
This is actually more basic than I thought. It only works because they assume that each round-trip contains two legs of similar duration, and this is usually true, but not always. With only two nodes, it's impossible to determine if the return trip takes more or less time than the outgoing trip. If one leg takes much longer than the other, you can't actually figure out when the other computer recorded its time. You need to coordinate connections between more nodes to figure out how long each leg takes, which is the only way to really get a guarantee about the time.
What a coincidence! I was just starting to take a closer interest in NTP last week and hey presto, your presentation has appeared at the same time! Thank you.
At uni we had a 4pm network problem. It was destroying our student radio station. And as manager I was spending half my time getting the uni to deal with it. At 4pm the entire network ground to a halt for an hour. It was eventually found it was caused by the entire network doing a full backup of everything. This was 2009 and the techs were still getting used to the rapid use of everyone being constantly online.
I used to design and procure national networks, both fixed and mobile. One of the most fun parts was figuring out the clock source - have your own Césium atomic clock, or Rubidium disciplined by GPS… How many to have, hierarchies of clocks…. I think I did 14 networks in all!
I worked in a meteorological office which ran an S0 clock, and honestly, I never expected how much fiddling with synchronization I'd have to do! Everything always ran flawlessly, until suddenly, you'd find that some weather station was somehow now the S1 or 2 source for an entire network, and you'd only notice after some random windows authentication stopped working properly!
Electronic devices in electrical power grids are synched in time, often using a GPS clock to be able to exactly determine where a fault occurs in the power grid. Since AC electricity changes direction every 20 ms it's necessary to have all devices synched up to ms precision
@@isyt1 Because as you cower behind a fake "m ame", it is plain to me that you have never met a real adult. That is why it clearly shocked you. For others, assuming that I can speak on their behalf only confirms the case.
Like most normal people i look at random conversations on networks via wireshark ( what its normal! ) but i have never looked at NTP, i will have to now.
In Windows, you can still specify/override what time servers to use, if you find that NTP isn’t reliable enough using the defaults. Just as in Linux, you have system commands to force time recalibration and other fun things.
1. There are systems that monitor the power demand by looking at the change in frequency 2. The same thing happened with Railways in the 19th Century, where synchronising clocks between different cities was introduced 3. Hence time zones. 4. Einstein and relativity was all based around think about how time works, when you have to send signals between different observers.
During the BBC Teletext broadcast trials the on screen clock was always out by several hours because the Unix system clock was not synchronized to anything.
A few years ago there was one unloved server where I worked whose time was out by about 6 seconds. It caused all manner of weird problems with my builds until I figured it out. The admins fixed it when I reported it but never explained how it came to be so far out in the first place.
Early adopter of NTP before it was quietly cool. Recently did some "certification" of NTP on a RTL system. Was more challenging that I thought to do right (and did find a minor bug in the RTL NTP system (or rather a deeper RTL issue that manifested through those tests)). IAC, armed with a pretty cheap GPS and its 1 PPS signal one can check the NTP algo to about 1000x the accuracy of NTP. [hate to say it, but if you need better accuracy, get a GPS and use the 1 PPS to know the top-of-second quite accurately (less than 1 µs)].
Having spent months(!) debugging a pesky clock sync problem on a small IOT product, I've developed a distain for NTP. It's great when it works, but when problems emerge on remote customer devices in the field, default NTP provides very few clues. There's a reason why people are developing alternatives like chrony.
There are some problems that chronyd addresses, but many problems are common and have more to do with admins of client computers not understanding what they're doing, or basic things like not having their timezone configured correctly and then blaming the NTP server for not giving them the correct time. I welcome having multiple compatible implementations of the protocol, but there are things that ntpd can do that chronyd can't. So, it's not a one-for-one trade.
@@shubinternet In my case the "local admin" can be a small medical or veterinary clinic that cannot afford to hire a trained sysadmin. My complaint with NTP (and many other subsystems) is is the lack of clear feedback when things go wrong. I don't know if crony is better, but I can vouch that there is an increasing demand for better.
Ntpq gives you lots of info about the state of ntp. I agree it could be a bit more verbose, but you only need to understand a few commands to troubleshoot ntp problems.
In America our computers also have to contend with the 2 time changes a year as well. In the spring, they jump forward 1 hour at 2:00am and then back again 1 hour in the fall again at 2:00am.
I don't know enough about NTP to know whether it cares about daylight savings time or not, but I suspect it doesn't. Internally, Unix just has a counter that ticks forward by one every second and holds the number of seconds that has elapsed since 00:00 GMT on January 1st 1970. Timestamps on files etc. are just the value of this counter. Only programs which need to produce a human-readable time need to care about timezones, DST and all the other complicated stuff. To do this there's a database which lists when DST finishes and ends etc. for each timezone that can be used to do the conversion from internal timestamp to human-readable and library routines which know how to use the information in the database.
It would make sense for industry or corporate applications to have mass produced NTP clocks installed throughout a building, especially where daylight savings is used. A clock should be able to run on PoE, so it becomes a one plug solution that lets all clocks be adjusted remotely. I would think governments and government institutions like schools would provide a decent customer base, enough to make the product viable at least.
That's another question answered, I use Net Time manually every so often, I was thinking about how they compensated for such time/distance variances, it syncs "perfect" with the "RF regulated" clock I have.
really cool video, I actually implemented NTP as part of my home network, since we're in a house share with lots of computers and a file server (NAS) it's nice to have everything syncronised, so i turned it on as a DHCP option and have the NAS serve as the network time server for local clients and it gets it's time from one of the internet NTP pools.
I deal with server software that gets especially grumpy if time rewinds. ‘work queue is empty. I need to nap for 2 milliseconds before checking again. wake me at 08:32:15.224’ If you the rewind the clock 5 minutes, then 5 minutes of wall time pass before that alarm gets raised, and work is processed. That may sound minor, but when that work is processing a counter payment… Rolling clocks back to fix the time? Bad idea. Adjusting the clock speed? Wonderful. With VMs becoming more common, I’m seeing more and more multiple time-source issues (once from the hyper visor, once from the OS on the VM). One of these days, we’ll figure out time. Not there yet.
It's crazy that someone watching NTP traffic could see things happening in the real world, like kettles being started and earthquakes. It makes sense though. anything that impacts the electricity that computers are using could cause fluctuations.
I wonder what badge was he wearing that caused it to be blurred out :) initially I thought that computerphile did it but then I googled the name and lo and behold, the picture is literally blurred on the university website :)
Could you do a video on clocks changing or timezone and how that affects things. Esp as it’s now automated and no one notices like they used to changing clock an hour by hand.
3:30 "T1 minus T0 is how long it took to get across [from the client to the server]" 4:30 "The difference in clocks is T1 minus T0 (…) and if that equals zero, then they're synchronized (...) You want to get closer and closer to that" These two statements seem contradictory, though I suspect we're just missing some piece of the explanation. Why would we want to synchronize it in a way that makes it seems as though the time it takes for our ntp packet to reach the server is zero, when we don't actually believe that to be the case?
Was this created after mtc midi time code that is used to sync music on beat via midi across multiple recording equipment? Same issue very similar solution.
im not sure if this has any relevance to anything but if you have ever disconnected from internet and manually changed the computer date settings to as far back as it will let you (mine was 1980) and create a restore point if the date is set at 1980 it is visible on system restore but once you connect to the internet and resync it is no longer visible on the system restore point list. im not sure if this can be used for security considering it to use the internet the time must be in sync. from memory i backdated and created a restore point i then opened that restore point and dragged and dropped other files into it, and as we know data recovery software is quite good at restoring hdd data , i dont know just one of thing that might be overlooked by a hacker or someone might gain physical access if your trying to hide bitcoin wallets etc
What happens if there is a systematic bias in the direction of traffic? e.g. what if there is a computer behind a router where everyone watches Netflix and the incoming route has a 100ms queue on average, or if there's a firewall that inspects all outgoing packets, or something? If you're just using the round trip time and dividing by 2 you'll be systematically off in one direction.
@@CMD_Line Last company I worked for we had a small back-haul radio sending the time to its connected devices via PTP could support at least 5 slaves from a unit with HW costs of a couple of hundred $ to the customer.
@@IMBlakeley interesting, perhaps I've got the technology used in what I watched incorrectly. It was a raspberry pi being setup as a HW clock and the board being used was rather pricey.
@@CMD_Line For sure proper Grandmaster clocks are very expensive albeit they will support hundreds of slaves. I did some work for a major European telco and they hired in their access from a 3rd party that specialised. The device we provided was only tested with as I recall 6 slaves albeit the developers were sure that if it wasn't doing other stuff (i.e. providing back-haul for small cells) as well they could support more. There was a discussion about making a stand-alone unit, however, I checked their website and no mention that they went down this route.
There are many companies that can provide GNSS synchronized Stratum-1 references, and they can potentially include rubidium or cesium clocks for highly accurate PPS values. They can easily cost $20k or more, depending on how many clients you want to serve, etc....
wow this is way simpler than i was imagining. how do we account for huge outbound latency and tiny inbound latency? or is that rare enough that we just ignore it?
Wait, why do I want t0 to be as close as possible to t1 - doesn't that ignore the packet travel time? I'd expect that I want to get the difference to be as close as possible to half the roundtrip time (assuming that the packet travel time is roughly the same in both directions - this can be improved once I synchronize to multiple servers).
A Computerphile video on NTP? It's about time.
I second this comment.
Or hour it.
Its the minute detail.
I'll get my coat.
r/angryupvote
*Chomping on cigar*
It's about time.
yes it was
Hour you sure? Well, on second thought...
More protocols with people who were there to see them written please! I love the anecdotes
As a network engineer I use NTP every day, but never actually knew how it worked. - Thanks for the explanation
same! UDP port 123
@@BattousaiHBr It's also the number for the speaking clock in the UK. I wonder if that is just a coincidence?
It's one of the things so robust it almost never breaks and you never need to deal with it.
However, I think the protocol will fall apart when passed through RFC1149
i'd bet you still don't know
The reason why you back off the polling interval is to allow the effect of the frequency error between the two NTP peers to accumulate enough phase error that can be detectable. There's also some cool algorithms at work here, where as you get closer to the synchronizing the correct local clock frequency, you '"tighten up" the phased-locked loop that's corrected by measured clock offsets (after going through a filter). The clock offset computation also needs to have half of the measured delay time accounted for (which was missing in the video.) Of course, this assumes that the network latency across the network path is symmetric... which isn't always the case. Along with the NTP peer stratum number, another metric, "dispersion" is measured between NTP peers which is roughly how noisy the measurement is. An NTP peer will include the "root dispersion" which is the sum of the dispersions of that peer to the root of that synchronization hierarchy and a measurement of the quality.
NTP is great fun. Along with Mike Petry, he and I built the first UNIX NTP implementation of the protocol, doing so only from the draft protocol document and peeking at the PDP-11 assembly code that Dave's implementation was built in. Mike and I were students of Dave's at the University of Maryland and enjoyed many time synchronization experiences ourselves.
I built the NTPv1 UNIX implementation on a NeXT workstation in my office. One of the things the NTP program does is compute the intrinsic frequency error of the clock in your computer. It saves this in a file, so that in the event you lose connectivity to your synchronization peer, you can continue to apply the frequency correction, so at least your clock advances at a more correct rate than it would otherwise. From this, I could indirectly measure the temperature of the room as the cheap crystal on the computer's board had a relatively poor temperature coefficient, and it became clear that that the air conditioning in the office got turned off over the weekends and the ambient temperature would rise.
And then there were the exciting New Year's Eve experiences! Will the code that handles leap-second insertion work correctly? A leap second is most frequently inserted at 23:59:59 UTC on 31 December, so about 7pm local time. I would disappear into my home office and watch NTP to see if the right thing would happen.. And then struggle to explain to family and friends why this had to happen right now..
Nice video! How novel to see NTP make an appearance on UA-cam!
Thank you for sharing your expertise and spreading your passion 💪
I studied under Dr Mills. People would occasionally look at a file system / database protocol and say "But what if the client isn't sync'ed to the server?" He'd say "We solved that problem. Let's move on."
Bought his book. We implemented NTP client on a PLC.
Admin: Time Synchronisation is a problem!
Chadmin: *Develops protocol to solve problem*
Beyond NTP, for high precision time for science experiments and such (e.g. the LHC, or radio telescopes doing VLBI), there's White Rabbit developed at CERN. It can synchronize clocks to under a nanosecond over local distances (tens of km). I used to work in a place that had a dedicated optical fibre running 50 km from the national lab with atomic clocks to sync some radio telescope clocks.
We have started using White rabbit at ASTRON for our LOFAR radio telescope and the preliminary results are really good.
How about those joint radio telescopes that have multiple station and global footprint? How do you sync them? Just reference to GPS clock? Sorry I don’t know the correct terms for this.
I work in high frequency FX, and NTP was a bit problematic, but so far, chrony suffices with no issue. We only need mics, so nowhere near as sensitive as astronomy use cases.
Why not PTP?
@@edmondhung6097 GPS reference for long term stability in LOFAR and rubidium clocks for short term. In WSRT / APERTIF its hydrogen maser (atomic clocks) for short term stability and still GPS. You have to have some global reference so almost always GPS but want that to be more stable so you combine them
Brilliant! One of the things I love about computer science is that a lot of the people who worked on all these methods and algorithms are still around.
Getting information straight from the source is always amazing, especially when its produced and presented as well as you do!
I agree - about time this happened.
I'll get my coat.
Rest in peace David L. Mills. We stand on the shoulders of giants.
A few years ago I moved from pure networking to networking/system administration in a very small company. Server care and maintenance hadn't happened for a while when I arrived and everything was a bit tottery and unstable.
I wasn't quite sure what the best approach was but got NTP working across all servers, whether they talked to the outside world or not. This was the crucial first step to stabilising servers and their (inter-server) services. Thanks NTP, you are a winner!
I worked for ISPs, so I had to make sure that servers were synced, as we had to track down issues at times, be it an attack, or just odd network packets, or the occasional P2P notice of copyrighted material being shared. The time stamps on all the devices needed to match.
Back in the early 90s, I'd just started getting into Linux. I was running an Yggdrasil distribution on a 80486 (kernel versión 0.99PL14R).
And I started hanging out with a local user's group - Unix Users of Minnesota.
NTP clients had just started showing up for Linux, and all us geeks were busy getting things configured.
So I'm waiting for the meeting to start, chatting with folks, and the moderator gets up behind the podium to kick things off.
And then it turned 7:00 o'clock, and everybody's watch beeped.
This was, of course, back in the day when people still thought digital watches were a pretty neat idea.
There must have been thirty of us, perhaps twenty had watches with hour-beeps turned on, and we all of us beeped at exactly the same time.
We'd all synced to our computers, and our computers were all synced to Internet time.
wdym "peple still thought digital watches were a neat idea"? they _are_ a neat idea!
@@BattousaiHBr "Far out in the uncharted backwaters of the unfashionable end of the western spiral arm of the Galaxy lies a small unregarded yellow sun. Orbiting this at a distance of roughly ninety-two million miles is an utterly insignificant little blue green planet whose ape-descended life forms are so amazingly primitive that they still think digital watches are a pretty neat idea." - Douglas Adams, "The Hitchhikers' Guide to the Universe"
@@jeffdege4786 Don't worry, I got the reference and had a sensible chuckle.
It's really great that at 0:32 and 6:55 you can see a drawing of an 8 bit BBC Micro computer from the 80's. I have build a WiFi board for this computer and a friend of mine, Timo, wrote a program that fetches the time from a NTP server 🙂 Thanks for this explanation Mr Onions.
I remember people arguing about whose watch had the correct time. The only way to truly settle the argument was to fire up the shortwave radio and tune it to WWV in Fort Collins. Thanks to NTP and smartphones those tedious arguments are a thing of the past
As someone born in the digital age this is fascinating to me
We would tune into that radio on New Year’s Eve during the countdown. We wanted to know *exactly* when the new year started.
In Britain we had a special phone number you could call in the 80s & 90s. The phone number was 123 and it was called, I think, the speaking clock. It was before speech synthesis so used lots of recording of a bloke with a posh English accent.
I can still remember the voice “At the third stroke, the time, sponsored by Accurist, will be… eight twenty four pm beep beep beep”
I've only found out a while ago that at least on Android NTP isn't used at all but only cellular network. You can download apps that provide you with NTP and check how far off you are ;)
@@tetbundy5683 I think most phones use “network time”. i.e. they get their time from the mobile phone network. You notice it when you travel abroad and it connects to a new mobile network and your time gets updated. Happens on iPhones anyway and I suspect it makes sense from a technical point of view
The underlying architecture for the global NTP Pool is a really interesting as well. It was one of the first instances of GeoDNS to silently get clients connected to the closest regional servers
TIL that GeoDNS is actually a thing!
There's just something wonderful about seeing multiple clocks perfectly synced. I love NTP
NTP came out in 1985. Prime computers didn't have crystal clocks. It was quite a chore to synchronize the clocks. The clock could only be set at the console. When time was set, it started at the indicated minute; there were no seconds. I wrote a program to query the other computers on the ringnet and set the clock. Some computers had more accurate clocks than others. The program had a list of computers from best to worst. If the best computer was unavailable, it would drop to the next. There was also code to do a sanity check if times were too divergent from each other. The time synchronization was added to the backup script because it was run daily from the console.
NTP had been in development and testing since 1980. Among internet-connected Unix machines adoption was incredibly swift.
@@rockets4kids The time period I'm talking about was from about 1979 to 1987. The only network we had besides the ringnet was telnet.
A student in my uni class did his dissertation that included a case of using NTP in a method of DDOS attack around 2014 (the "derp trolling" group, if that rings a bell for anyone). At the time it broke records on both total bandwidth used up in an attack and the return they got for every bit they sent (I think it was in the 400 bits per bit sent amounts?)
I've been involved with the NTP Hackers team for 25+ years, wonderful to see such a nice explanation of what/why/how it works!
A few small details: In ntp infinity equals 128 ms! I.e. if a local clock has a time offset larger than this limit, it will reset (typically by jumping the clock) and start the protocol engine from scratch. I.e. the combination of multiple seconds of offset and skewing to correct this doesn't actually occur, unless you have configured ntpd with non-default settings.
The protocol will always assume the round trip delays to be symmetrical, but with the huff-puff algorithm, it can also handle temporary one-way overloading, i.e. when the round trip increases so much that the measured clock offset can be explained by such a one-way delay.
If you're able to ask the guy who spent half his life watching clocks about an interview, it would definitely be worth a watch too
that is to say, it wouldn't be a waste of time
I second this. It's very timely information.
I clocked what you did there
I’d love to see a video expanding on this to PTP!
NTP is so awesome. I love that Canada has an official NTP time server. It's run by the NRC and is extremely accurate! Been syncing all my computers with NTP for many many years.
Regional NTP server as opposed to pool makes sense at a local IX (internet exchange)
The UK National Physical Laboratory (NPL), who operate the national radio time signal, also provide an NTP service. As does the London Internet Exchange (LINX).
As do many ISPs, universities, and the national university network (Janet). When you do some digging you find there are so many public NTP servers!
In years past I really enjoyed looking at the delay-offset scatter plots from ntp's peerstats data. It reveals interesting network details like the asymmetry in DSL links, or big changes in global routing. A "network weather monitor" of sorts. Search for the great write up on a focus on NTP in Slovenia to see some of these scatter plots.
And when you dig into the ntp configuration files, you can set up 2nd order correction files for your computer and get the drift down to +/- 1 ms. Diurnal drift is mostly removed (effects of daily solar heating).
Plotting the drift files shows that the correction coefficients are established in a few days.
Now that is something you can set your Swiss watch to. (+6 to - 4 seconds drift per day).
This will be useful for a weather station I am building - it has multiple agents, and these need to be synchronised in time; I am still researching ways to do this - this is a good starting point; thanks for this video. I had not thought of this; I am not a computer scientist but more of a mathematical interest. Thanks again!
Use a real time clock with a battery.
I use a USB GPS connected and when running chrony it's VERY accurate and becomes its own Stratum1 time source. This gives me a 'known' standard that I can reliably sync other data to.
@@patrickssj6 Depending on conditions, a RTC has a lot of drift due to environmental conditions if nothing else.
@@patrickssj6 it drifts out of sync. that's the point of NTP.
for example, on linux you may want to run this once a month to sync the RTC with the network time you currently have.
hwclock --systohc --utc
@@kevinshumaker3753 a GPS clock would be stratum 2, stratum 1 would be the computer inside the satellite where the stratum 0 clock resides.
This is awesome. Can we get one of these for Precision Time Protocol?
this might be the best science channel on this platform. It is in the top for sure.
Iirc, in some datacenters where synchronized clocks are critical, they'll have servers with their own little atomic clocks as PCIe cards to maintain high precision and reduce drift.
Look up Jeff Gerling and others who had a play around with them.
Wonderful, thank you! I used to assume that my computer sent a "what time is it?" question and the server replied. I wondered how they accounted for the transit time (although I was never so curious that I looked it up!). Now that I've seen this video the solution seems obvious.
Before NTP there was a timeserver protocol that works much as you describe. A client opened a connection to port 37 on the server and the server sent the time as a 4 byte value. Some machines still implement this as part of inetd, although I don't think there are many clients left.
One of the best UA-cam channels
This channel is a real treasure!🐧💝
The NTP client on Windows NT6 has mind of its own. If I need to synchronize a computer without a CMOS battery, it's hard to get it to coax into running on startup, keep working, and not reject the time. And when I need it again, I have forgotten what I needed to do.
Same on Windows 10 and many Linux. Too large time difference rejected as error / attack.
The max offset can be adjusted. But there's more to it. The first time request may be discarded because the data was "stale", or the service shuts down without a clear reason. It works on winxp. I distribute time from my network router, and want it to use that.
Too bad, I think the important part of the synchronization algorithm was left out. How should the client update its clock to be the same as the server's? Aiming for t1 - t0 = 0 is clearly not the answer since propagation delay is never exactly 0. What actually happens in NTP is that it aims to get the "midtimes" equal. i.e. make the difference (t2 + t1)/2 - (t3 + t0)/2 equal to 0. Under the assumption that propagation delays are equal in each direction, this quantity will be 0 for a well-synchronized server-client pair.
What if the propagation delays are different in each direction? Is there any way to account for that? This seems like it could be a real problem especially if you're synchronizing with two different servers with different propagation delays, and could gain/lose 50ms every time you switch servers or something.
At 4:31 Dr Onions says that "the difference in clocks is t1-t0". But isn't that ignoring the time it takes for the round trip? If we assume the trip time is the same both ways then I'd think the difference in clocks would be t_1-t_0 - ((t_3-t_0) - (t_2-t_1))/2 . Or to simplify (t_1 + t_2 - t_0 - t_3) / 2 .
LOL, just posted the same thing.
Should have read the comments further down.
NTP! One of my fav's and most used...and also one of the things even super nerds don't generally know about. I have microcontrollers running everywhere that need their time synced to my server, and it's amazing how simple a thing can be so useful....and so often forgotten...
I spent the start of this video trying to brush a hair off my phone screen. It turned out to be a drawing on the whiteboard!
I'm surprised no mention the NTP protocol dates all the way back to 1980!
What a coincidence. I was just Reading about NTP today and now Computerphile releases a video about it. 👍🏻
I'm sure people will disagree but this is one of the most important protocols in network engineering. Certificates, RADIUS, logs, IPSEC etc.. On and on, you lose alot of important things should this fail in a network and things get out of synch.
ipsec depends on time?
@@BattousaiHBr Yes in IPSEC a security association is formed. It expires based on packets, data or time expired. In order for the SA to form and be correct, timestamps must be the same or the rekeying will fail. The new key has to be generated before the old one fails, if a new one can't be formed and the old one expires then the VPN will drop. Edit* yes you can zero out the lifetime but most companies don't. Also you can read RFC 3585 to read more about IPSEC. I'm by know means an expert, I've just been on the outage when NTP breaks and it kills many things. If for example a power cut happens and dates go back to default and the NTP is down, all hell will break lose because many things will be time expired. Hopefully that makes sense.
Way back I worked at a antarctic station and setup a server (debian linux) as a level 1 NTP server using data from a gps receiver. I would not be surprised if it is still running 20 years later.
In my experience comparing NTP time to a much more precise GPS time source NTP has usually been good only to within 6-10 ms. That's pretty good for most things, but I'm working with scientific equipment that we need to synchronize to within a few nanoseconds ideally, hence the GPS.
PTP2 will get you real close to GPS accuracy
I routinely get sub millisecond sync with normal ntp. It all depends on what you’re syncing to and how stable the latency is in your network. I can get within nanoseconds syncing to GPS 1PPS.
This kind of skips over the actual calculation which is kind of confusing IMO.
Interestingly the calculation can do no better than assume the speed is the same both ways.
The professor is obviously a very good teacher just a little camera shy so he speeds up in some segments, I did the same thing during many presentations.
The calculation was very simple: adjustment = server time - client time + round trip time.
For example 10:10:30 - 10:10:20 + 0:0:2 = my clock is 12 seconds slow.
@@Jono4174 Yes but the value actually used is a statistical mean of the various values it has got, with outliers filtered, so in practice this doesn't matter.
@@forthrightgambitia1032 but I’m using a 1200/75 bits per second V.23 modem with different upload and download speeds
@@Jono4174 that’s ok, time is relative to the observer.
Definitely need to follow up and investigate the predictive/detection possibilities with NTP and the drift patterns.
saw a guy uneasily sitting over the table in the thumbnail...... that told me instantly that this dude is obscenely intelligent and will be able to explain why exactly this gobbeldygoop is necessary for everyday life
Since there is latency in the packets getting to the server, why would you want t1 and t0 to be equal? Wouldn't you want t2-t1 to equal t1-t0? Wouldn't that mean that (assuming the packets have the same latency each way), the clocks are in sync? Otherwise if you targeted t1=t0, then your clock would be ahead since you are assuming the latency is 0?
No, that's not what's happening. The *only* things you are assuming are (1) that all clocks involved advance at the same *rate* even though there may be offsets between them; and (2) that the time (t3-t2) taken for the response to come back is equal to the time taken (t1-t0) for the request to get there. (This also interferes with attempts to measure the speed of light; either you have to make a return journey which you can time with one clock, and then you only know the average speed of light in both directions there and back, or you have to use two separate clocks, and then yeah, let's just not go there.) (t3-t0)-(t2-t1) is the total packet transit time, irrespective of any offset between the client and server end clocks (since both t3 and t0 were recorded at the same end, and so were t2 and t1); so t0 + ((t3-t0)-(t2-t1))/2 is what your clock would have been showing when the other end recorded t1, and from that you can work out how much you need to move your clock forwards or backwards so it shows the same time as the other clock.
This is actually more basic than I thought. It only works because they assume that each round-trip contains two legs of similar duration, and this is usually true, but not always. With only two nodes, it's impossible to determine if the return trip takes more or less time than the outgoing trip. If one leg takes much longer than the other, you can't actually figure out when the other computer recorded its time. You need to coordinate connections between more nodes to figure out how long each leg takes, which is the only way to really get a guarantee about the time.
What a coincidence! I was just starting to take a closer interest in NTP last week and hey presto, your presentation has appeared at the same time! Thank you.
At uni we had a 4pm network problem. It was destroying our student radio station. And as manager I was spending half my time getting the uni to deal with it. At 4pm the entire network ground to a halt for an hour. It was eventually found it was caused by the entire network doing a full backup of everything. This was 2009 and the techs were still getting used to the rapid use of everyone being constantly online.
Please do a video on alpha tensor! Would love to learn more about it and the algorithms it discovered
I used to design and procure national networks, both fixed and mobile. One of the most fun parts was figuring out the clock source - have your own Césium atomic clock, or Rubidium disciplined by GPS… How many to have, hierarchies of clocks…. I think I did 14 networks in all!
Have been waiting for that topic!
2nd
@@I_Was_Named_This_Way... 3rd
I worked in a meteorological office which ran an S0 clock, and honestly, I never expected how much fiddling with synchronization I'd have to do! Everything always ran flawlessly, until suddenly, you'd find that some weather station was somehow now the S1 or 2 source for an entire network, and you'd only notice after some random windows authentication stopped working properly!
Electronic devices in electrical power grids are synched in time, often using a GPS clock to be able to exactly determine where a fault occurs in the power grid. Since AC electricity changes direction every 20 ms it's necessary to have all devices synched up to ms precision
The last job I had before giving up working for a living spent a fair bit of time working with PTP to synchronise small cells.
What a great passionate guy. Wish I had a lecturer like that in uni
And he is adult enough to use his real name!
What a shock that must be to you.
@@MichaelKingsfordGray Why would that shock me or, indeed, anyone?
@@isyt1 Because as you cower behind a fake "m
ame", it is plain to me that you have never met a real adult. That is why it clearly shocked you. For others, assuming that I can speak on their behalf only confirms the case.
@@MichaelKingsfordGray mate, your name isn’t Kingdford lol. Wtf you on about
As a sysadmin I allways enjoyed NTP, it just works and is so useful For so many applications.
Like most normal people i look at random conversations on networks via wireshark ( what its normal! ) but i have never looked at NTP, i will have to now.
Such a deceptively complex issue that's basically a necessity for modern communications. The whole power grid thing blows my mind a bit
Shouldn't (t1 - t0) (or (t2-t3)) be equal to half of the travel time? I'm confused about how they can be equal to 0 when the clocks are synchronized.
Synchronized means client and server have the same notion of time despite the travel time.
In Windows, you can still specify/override what time servers to use, if you find that NTP isn’t reliable enough using the defaults. Just as in Linux, you have system commands to force time recalibration and other fun things.
So, Dave Mills was a clock watcher! 🙂
How about a video on PTP (Precision Time Protocol)?
As a nerd for precision time keeping, I like this video.
(I have a Raspberry Pi 3B+ dedicated as a GNSS NTP Server with chronyd + gpsd)
Thanks for sharing Julian 👏🏻
I thought I knew about NTP. Clearly I didn’t ! But it was the stratums that I need to know about. Thanks!
You know this is going to be brilliant when he pulls out the old dot-matrix paper.
1. There are systems that monitor the power demand by looking at the change in frequency
2. The same thing happened with Railways in the 19th Century, where synchronising clocks between different cities was introduced
3. Hence time zones.
4. Einstein and relativity was all based around think about how time works, when you have to send signals between different observers.
During the BBC Teletext broadcast trials the on screen clock was always out by several hours because the Unix system clock was not synchronized to anything.
A few years ago there was one unloved server where I worked whose time was out by about 6 seconds. It caused all manner of weird problems with my builds until I figured it out. The admins fixed it when I reported it but never explained how it came to be so far out in the first place.
Nicely explained. Thanks for sharing 👍🏼
Early adopter of NTP before it was quietly cool. Recently did some "certification" of NTP on a RTL system. Was more challenging that I thought to do right (and did find a minor bug in the RTL NTP system (or rather a deeper RTL issue that manifested through those tests)). IAC, armed with a pretty cheap GPS and its 1 PPS signal one can check the NTP algo to about 1000x the accuracy of NTP. [hate to say it, but if you need better accuracy, get a GPS and use the 1 PPS to know the top-of-second quite accurately (less than 1 µs)].
Having spent months(!) debugging a pesky clock sync problem on a small IOT product, I've developed a distain for NTP. It's great when it works, but when problems emerge on remote customer devices in the field, default NTP provides very few clues. There's a reason why people are developing alternatives like chrony.
Yes, and the reason is they don't understand the complexity of the problem they are trying to solve.
There are some problems that chronyd addresses, but many problems are common and have more to do with admins of client computers not understanding what they're doing, or basic things like not having their timezone configured correctly and then blaming the NTP server for not giving them the correct time. I welcome having multiple compatible implementations of the protocol, but there are things that ntpd can do that chronyd can't. So, it's not a one-for-one trade.
@@shubinternet In my case the "local admin" can be a small medical or veterinary clinic that cannot afford to hire a trained sysadmin. My complaint with NTP (and many other subsystems) is is the lack of clear feedback when things go wrong. I don't know if crony is better, but I can vouch that there is an increasing demand for better.
Ntpq gives you lots of info about the state of ntp. I agree it could be a bit more verbose, but you only need to understand a few commands to troubleshoot ntp problems.
In America our computers also have to contend with the 2 time changes a year as well. In the spring, they jump forward 1 hour at 2:00am and then back again 1 hour in the fall again at 2:00am.
I don't know enough about NTP to know whether it cares about daylight savings time or not, but I suspect it doesn't. Internally, Unix just has a counter that ticks forward by one every second and holds the number of seconds that has elapsed since 00:00 GMT on January 1st 1970. Timestamps on files etc. are just the value of this counter. Only programs which need to produce a human-readable time need to care about timezones, DST and all the other complicated stuff. To do this there's a database which lists when DST finishes and ends etc. for each timezone that can be used to do the conversion from internal timestamp to human-readable and library routines which know how to use the information in the database.
I’ve made a big NTP wall clock with ESP it’s amazing
@Seb Gibbs supply and demand.
It would make sense for industry or corporate applications to have mass produced NTP clocks installed throughout a building, especially where daylight savings is used. A clock should be able to run on PoE, so it becomes a one plug solution that lets all clocks be adjusted remotely.
I would think governments and government institutions like schools would provide a decent customer base, enough to make the product viable at least.
Thanks that's more complex than I would have thought 8-)
He's so gentle I forget I'm hearing super serious technical chat
That's another question answered, I use Net Time manually every so often, I was thinking about how they compensated for such time/distance variances, it syncs "perfect" with the "RF regulated" clock I have.
Great explanation!
Thanks!
there's a strange series of articles if not books on the technical wonkiness surrounding tea time across so many industries
really cool video, I actually implemented NTP as part of my home network, since we're in a house share with lots of computers and a file server (NAS) it's nice to have everything syncronised, so i turned it on as a DHCP option and have the NAS serve as the network time server for local clients and it gets it's time from one of the internet NTP pools.
I wonder how NTP would cope with asymmetric channel latency such as on RFC1149
This is the best video ever
God damn fascinating, the way to see an earthquake in the clock drift.
Nice sir explain. Really amazing. I like it.
I wish this explanation got into the conf setups
Are you guys going to do a video on PTP (Precision time Protocol)?
I deal with server software that gets especially grumpy if time rewinds.
‘work queue is empty. I need to nap for 2 milliseconds before checking again. wake me at 08:32:15.224’
If you the rewind the clock 5 minutes, then 5 minutes of wall time pass before that alarm gets raised, and work is processed.
That may sound minor, but when that work is processing a counter payment…
Rolling clocks back to fix the time? Bad idea. Adjusting the clock speed? Wonderful.
With VMs becoming more common, I’m seeing more and more multiple time-source issues (once from the hyper visor, once from the OS on the VM).
One of these days, we’ll figure out time. Not there yet.
6:10 defining jitter without using the word “jitter”
Love this channel...
It's crazy that someone watching NTP traffic could see things happening in the real world, like kettles being started and earthquakes. It makes sense though. anything that impacts the electricity that computers are using could cause fluctuations.
Awesome! Can you guys also do a video on PTP?
I wonder what badge was he wearing that caused it to be blurred out :) initially I thought that computerphile did it but then I googled the name and lo and behold, the picture is literally blurred on the university website :)
Could you do a video on clocks changing or timezone and how that affects things. Esp as it’s now automated and no one notices like they used to changing clock an hour by hand.
Don't they all use UTC and the timezone adjustment is done locally by the system? At a guess...
They did! "The Problem with Time & Timezones" with Tom Scott.
@@nowster I miss Tom hosting these videos
Yes, NTP operates exclusively in UTC. All differences from that are a presentation issue within the OS.
3:30 "T1 minus T0 is how long it took to get across [from the client to the server]"
4:30 "The difference in clocks is T1 minus T0 (…) and if that equals zero, then they're synchronized (...) You want to get closer and closer to that"
These two statements seem contradictory, though I suspect we're just missing some piece of the explanation. Why would we want to synchronize it in a way that makes it seems as though the time it takes for our ntp packet to reach the server is zero, when we don't actually believe that to be the case?
The video didn’t explain this very well and left out a lot of the details.
Was this created after mtc midi time code that is used to sync music on beat via midi across multiple recording equipment? Same issue very similar solution.
Next video Precision Time Protocol? NTP its more obscure cool cousing.
im not sure if this has any relevance to anything but if you have ever disconnected from internet and manually changed the computer date settings to as far back as it will let you (mine was 1980) and create a restore point if the date is set at 1980 it is visible on system restore but once you connect to the internet and resync it is no longer visible on the system restore point list. im not sure if this can be used for security considering it to use the internet the time must be in sync. from memory i backdated and created a restore point i then opened that restore point and dragged and dropped other files into it, and as we know data recovery software is quite good at restoring hdd data , i dont know just one of thing that might be overlooked by a hacker or someone might gain physical access if your trying to hide bitcoin wallets etc
What happens if there is a systematic bias in the direction of traffic? e.g. what if there is a computer behind a router where everyone watches Netflix and the incoming route has a 100ms queue on average, or if there's a firewall that inspects all outgoing packets, or something? If you're just using the round trip time and dividing by 2 you'll be systematically off in one direction.
When NPT isn't accurate enough you can use PTP. (IEEE 1588) Precision Time Protocol delivers sub microsecond accuracy.
I was reading about this and saw a video on another channel a while back. The equipment for it looks cheap 😩😂
@@CMD_Line Last company I worked for we had a small back-haul radio sending the time to its connected devices via PTP could support at least 5 slaves from a unit with HW costs of a couple of hundred $ to the customer.
@@IMBlakeley interesting, perhaps I've got the technology used in what I watched incorrectly. It was a raspberry pi being setup as a HW clock and the board being used was rather pricey.
@@CMD_Line For sure proper Grandmaster clocks are very expensive albeit they will support hundreds of slaves. I did some work for a major European telco and they hired in their access from a 3rd party that specialised.
The device we provided was only tested with as I recall 6 slaves albeit the developers were sure that if it wasn't doing other stuff (i.e. providing back-haul for small cells) as well they could support more. There was a discussion about making a stand-alone unit, however, I checked their website and no mention that they went down this route.
There are many companies that can provide GNSS synchronized Stratum-1 references, and they can potentially include rubidium or cesium clocks for highly accurate PPS values. They can easily cost $20k or more, depending on how many clients you want to serve, etc....
Okay so you estimate the round trip time, but what time does the client actually set? t_3 minus half the round trip time?
wow this is way simpler than i was imagining. how do we account for huge outbound latency and tiny inbound latency? or is that rare enough that we just ignore it?
Now, you should do one on IEEE1588 PTP.
Wait, why do I want t0 to be as close as possible to t1 - doesn't that ignore the packet travel time? I'd expect that I want to get the difference to be as close as possible to half the roundtrip time (assuming that the packet travel time is roughly the same in both directions - this can be improved once I synchronize to multiple servers).
The real question is: what kind of wrist watch is being worn by the guy who helped design Internet time synchronization?