A Matter of Timing: Consumer Electronics & Network Time
Table of Contents
A MATTER OF TIMING: CONSUMER ELECTRONICS & NETWORK TIME
1
WHAT IS THE NETWORK TIME PROTOCOL (NTP)?
1
WHY DO I NEED TO KNOW ABOUT NTP?
HEROIC ENDEAVOR
SETTING THE DATE & TIME
SYNCHRONIZED (DEVICE) SWIMMING
2
2
2
2
HOW DOES IT WORK?
2
CLOCK STRATA
STRATUM 0 & 1:
STRATUM 2:
STRATUM 3+:
NTP TIMESTAMPS
CLOCK SYNCHRONIZATION ALGORITHM
SECURITY MATTERS AND NTP
3
3
3
3
3
3
4
GETTING YOUR HANDS DIRTY WITH NTP
4
RASPBERRY PI ANYONE?
MAKING IT HEADLESS
UPDATING AND CONFIGURING NTP
WHAT SORT OF ACCURACY CAN I EXPECT?
STANDARD CONFIGURATION
LOCAL LAN TIME SERVIER
HARDWARE TWEAKS WITH GPS
4
4
5
6
6
6
7
IEEE PRECISION TIME PROTOCOL (PTP)
9
REFERENCES
10
What is the Network Time Protocol (NTP)?
The Network Time Protocol (NTP) has become widely used across the Internet to
synchronize clocks on computers, and more recently on a wide variety of handheld devices.
Many of us are using NTP on a daily basis without even knowing it - when you set your
mobile phone to get its time from the local network you are linking into a global network of
NTP servers that co-ordinate time across the entire Internet.
The NTP architecture, protocol and algorithms have evolved over more than three decades to
become the NTP Version 4 specification [1]. There are many reference implementations
available and NTP has been an integral part of Unix systems from the early days of the
ARPAnet.
Ongoing research over a 30-year period has led to a series of improvements in accuracy and
reliability of the protocol and supporting algorithms. Today, when used with a fast wired
network NTP can provide accuracies in the range of 0.1 ms; in a more peripheral network, or
over a wireless connection it will still provide accuracies of a few tens of milliseconds - more
than sufficient to keep your mobile phone in synch!
NTP provides Coordinated Universal Time (UTC) including scheduled leap second
adjustments. No information about time zones or daylight saving time is transmitted; this
information is outside its scope and must be obtained separately.
The current reference implementation is version 4 (NTPv4), documented in RFC 5905.
Why do I need to Know About NTP?
Well the obvious answer to this is to keep time!
You've problem noticed that almost every new CE device these days is connected to the
Internet. And most new services are delivered over that darn Internet so Internet connectivity
has become a bit of a sine-qua-non for consumer devices.
Heroic Endeavor
On the other hand consumer electronic devices always have to save costs wherever possible.
If you can save 0.10c on a device and you are selling 100 million units, you've just saved your
company 10 million which will make you a big hero! So many devices are losing their
hardware clock ICs in the interests of heroism.
At an even greater level of heroic endeavor many devices are also using low-cost internal RC
oscillators rather than reliable crystals. Of course RC oscillators tend to drift quite a bit with
temperature so local time calculations will be quite a bit different in Los Angeles compared
with Moscow. And you'll have significant difference between Summer 'time' and Winter
'time' as well! And don't forget that there is quite a variation between production batches with
capacitors varying up to 20% in value depending on the manufacturing process.
Setting the Date & Time
So, your modern CE device is quite likely to have an unreliable local time-base but at the
same time your users will want it to be aware of the date & time. Remember all those older
devices where you had to keep resetting the time & date every time you switched the
batteries? No? Well that is because nobody makes them any more, not since we transitioned
into the 21st century. And no-one misses them!
In fact I can hardly remember the last time I had to set the data & time on a device! So if you
want your modern CE device to keep time, without a reliable hardware time-base, you need to
use NTP.
Synchronized (Device) Swimming
Of course that is not the only reason. There are many interesting and cool things you can
build that involve multiple networked CE devices that share a common time-base. In fact
once you start thinking about it you'll probably come up with a few ideas of your own. I'll
give some practical examples later in this article, but for now lets reflect on the beauties of
synchronized swimming and how our devices could behave in newly co-ordinated ways once
they all share a common understanding of time.
Now, back to the technicalities.
How Does it Work?
NTP uses an algorithm developed by Keith Marzullo
for his Ph.D. dissertation in 1984 [2], and is
Figure 1: NTP Clock Hierarchy - Strata 0-3
specifically designed to resist the effects of variable latency. As a consequence NTP can
usually maintain time to within tens of milliseconds over the public Internet, and can achieve
<1 millisecond accuracy in local area networks under ideal conditions.
Clock Strata
NTP uses a layered hierarchical system of levels of clock sources. Each level is termed a
stratum and is assigned a layer number starting with 0 (zero) for master-clocks at the apex of
the hierarchy. The stratum level defines the distance of a time server from the reference clock.
The use of a stratum level prevents cyclical dependencies in the hierarchy. As each server
uses a higher stratum server to provide its master synchronization there can be no 'synch
loops' between any two servers. It is important to note that the stratum is not an indication of
quality or reliability. Many stratum 3 time sources are of higher quality than stratum 2 time
sources.
Figure 2 - NTP Clock Strata
Stratum 0 & 1:
Stratum 0 represents the stand-alone high precision atomic standard clocks, GPS clocks or
similar. These master-clock devices are traditionally not attached to the network; instead they
are locally connected to computers (e.g., via an RS-232 connection using a pulse per second
signal). Stratum 1 computers are those attached to the Stratum 0 devices. These act as servers
for timing requests from Stratum-2 servers via NTP.
Stratum 2:
Computers that send NTP requests to Stratum-1 servers. Typically a Stratum-2 computer will
reference more than one Stratum-1 server and the NTP algorithm determines the optimal data
samples, dropping any Stratum 1 servers that show a lack of consistency. Stratum 2
computers will peer with other Stratum-2 computers to provide more stable and robust time
for all devices in the peer group. Typically the Stratum-2 computers will also act as servers
for Stratum 3 NTP requests.
Stratum 3+:
In the same way Stratum-3 computers obtain a master time from one or more Stratum-2
servers, they peer with other Stratum-3 servers and act as servers for Stratum 4 NTP requests.
For higher level Strata there are significantly fewer computers and it is rare to find a Stratum
6 or higher order server.
NTP timestamps
The 64-bit timestamps used by NTP consist of a 32-bit part for seconds and a 32-bit part for
fractional second, giving NTP a time scale that rolls over every 232 seconds (136 years) and a
theoretical resolution of 2−32 seconds (233 picoseconds).
NTP uses an epoch of January 1, 1900. The first rollover occurs in 2036, just prior to the
UNIX year 2038 problem.
Future versions of NTP may extend the time representation to 128 bits: 64 bits for the second
and 64 bits for the fractional-second.
Clock synchronization algorithm
NTP has to compensate for various sources of time delay. The most significant of these are
kernel latencies in the local operating system, and network latencies both locally and over the
global Internet. To match its clock-time with a remote server, an NTP client must compute
the round-trip delay and the offset time.
The round-trip delay is computed as   (t3  t0 )  (t2  t1)
where
t0 is the client's timestamp of the request packet transmission,
t1 is the server's timestamp
of the request packet reception,

