Time is an interesting phenomenon. If you ask ten people what time it is, you’ll likely get ten different answers…especially if you ask them the exact hour, minute, and second. For most people living their normal lives, this slight variance in time is not a huge deal. But for networks and web applications, time is an extremely critical thing. When computers do what they do, sometimes they wait to conduct certain operations until a certain time-of-day has arrived. Other times, computers speak to each other and coordinate operations based on the exact time of day. What if one computer thinks it’s one time and the other thinks it’s another? This timing issue could cause some really big problems!
As it turns out (for computer and network applications), it doesn’t matter what the true time really is…it only matters that everyone agrees on what time it is. Now, to be fair, the goal is not to have everyone agree on some random, false time. Ideally, we know the true time as much as we can possibly know it and then coordinate all our machines to that same time.
In the late 1970’s the first-ever time synchronization technology was used at a computer conference in New York. This technology evolved over time and ultimately was presented in 1991 in an IEEE Transactions on Communications article written by David L. Mills. The technology is known as Network Time Protocol (NTP), and it defines the way that clock synchronization happens between computer systems. NTP is designed to synchronize all participating computers to within a few milliseconds of Coordinated Universal Time (UTC). It uses algorithms to select accurate time servers, and it’s designed to mitigate the effects of variations caused by network latency. The current protocol is NTP version 4 and is documented in RFC 5905.
According to the RFC, the UTC timescale represents “mean solar time” as disseminated by national standards laboratories. The system time (clock on your web server, clock on your PC, etc) is represented by the system clock maintained by the hardware and operating system. The goal of the NTP algorithms is to minimize both the time difference and frequency difference between UTC and the system clock. When these differences have been reduced below nominal tolerances, the system clock is said to be synchronized to UTC. That’s the entire point of NTP…keep everything within a tolerable time difference to make sure all devices agree on the time.
The basic architecture of NTP uses a hierarchy of time servers that are assigned “stratum” values. Stratum zero devices are at the top of the hierarchy, and they are the clocks by which all the other computers set their time. The interesting thing about Stratum zero devices is that they cannot be connected directly to the Internet, but rather they are connected to and provide exact time for Stratum 1 level servers. Stratum zero devices include atomic clocks, GPS clocks, etc. These are the crazy-sophisticated clocks that keep really, really accurate time. Since Stratum 1 servers are directly connected to the Stratum zero devices, the Stratum 1 servers typically have very accurate time and are sometimes referred to as “primary time servers.” The Stratum 1 time servers are connected to each other and also to the layer below them (Stratum 2 servers). Likewise, the Stratum 2 servers are connected to themselves and the layer below them (Stratum 3 servers). This mesh of connectivity is repeated for all layers of Stratum servers. In all, the NTP protocol allows for 16 layers of Stratum time servers. As you can imagine, the lower down the list you go, the less accurate the time might be. Also, some time servers limit the number of clients who can connect to them, so keep that in mind as you configure your NTP settings.
You can configure the BIG-IP to use an NTP server for its system time settings. Simply log in to the BIG-IP, and navigate to System > Configuration > Device. Then click NTP, and on the Properties page, type the IP address of the NTP server in the Address field. Click Add. Continue to add IP addresses for as many NTP servers as you need, then click Update and you’re all done! Don’t forget that you also need to ensure that the BIG-IP routing table is configured appropriately to support the intended routing path for NTP traffic.
It’s important to stay connected to a reliable time source because time is changing all the…time. Did you know that the rotation of the earth on its own axis is slowing down? Did you also know that, as the earth’s rotation slows, more time is needed to make a full day rotation? We always say that there are 24 hours in a day. Well, that’s not exactly correct. In fact, today will last 24 hours and 1.45ms. By the way, here’s a cool website that shows a bunch of cool numbers related to time and day: https://www.timeanddate.com/time/earth-rotation.html.
Because of all this “slowing down” stuff, time servers inevitably need to add seconds to the day every now and then. These added seconds are known as “leap seconds” and we experienced one at the end of December last year. Check out the following screen capture from the UTC clock listed on the time.gov website. You’ll notice that an extra second was added when the clock went from 23:59:59 to 23:59:60 to 00:00:00. Did you know that, in the past 40 years, a leap second has been added about every 18 months? Crazy stuff, huh?!?
Not all clocks handle these leap seconds the same. The UTC clocks add an extra second (as shown in the screenshot above), some NTP implementations freeze the clock for a second, and others smear the extra second over the course of hours or days leading up to the leap second (Google chose to do the smear method for the Dec 31, 2016 leap second). Either way, this time thing is a big deal, and it’s important to think about how you will deal with these extra seconds so you don’t crash like some of the 2,000+ networks did during the last leap second.
Be safe out there, and don't waste that extra second you were given this year!