A quick word about time
Feb 22nd, 2011 by Jonathon Moore
I’ve copied this post from my blog on my organisation’s Intranet which is why it has a few internal references.
I’ve been meaning to post this somewhere for a while now and this seems like as good a time and place as any…
Time: the slight offset between our PC clocks and the Phone Clocks seems to have caused some confusion as to what you can trust as the accurate time.
The short answer is – PC clocks. They’re accurate to the second (and usually even more than that.)
To explain this we need to look at why we need accurate time on our computers, how we have done this in the past and how we do it today.
Why?
When ever you’re using your machine on the domain you hold a Kerberos security token, there is a record of this on the domain controllers (all of them) which contains its expiry time. When the token expires, you re-authenticate. Time features heavily in this process and if your times are out of sync by more than a few minutes you can’t renew and so can’t get on the servers.
Because of this the network uses a time hierarchy to sync the clocks across the domain to an extremely high accuracy.
SO… As long as our domain controller’s clock is correct, the domain time will also be accurate.
How it was done
As I mentioned, clocks are synced using a domain hierarchy. We call this method NT5DS (catchy eh?)
Basically, a PC or server can sync it’s time securely (certificate authentication) with a domain controller and a domain controller can sync it’s time with the primary domain controller.
The primary domain controller then received it’s time from an accurate hardware source, this was usually a GPS clock connected with a serial cable, later (if you tweak the registry) it was a secure time server on the internet (which will have either it’s own GPS time device or sync from a server farm which has one.)
When computers are switched off they use hardware clocks and a small battery to keep the time running but this is inaccurate and is discarded once the OS starts.
If once you contact the domain controller your time is off, you PC clock will speed up or slow down until you are in sync. This usually only takes a minute or two unless your time is out by more than 5 minutes, in which case you clock will jump to accurate time.
Problems we faced and how they were overcome
(How it’s done now)
We had problems with this method when we virtualised the servers. VMs don’t have batteries so they loose the time completely when we turn them off, to deal with this problem they synchronise with the host server.
The trouble with that is; the host servers are member servers on the domain, so they sync with the domain controllers and hold their time with the hardware clock on restart.
So time sync looks like this:
PC<——DC<——>Host
This two way sync between with DCs and the hosts with no accurate source caused a slow drift in the PC clocks. Everyone could still log on to the domain as all PCs had the same inaccurate time.
To remedy this, we’ve made some registry changes on the host servers to break the NT5DS hierarchy and force them to visit a time server farm for accurate time sync.
This is done in:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Parameters
by changing the ‘Type’ key to “NTP” and adding “uk.pool.ntp.org” to the servers list. (We’ve got a few more in there for redundancy.)
So from start to finish;
The Host server boots and takes its inaccurate time (it’s considered inaccurate but is probably out by less than a second) from the hardware clock.
The OS starts and the time is discarded when we can sync with a secure time source, the much more accurate software clock takes over.
The virtual DC starts, we ‘fake’ a hardware clock and push in the host’s time, once the OS starts we push the host’s time again but this time with the software integration services rather than a fake hardware clock. The DC will occasionally check this service for accuracy.
This accurate time is pushed to client PCs and member servers using the NT5DS hierarchy.
You visit http://www.greenwichmeantime.com/ and find your computer clock exactly matches (well, your browser only check as the page is loading… so if it’s out by 1/2 a second your PC clock is the more accurate of the two.)
…and the phone system?
The phone system doesn’t sync with an external time source and doesn’t have an accurate hardware time device. We have to manually set the time and it’s held in an inaccurate battery powered hardware clock on restart.
This causes the time to drift. I estimate by around 10 minutes a year (the phone system clock is fast, just in case you were interested in the drift direction.)
I think this is addressed in the next version of the phone system software.
So next time you need an accurate time reading, look to the task bar and not your phone.







