all site content copyright © chris rue. all rights reserved. any reproduction, re-use or summarization of any kind without prior written consent is prohibited.
July 6, 2008

A Matter Of Time

Repent Harlequin, said the Tick-Tock Man!

There’s no single more important thing to the long-term health of any network system than accurate time.

Without accurate time, there is no way to assure than any transactions flying in that environment will maintain fidelity. In other words…

There’s no way to know that databases, Active Directory, file systems, or anything else that uses any kind of timestamp isn’t shredding itself to bits.

10 years ago or so, time sync used to be much more of an issue. Oh sure, you could always load a dialer program that would call Colorado (in the US) and get a time adjust to the master clocks. But that was a major pain in the tookus. And it cost you money with each call.

Thanks to the glorious achievement that is the Internet, and a little gem called Network Time Protocol AKA NTP (including its eponymous sibling Simple Network Time Protocol AKA SNTP), time sychronization became largely a moot issue in data networks during the 90s.

The key to time synchronization, at least as far as maintaining a healthy network goes, is not so much having correct time (more on that in a minute), but having consistent time, which are two very different concepts.

Although it might make your users mad when the clocks on their PCs are off a bit, it is usually far more healthy for the average data network to be 5 minutes off everywhere, as opposed to having different parts of the network running on-time whle other parts do not.

The consistency of time in a data network has far-ranging implications. For Active Directory, one of the primary functions that depends on consistent time is network logon.

That’s because Active Directory uses Kerberos tickets to validate logon traffic. The tickets, which are by design time sensitive and expire so that captured traffic cannot be replayed and used to compromise systems in a classic man-in-the-middle attack, rely on consistent time. We’re normally talking about a 5 minute (which is an absolute eternity, in computer time actually) for everything to remain both hunky and dory.

The stampede rush to all things virtualization is poised to make time synchronization a key network design issue, all over again.

Because when the magic act that is virtualization makes the hardware go poof, there’s one major thing that goes away forever…

The BIOS Clock

Sure, a BIOS clock isn’t the end all, be all.

But it will keep you, and your systems, in the ballpark.

So if you aren’t spending time planning clock synchronization for your virtual systems, you’d best get that taken care of, and pronto.

|| posted by chris under business, hardware, it pro, migration, rx, time, virtualization || comments (2) || ||


  1. And it’s generally ACPI-aware OSes that have the most amount of grief.

    Expect lots of clock drift on unsupported ACPI-aware OSes (Linux, FreeBSD, etc) running in Hyper-V.

    VMWare have a good timekeeping document which provides some good background on how it all works and what VMWare Tools actually does.

    Still waiting with bated breath for MS to document this as well as VMWare have done…

    comment by Chris Knight — July 7, 2008 @ 2:03 am

  2. @ Chris…

    Thanks for the link to the VMware time document. I’ve seen that before, and it’s an excellent primer for time issues in virtual environments.

    Unfortunately, as that doc rightly points out, there’s no standard way for determining time. I predict drift will be making huge comeback, even on supported ACPI-aware OSes.

    A few more posts on that in a bit…

    comment by chris — July 7, 2008 @ 7:01 am

rss feed for comments on this post. | trackback:

leave a comment

XHTML ( You can use these tags): <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> .