Network Time Protocol - get atomic clock's precision from the Internet

by Girish Venkatachalam

Girish Venkatachalam is a UNIX hacker with more than a decade of networking and crypto programming experience. His hobbies include yoga,cycling, cooking and he runs his own business. Details here:

It is ridiculous that a computer that we buy for several hundred dollars cannot be as accurate as a watch that be bought for less than 10$. That does not have to be the case once you read and understand this article.

Network Time Protocol described in RFC1305 in enough detail and chatty language is the trick behind keeping computers in sync with the most accurate time sources on the plant - atomic clocks on board satellites that are used by GPS gear.

GPS will not even work without sub millisecond accuracy but our computer can be oblivious of time and still do all its work. This is true of even servers including mail servers or web servers.

But it is backward to not have accurate time on your machines. Especially when you can easily get this for free on the Internet.

All you have to do is run the ntp daemon. There are several watered down protocols called daytime and rdate that can help too. For instance, all you have to do is type this as root:

	# rdate

That is all there is to it to fix a clock that might have been off by even days. Who knows?

There are also Windows software that can do the same thing. Please google for "free SNTP client". You know what SNTP will stand for if you know NTP. It is Simple Network Time Protocol.

I started my career in Novell in 1998 with a protocol converter project that would make the Netware world talk to the UNIX world. I wrote a program that would act as a bridge for time and translate the proprietary TimeSync format with the NTP time format.

My project suddenly assumed a lot of importance when their Netware server experienced severe time lag due to some driver eating up the timer interrupt.

I think mostly due to corporate politics than anything else, the driver team refused to fix the issue. And the issue was in our hands. I did the right thing by ignoring the timer interrupts and taking time from the hardware clock on the PC. The RTC that is found on most computers.

My work was appreciated in the form of an award though what I did was clearly wrong. The real fix should have been on the driver. But this should tell you something about the commercial corporate world. They put the cart before the horse and see things upside down.

Let us save our crib about the silly commercial world and get back to the wonderful world of UNIX and open source geeks. Before that I wish to point out that my work also was critical in signing a 5 million dollar deal with British Telecom long ago. They had two networks firewalled from one another and time had to be synchronized between them. I suggested using NTP since the Internet has several freely available public NTP stratum 1 servers.

By the way, Novell had a dying need for accurate time due to directory synchronization. NDS which was a precursor to LDAP needed time to be in sync.

But as I said in the beginning, it is ridiculous and somewhat inane not to have your computers in sync with the accurate time. You might not need microsecond accuracy but asking for millisecond accuracy is not too much. Come on, computers are deterministic and this is what they are good at.

There is a command called ntpdate which works similar to rdate on the surface but underneath it is very different.

	# ntpdate

I should also talk about the innards just to pique the curiosity of detail oriented peoples. NTP uses source port and destination port UDP 123 for its time query packets. And NTP works in unicast or multicast mode. I have never bothered with multicast configurations. NTP does add traffic to the network but in today's terms it is negligible and inconsequential.

NTP comes with a clock filtering algorithm, a clock selection algorithm when faced with multiple sources that offer different times and it also has protections against malicious tampering by using cryptographic keys.

stratum 1 servers are supposed to be the most accurate followed by stratum 2 or stratum 3 depending on how far away they are from accurate time sources like the atomic clocks. I believe that OpenBSD comes with time sensors that can obtain time through long wave radio and adjust their clocks. This is not available in the entire developed world.

The way NTP does its work is by exchanging UTC time format in the number of seconds that elapsed from 1900 1970 in a 64 bit field. 32 bits of seconds and 32 bits of subsecond data. You have leap years, leap seconds and what not. And the counter will overflow in 2038. People are predicting the world to end by then...that we will have a revisit of the y2k problem. Do you care?

Here is the equation for clock correction.

	time difference = time at destination - time at source

Time queries are sent as simple UDP packets with time fields on them. The time fields are used to arrive at the correction factor. The computer never sets its clock back. So don't be surprised if your computer does not go back in time. And for NTP to work, the packet latency in the forward and reverse paths have to be the same. Otherwise you won't get accurate time. Think about it, you will know why this is necessary.

Got something to add? Send me email.

(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Network Time Protocol - get atomic clock's precision from the Internet


Increase ad revenue 50-250% with Ezoic

More Articles by © Girish Venkatachalam

Wed Sep 23 10:15:23 2009: 6954   TonyLawrence

Well, I think you were right to ignore the driver issue because interference with clock updates can always happen - and does, which is why we need ntp.

It's actually ntpd that should be configured and running - ordinarily there should be no reason to run rdate or ntpdate. "rdate" is just going to fetch and set the time, while ntpd takes a more gentle approach, avoiding sudden shifts by effectively slowing down or speeding up the clock.

The man page for ntpdate on my OS X says "After a suitable period of mourning, the ntpdate utility is to be retired from this distribution."

Wed Sep 23 10:45:57 2009: 6955   TonyLawrence

By the way, the "can't set time backward" limit reminded me of this 2006 article on that subject:

Wed Sep 23 15:28:29 2009: 6957   BigDumbDinosaur

In years past, I inserted a call to ntpdate into a startup script to correct the time. The CMOS clocks in most PC hardware are not particularly stable, and both forward and backward drift are not uncommon. So a good swift kick was often necessary to get the clock into sync with the rest of the universe. The xntpd startup script in many Linux distributions performs a similar action.

It should also be noted that a file called ntp.drift should be present in /etc (on most systems) while ntpd is running. ntp.drift tracks how much and in which direction the system's notion of time wanders. The resulting average can be used to gently skew the clock at ntpd's startup absent a connection to an authoritative Internet time server.

As for the time server itself, you should pick several that are geographically close to your location to limit the effects of packet propagation time. ntp.conf should be configured to recognize at least two stratum 2 servers, or better yet, three. Most larger colleges and universities maintain stratum 2 servers, which are about as accurate as anyone needs. I use and (University of Illinois at Urbana-Champaign) as my primary references, with a backup reference to

...keeping computers in sync with the most accurate time sources on the plant - atomic clocks on board satellites that are used by GPS gear.

Although the atomic clocks found in GPS satellites are indeed very accurate, they are not the most accurate. Currently, that title would belong to the U.S. Naval Observatory's master clock (see
(link) for more info), which is an amalgam of cesium beam and hydrogen maser timekeepers. The U.S. GPS constellation refers to the Naval Observatory master clock for stabilization. The master clock also drives a set of stratum 1 and 2 time servers.

Speaking of time and clocks in general, the Naval Observatory website at
(link) is a very interesting place to visit, especially if you are fascinated by really cutting-edge technology. It's also a good place to send your school-age children to learn about timekeeping and its history.

Wed Sep 23 15:04:34 2009: 6958   Jeff

Every UNIX server I know keeps track of UTC time via the number of seconds from 1970, not 1900 aka UNIX EPOC time. See

Wed Sep 23 15:24:48 2009: 6959   BigDumbDinosaur

Every UNIX server I know keeps track of UTC time via the number of seconds from 1970, not 1900 aka UNIX EPOC time. why didn't I see that little error when I was reading the article? Must be because of the fine print Tony uses on all of his pages. <Grin>

Wed Sep 23 17:59:20 2009: 6961   TonyLawrence

I missed the epoch date also, but you can blame Microsoft for the smaller fonts - if I don't cut -em back, it's GIGANTIC on stupid Microsoft browsers. I figure anyone running a good browser knows how to increase font size; people using Microsoft by choice are plainly too dumb to do anything with a compuyer, so we try (only a little) to be nice to them.

Kerio Samepage

Have you tried Searching this site?

Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

privacy policy