As someone who works on the perf space, I am always measuring how long things are taking. I rely on APIs exposed by the operating system to do measurements. So, it came as a surprise to me when one function that I expected to take a few seconds, ended up taking several hours. So, I dug into the data and found some interesting things.
How do computers know the current time?
I was recently traveling to Denver, Colorado from Seattle for vacation. I had taken my laptop with me on the trip. Denver is in a different timezone than Seattle and the flight took about 2 and half hours. But as soon as I opened my laptop and connected to wifi, my computer correctly updated the correct current local time in Denver. But how did this happen?
The magic sauce is Network Time Protocol (or more commonly known as NTP). NTP is a very widely used protocol that allows computers to synchronize the current time with other computers in the network. Computers in a network routinely ping each other or a NTP server to get the current time. So, my computers pinged someone who told my computer about the current time and it updated itself to the latest time.
Measuring Execution Time
As I mentioned my job is to obsessively measure every piece of code that we ship to customers. One of the common forms of measurements I do is the execution time measurement. I literally do something like this
const startTimeStamp = get_current_time();
executeSomeCode();
const stopTimeStamp = get_current_time();
console.log(stopTimeStamp - startTimeStamp);
Let’ see what the computer does when you ask it to run the code above.
- Look at the clock, write down the current time and store it in the
startTimeStamp - Execute the code
- Look at the clock again, write down the current time and store it in the
stopTimeStamp
Once again, you might still be confused “What is this guy complaining about?”
Time Traveling Clocks
As I mentioned above, computers are constantly pinging other computers in the network to get the correct current time and updating themselves. But what happens if the computer was offline for a few hours and then is reconnected to the network.
Time travel happens.
You might be like “What? Time travel? No way. This guy must be out of his mind”
But it is true. Let’s go back to my vacation example. When I closed my laptop at the Seattle airport, it was 5 AM PST. When I landed in Denver, the time was 8:30 AM MDT. From the time my flight took off in Seattle to me re-connecting my computer to wifi in Denver, my computer was not connected to the network. So, it had no idea that I had flown two and a half hours and is now in a different time zone. So, as soon as the computer was connected to the network, some other computer in Denver told my computer what the correct current local time was and my clock traveled forward to match the current local time. Boom. Time travel baby.
Reconnecting to the network is not the only time a clock can time travel. Almost all of the OSes allow an admin to change the clock anytime. So, if the administrator decided that the current time should 12 PM MDT even though it is actually 9 AM EST, you are unfortunately stuck with that. Usually the time from NTP doesn’t override the admin setting. And, the admin can decide to do that anytime and even remotely.
But you might still be confused “What does all of this have to do with execution time measurement?”
Incorrect Execution Time Measurements
If you are using the computer’s clock to measure execution time like I was, you have to account for the possibility that the clock might time travel forwards or backwards at any time. This will often result in incorrect measurements.
In my case, the customer’s administrator decided that every computer in their organization has to follow Japan Standard Time irrespective of where the person is actually located. They decided to enforce this setting while I was still in the middle of measuring something and the clock time traveled forward by several hours.
You must be thinking “There has got to be a way to fix this right?”. And the answer to that question is a yes.
Monotonically Increasing Clocks
To help prevent time travel while measuring something, OSes have another set of APIs called Monotonically Increasing Clocks (MICs). MICs have one property. These clocks can only tick forward by a fixed linear amount. MICs are not hooked up to NTP and cannot be changed on the fly by an admin.
I will cover how to use monotonically increasing clocks in different programming languages in a follow up post.
Leave a comment