The Planet Blog

Time is something we all take for granted. It is the only finite measurement that all businesses and individuals rely on. We have doctor appointments, meetings to attend, bills to mail and deadlines to meet. What happens when you can’t depend on time? How do businesses and individuals operate without a universal standard of time? In truth, operating without time is probably one of the worst possible situations to deal with and, trust me, it does happen!

While doing my tour through technical support, I found that most server time clocks were incorrect. This led to a number of issues ranging from an SSL not working, inabilities to log-in and difficulty tracing a problem through log files. I don’t blame the administrators of those servers, because it all comes down to how our clocks tick.

There are two clocks with every computer, the hardware clock and the system clock. CMOS uses the hardware clock to keep track of time running at 64Hz (usually). The system clock runs at whatever the kernel is compiled to run at. In Linux, the default 2.6 kernel line defaults to 1000Hz** for increased interactivity at the cost of more overhead. But, you can recompile between 100Hz, 250Hz and 300Hz. Each set of tick rates has their advantage and shortcomings. Soon to come, there will be a tickless Linux kernel, making the problem even more interesting. Let’s save that for another day.

As the CMOS ticks away at 64Hz and the kernel at 1000Hz, there is a drift from one clock to another called a skew. As the clocks drift apart the system clock “runs” faster than the CMOS clock, and the time between the two no longer serves as a concrete form of measurement. Instead, you have a CMOS clock that is probably running a bit slow, and a system clock that is running quite a bit faster. How do you use the clock as a reference clock for anything at this point?

Enter Network Time Protocol. It keeps all the clocks in the world within milliseconds of each other (when configured to use NTP). Administrators will setup systems to sync against logistically close Tier 2 NTP servers.

I won’t write a how-to on the setup of NTP servers, there are a number of articles that already exist out on our glorious series of tubes. I will explain a little how NTP does work, and how it will apply to every server you deal with going forward. NTP and its corresponding tools will adjust your system’s clock to accurately reflect your designated offset from UTC time. NTP always responds in UTC time, but the NTP tools running on your server will make the time zone adjustment.

If your clock is fast, it will slow down the conversion of jiffles/ticks until your system clock more accurately reflects the correct time. If your clock is slow, NTP will automatically adjust your time. Time is a linear progression and does not deal well with “future” dates. Many tools utilize modification times of their configuration files to see if they need to be reloaded. IDS monitoring tools utilize modification time, checksums and log times. Payment gateways are sensitive to time as well. Having a date set in the future breaks many logic gates, and can leave you troubleshooting issues for hours or destroy precious financial records.

At The Planet, we have a time server for you to use to help offload some stress from public time servers: ntp.theplanet.com

Feel free to utilize this on your servers, if it isn’t already setup for it. Don’t forget to set-up a cron job to sync your hardware clock against your system clock. I highly suggest reading this article from Vmware on the subject as ticks and drift get very complicated when you add virtualization.

Good luck. I hoped I cleared things up a bit!

- Kevin Landreth, RHCE

** Most recently changed to 250Hz, but it really depends on who compiled the kernel

This entry was posted on Tuesday, June 19th, 2007 at 5:00 am and is filed under Tech Stuff. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.