t2 is the server's timestamp of the response packet transmission and
t3 is the client's timestamp of the response packet reception.
And thus
t3 − t0 is the time elapsed on the client side between the emission of the request packet
and the reception of the response packet and
t2 − t1 is the time the server waited before sending the answer.
The offset θ is given by  
(t1  t 0 )  (t 2  t 3 )
2
Correct synchronization is achieved when both the incoming and outgoing routes between the
client and the server have a symmetrical nominal delay.
Security Mattersand NTP
An important point with any distributed Internet service these days is its vulnerability to being
attached by malicious individuals. And you can imagine the potential havoc that could be
achieved by attacking a global time service like NTP! Don't panic, the origins of NTP lie in
the ARPANET, which was originally a military project. As a consequence security has
always been embedded into the core of NTP [3].
Getting your Hands Dirty with NTP
Well this is an ‘electronics’ magazine so what better way to get to know NTP than actually
building a working NTP system! As you will probably have gathered NTP has a long
tradition with its origins in the early days of the Internet and the Unix operating system. But
nowadays you can find Unix even in small, embedded systems.
Naturally enough many people have found interesting uses for NTP and perhaps one of the
best practical descriptions of how to set up a ‘local’ time-server is provided by David Taylor
at http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html. David has kindly agreed to presenting
some of his work and practical results in this article. His principle application for NTP is in
satellite communications systems.
OK, lets get started.
Raspberry PI Anyone?
Well in case you’ve been living under a rock for the last few years, the Raspberry PI isn’t
actually a ‘pie’, instead it is one of the latest DIY embedded systems, offering a CPU that can
run Unix together with state-of-art HDMI for display. It also comes with USB for keyboard
and a spare USB for ‘something else’.
So if you provide the display (can be an old TV, or a modern HDMI monitor or TV panel)
and keyboard you can boot the PI from a standard SD card. The PI has its own version of
Unix, but you can also build your own OS from one of the many POSIX based operating
systems that exist. And given that it costs less than fifty dollars it’s a great way to build
inexpensive prototypes or even a low-cost Unix box.
Every engineer should have a PI on their desktop! In fact the goal of the foundation that
makes the PI was to educate today’s kids in the basics of computer systems. A BBC-micro for
the 21st century.
Making it Headless
To start implementing an NTP system you’ll need at least one other computer, but if you are
brave I’d suggest buying a few PIs so you can fun with something more complex (more on
that later).
Now the first thing you need to do with your PI is to turn it into a ‘headless’ system. No you
won’t need a large axe and bucket to catch the blood … the ‘headless’ means that your PI will
operate without keyboard and display.
As our application is for an NTP server, a display isn’t needed for the Raspberry Pi, nor a
keyboard or mouse. All interaction will be via a terminal, and even that will be emulated via
program running on a remote PC, with connectivity through the Ethernet port on the
Raspberry Pi. Such operation is commonly called a ‘headless server’. There is additional
advice on running headless here: http://glynrob.com/hardware/raspberry-pi-headless/ .
A terminal program is also needed to communicate with the PI, one that will work in SSH
mode - PuTTY is a good choice if you are using a Windows PC.
It will be helpful initially to check your router to see the IP address that is assigned to the PI,
and then use that address to run PUTTY in SSH mode. Once a connection is established you
can access a full Unix terminal with the default user name and password.
Figure 1: Raspberry PI in a basic case; note on the right the SD card that is used to boot the
OS.
Updating and Configuring NTP
Now the nice thing about the PI is that it doesn’t have a hardware clock – the basic clock
function is provided by NTP! So when you install a standard distribution you automatically
get NTP running on your PI.
After you boot the PI from SD card you may want to update the OS (and thus the NTP
module). To run these commands requires privileged access, achieved here by prefixing the
command with sudo. These commands take considerable time to run, and require Internet
access from your Pi. Allow 30 - 45 minutes.
$ sudo aptitude update
$ sudo aptitude dist-upgrade
$ sudo apt-get update
$ sudo apt-get dist-upgrade
You may need to restart the OS after making these changes:
$ sudo reboot
You can find additional details on David’s web page - http://www.satsignal.eu/ntp/RaspberryPi-NTP.html - if you want to configure NTP for best results on the local network. Remember
NTP time actually originates from the Internet, but if you set up a local time server you’ll be
able to synchronize more accurately with that local clock than with a time server that is out
‘somewhere’ on the Internet.
What Sort of Accuracy can I expect?
Well that really depends on how you configure NTP. Out of the box NTP on the Raspberry is
set up to use Internet time-servers. The level of accuracy will depend on a number of factors
including how fast and reliable your network connection is, how close, in terms of
communications latency, you are to a stratum 1 or stratum 2 time server and a range of other
local network configuration factors.
But as a rule you’ll get less than 10 millisecond variations and this tends to improve with time
as NTP ‘learns’ some of the characteristics of your local network connection.
Standard Configuration
Figure 2 below shows a typical graph over a couple of days for such a standard configuration.
It can be seen that maximum fluctuations in this case are no more than 5 milliseconds. This is
more than sufficient accuracy to use for time on a conventional clock.
However it would be nice if we could get even better accuracy?
Figure 2: Offset Using Internet Servers Alone; time in hours on horizontal (X) axis; deviation in
milliseconds on the vertical (Y) axis.
Local LAN Time Servier
Well the first way to improve performance is to move the time server closer to your NTP
client. This can be easily achieved by (i) setting up some local NTP time servers on your local
network, and (ii) giving these local servers priority over the Internet pool of servers that NTP
normally uses to determine time.
If you have a Unix system on your network – and this includes a modern Mac – then you may
already be running NTP. But you’ll need to make sure that the time-server package is
installed and running. Ideally it is better to have more than one local time server.
Again you will find details on how to configure this mode of operation on David’s web page
including some useful tips. The results are well worthwhile as can be seen in Figs 3(a) & (b)
below. Note that the timescale in Fig 3(a) is in microseconds so use Fig 3(b) to compare with
Fig 2 above, noting the entire vertical scale of Fig 3(b) is one millisecond!
Figure 3(a): Offset Using LAN Servers; time in hours on horizontal (X) axis; deviation in
microseconds on the vertical (Y) axis.
Figure 3(b): Offset Using LAN Servers; time in hours on horizontal (X) axis; deviation in
microseconds on the vertical (Y) axis.
So we can say that using local time servers will greatly enhance your NTP accuracy enabling
synchronization to within 50-100 microseconds, or 0.05-0.1 milliseconds. Not bad at all but
we can do even better!
Hardware Tweaks with GPS
Yes, it is possible to get even better performance from NTP. To do this you’ll need a GPS
module with a ‘one pulse per second’ (1 PPS) signal. The 1 PPS is obtained from GPS
satellites in orbit and is synchronized very accurately. Even though it operates at quite a low
frequency it can be used to amplify the accuracy of the NTP clock.
This is where you really start to get your hands dirty as most GPS modules require some
physical modifications in order to access the 1 PPS signal. Again you’ll find most of the
details for a number of commercially available GPS units on David’s page.
Figure 4: Offset Using 1 PPS GPS hardware; time in hours on horizontal (X) axis; deviation in
microseconds on the vertical (Y) axis.
And when the GPS PPS signal is added in we can see from Fig 4 that the time accuracy is
improved another order of magnitude. Note that the zero clock value is offset to 20
microseconds in Fig 4 and thus the fluctuations are less than +/-5 microseconds within this 24
hour period. Not bad at all for a prototype costing less than 100 dollars!
Things to Do with NTP?
As you’ve already seen NTP is widely used to simply ‘keep time’ on computers and devices
that are connected to a network. This in itself is a very commendable use and enables lowcost devices like the Raspberry PI to operate as a normal computer, but without a need for a
hardware clock.
But as we’ve just seen you can do better than simply keeping time. There are many other
things you can do when you know how to accurately synchronize two physically separated
devices.
Audio Synchronization & Precedence Effect
Human ears are quite sensitive to both timing and the loudness of sounds. Where one sound is
louder than a second the human ear is insensitive to delays of 10’s of milliseconds, but where
the sounds are close in amplitude and volume it can detect delays of as little as 1-2
milliseconds. Sometimes these delays are important - for example in Hi-Fidelity stereo
reproduction it is critical to preserve such delays as these characterize the underlying music.
Now consider examples where we wish to reproduced audio at different locations linked by a
network connection. One example is a PA system in a football stadium.
The Football Stadium
Consider a large football stadium with PA speakers linked by network. Now for most
locations one speaker will dominate and the precedence effect will merge the sounds from
other speakers into a single sound.
However if someone is seated at a mid-point between two or more speakers they hear equal
volumes from each speaker and are sensitive to time lags between the speakers. In these areas
it is important that the speakers are synchronized to within 10 milliseconds of each other or
supporters could hear echoes in the speaker system. As you’ve seen above this is something
that can be achieved quite easily using NTP with local time servers.
The VOIP Teleconference
Every wondered how one of those Internet teleconferencing systems manages to allow 10, 20
even more people to listen in and participate without all sorts of horrible audio delays,
speakers talking over one another and getting mixed together. Did you ever wonder how this
magic worked? Well now you should be able to figure it out!
Yes NTP and its first cousin PTP (precision time protocol) are often behind such magic on the
Internet. As we’ve seen it may not be sufficient to rely on the global NTP networks as these
can only provide accuracies of some 10s of milliseconds. Typically a local time-server will be
established – often at the central location that hosts the teleconference – and local clients are
primarily synchronized to this central time source.
Wireless Speakers
Now here is a good question – why has nobody actually made a pair of separate wireless
speakers? It seems like a no-brainer when you are fiddling with all of those wires to hook up
your home cinema speakers.
Well a lot of the problems stem from the issue of synchronizing the two speakers. As was
commented above, if one audio source is much louder then your ears don’t hear the distant
echo; but when both sounds have very similar volumes the ear can be extremely discerning
and may notice time differences of the order of 1-2 milliseconds. Now while this is
achievable it requires having a local time server and it is difficult to have an ‘out of the box’
solution that doesn’t require the consumer to start configuring NTP for their local network.
Something More Complex
Now I mentioned earlier that you should buy a few Raspberry PIs and try something nice and
complex. Well how about an internet protocol sound system [4]. Yes it is all there in great
detail, how to make your own 5.1 or even 7.1 audio system based on NTP. And straight out of
Microsoft Labs!
The only question I have is, if this works well how come Microsoft have not actually built
some and offered them for sale? I know that I really want one of these!
IEEE Precision Time Protocol (PTP)
The Precision Time Protocol (PTP) is a protocol used to synchronize clocks throughout a
computer network. On a local area network, it achieves clock accuracy in the submicrosecond range, making it suitable for many applications in computer-operated
measurement and control systems.
PTP was first defined in the IEEE 1588-2002 standard, entitled "Standard for a Precision
Clock Synchronization Protocol for Networked Measurement and Control Systems" and
published in 2002. In 2008 a revised standard, IEEE 1588-2008 was released. The new
standard, known also as PTP Version 2, enables improved accuracy, increased precision and
added robustness to PTP, but is not backwards compatible with the original 2002 version. It is
important to be aware of this incompatibility when specifying PTP based systems!
The IEEE 1588 standard was specifically designed to fill a niche that is not well served by
either NTP or GPS. It is designed for locally networked systems requiring greater levels of
accuracy than can be attained using NTP on its own. Now while NTP can be enhanced using
the GPS 1-PPS signal, many applications that cannot bear the additional cost of a GPS
receiver at each node, or in many applications GPS signals are simply not accessible. One
very widespread usage of IEEE 1588 has been for electric grid control systems when it has
been largely adopted as the underlying time synchronization protocol.
A related standard of interest to many CE engineers is IEEE 802.1AS-2011 which is part of
the IEEE Audio Video Bridging (AVB) group of standards. This specifies a profile for the use
of IEEE 1588-2008 to provide time synchronization over a local area network (as defined by
IEEE 802.1Q). In particular, 802.1AS defines how IEEE 802.3 (Ethernet), IEEE 802.11 (WiFi), and coordinated shared networks like MoCA can all be parts of the same timing domain.
The Society of Motion Picture and Television Engineers is also developing a new broadcast
synchronization standard based on IEEE 1588.
You can find out more about PTP at http://ieee1588.nist.gov/
References
[1]
[2]
[3]
[4]
“The Network Time Protocol (NTP) Distribution.” [Online]. Available:
http://www.eecis.udel.edu/~mills/ntp/html/index.html#info. [Accessed: 07-Jun-2013].
K. Marzullo, “Maintaining the time in a distributed system: An example of a looselycoupled distributed service.,” Dissertation Abstracts International Part B: Science and
…, 1985.
“Network Time Synchronization Research Project.” [Online]. Available:
http://www.eecis.udel.edu/~mills/ntp.html. [Accessed: 07-Jun-2013].
T. Blank, B. Atkinson, M. Isard, J. Johnston, and K. Olynyk, “An internet protocol
(IP) sound system,” in 117th AES Convention, San Francisco, 2004, pp. 1–17.