2004.11_The Pulse-Time Synchronization on Local Networks.pdf

KNOW HOW

NTP

The Pulse

Time servers are the pulse of the network. Without them, databases fail to syn-

chronize or NFS exports become confused. To avoid this, admins set up a

service that provides a standardized time to the machines on the network.

BY JÖRG REITTER

depend on consistent timekeeping; fail-

ure to provide this could be disastrous.

In contrast, isolated networks may be

able to live with slight discrepancies, or

even without a time source. However,

there are a few pitfalls.

prefer to attach a time source to the

LAN. Of course you still need to config-

ure your firewall (after all, you will not

want external users accessing your time

source), but at least admins are not

exposed to the whims of a public time-

server on the Internet, or the vagaries of

a WAN link.

There are two interesting time sources

in Europe. One is the MSF transmitter in

the UK (see the box MSF, [2]), which

transmits its time code over most of

Northern Europe. The second is an

enhanced transmitter based in Allouis,

near Paris, France, and known as TDF

(see the box TDF Explored, [3]), which

has a range of 3500 kilometers and is

thus ideal for enterprises with offices all

over Europe. Other stratum 0 signals are

available, such as DCF77 in Germany,

WWV (Fort Collins, USA), CHU (Ottawa,

important service on a network, they

are unlikely to think of the time ser-

vice. In reality, it is. Without uniform

time, network services can experience

massive problems. Database synchro-

nization is bound to fail if the

timestamps are out of sync. Backups are

canceled because the files are dated

some time in the future.

Encryption and authentication soft-

ware also requires consistent network

time. Some operating systems also strug-

gle if the network time is too far out of

sync. NetWare will refuse to run if it

does not have a time client on the local

machine, but Linux admins have a

choice of approaches.

There is a fine, but important distinc-

tion between using an Internet-based

time server, or a special receiver attached

directly to a local machine, as the time

source. Admins need to take the applica-

tions into consideration. Many of them

may depend on consistent timekeeping,

and there are very few that completely

ignore the time.

Your LAN time server does not neces-

sarily need access the Internet to find a

time source. There are many manufac-

turers of radio or GPS time receivers

worldwide.

Distributed networks, where databases

are synchronized across WAN links,

A Sense of Timing

The latter category of network should at

least have a tool that queries a time

server on the Internet and acts as the

time source for the other hosts. Linux

uses the Network Time Protocol (NTP)

[1] to access the time source in this case.

However, synchronizing across the Inter-

net is fraught with danger, and it

involves quite a lot of administrative

work. Admins need to be aware of

potential security loopholes, and imple-

ment appropriate firewall rules.

To make things easier, IT staff might

MSF

MSF60 is the radio signal which broadcasts

the national time standard for the UK. The

MSF service broadcast from Rugby is the

principal means of disseminating the UK

national standards of time and frequency

which are maintained by the National Physi-

cal Laboratory. Transmission is 24 hours a

day, and the carrier frequency is maintained

at 60 kHz to within 2 parts in 1012.

The name MSF is based on an international

convention. The letter M stands for UK, along

with G or 2. SF is thought to indicate Stan-

dard Frequency but no one can remember if

this is true any longer. 60 indicates the trans-

mitter’s frequency (60 kHz).

The standard time and frequency service is

funded by the Department of Trade and

Industry (DTI) as part of its provision of time

and frequency measurement standards in

the UK. The maintenance and development

of those standards is carried out by the

National Physical Laboratory (NPL), with the

MSF 60 kHz signal being transmitted from

the Rugby Radio Station by BT Radio Engi-

neering Services under contract from NPL.

The signal is generated at Rugby using the

atomic clocks and time code equipment pro-

vided by NPL. The broadcast signal is

monitored and controlled relative to the

national time standard at the NPL site in

Teddington.

The transmitter is at 52° 22’ N, 1° 11’W. The

estimated equivalent monopole radiated

power (EMRP) is 15 kW and the horizontal

radiation pattern is substantially omnidirec-

tional. The signal provides a field strength

exceeding 100 µV/m throughout the UK,

and it can be received throughout most of

north and west Europe. The main reasons for

reception difficulties are local interference

and screening due to nearby metalwork

such as that found within office blocks.

November 2004

www.linux-magazine.com

Time synchronization in local networks

I f you ask people which is the most

NTP

KNOW HOW

Canada), JJY (Japan), BPM (China), etc.

See [4] for a list in greater detail.

erences multiple sources over a relatively

long period. NTP adjusts major devia-

tions from network time in small steps.

This prevents services from becoming

unreliable because the time adjustment

was too much for them to handle. Luck-

ily, all this effort means more accuracy,

as NTP can judge the stability of the

local time server based on the accuracy

of its sources.

NTP uses a multilevel approach with

so-called strata to categorize time

sources by accuracy. GPS time sources,

DCF77 or TDF receivers are the most

accurate and are assigned to stratum 0,

as they always keep the right time. A

local server that queries a stratum 0 time

source will automatically be assigned to

the next highest level, i.e. Stratum 1

(NTP primary).

Clock Around the Rock

Unfortunately, MSF and TDF are of little

use to enterprises that operate globally.

In this case, admins need a little help

from satellites in orbit around the world.

Clocks that can receive the signal trans-

mitted by the Global Positioning System

(see box GPS Explored) provide the best

approach to consistent timekeeping in

globally distributed networks.

However, admins should be aware that

civil applications based on this US mili-

tary project are subject to political

influence, and that the service may be

discontinued at any time. Until an equiv-

alent civilian time source, the EU Galileo

project, goes online, there is no real

alternative to GPS.

Figure 1: Underneath the UFO, the Linum Neo-

clock 4X [8] has two antennas and either a DCF77

or TDF receiver. The receiver is attached to the

serial port at a distance of up to 100 meters using

an extension lead, and accesses the long wave

transmitters to query the exact time.

which is typically used by Windows

2000/XP is easy to set up and manage.

The issue that many admins face in het-

erogeneous networks is convincing the

Linux and Microsoft protocols to talk to

each other.

NTP and SNTP both communicate

over TCP/UDP port 123, querying exter-

nal sources such as a stable time source

in your data center or a timeserver on

the Internet. Clients can either query the

time themselves or receive server multi-

casts, broadcasts or manycasts.

While SNTP simply queries a time

source and adjusts the system clock,

NTP has a more precise approach. It ref-

Setting the System and

Real Time Clocks

The Network Time Protocol is part of

any distribution. The current source

packages are available from [1]. It is not

really important whether you use “ntp”

or “xntp”. According to the ntp.org FAQ ,

the difference is that “xntp” refers to pro-

tocol version 3 or earlier, and “ntp”

refers to version 4 or higher. The x in

“xntp” originally stood for experimental.

This article refers to NTPv4, and this is

why the commands and init scripts all

start with “ntp”.

Before starting the configuration

process, admins should set the system

clock as accurately as possible. If the

NTP daemon notes a deviation of more

than 1000 seconds when initializing, it

will not attempt to synchronize. You can

use the “date” tool to set the date and

time:

Taking Timekeeping to the PC

Every computer has a built-in clock with

a promising name: Real Time Clock.

Unfortunately CMOS or hardware clocks

are hardly renowned for their accuracy.

They often deviate by a number of sec-

onds per day. For this reason, the kernel

also has a software clock. The so-called

system clock counts the number of sec-

onds since 1.1.1970. When a computer

boots, the hardware clock is accessed

and the time is passed to the system

clock, which then handles time and time

zone management.

Of course, you could use cron to syn-

chronize the clocks on your network, but

there is a far simpler server-based

approach. The time server distributes the

time to all the computers on the network

and acts as a reference. NTP (Network

Time Protocol, RFC 1305, [5]) is the rec-

ommended transport protocol in

homogeneous Linux-Unix networks, as

any Unix variant will support it. If you

additionally need to synchronize Win-

dows 2000/XP machines, you have a

choice. Microsoft systems typically use

SNTP (Simple Network Time Protocol,

RFC 2030, [5]), which will work with

NTP.

TDF Explored

The TDF (Télé Distribution Francaise) time

signal is provided by the world’s most accu-

rate atomic clock, the cesium fountain clock.

The clock is operated by the LPTF – Labora-

toire Primaire du Temps et des Frequences

(now renamed BNM – SYRTE) in the “Obser-

vatoire de Paris”, France. This international

institution, which has its headquarters in

Paris, France, helps coordinate the official

world time (UTC). France Inter, a commercial

broadcaster, maintains the infrastructure.

The TDF signal is modulated on top of a nor-

mal radio transmitter. Decoding the time

signal receiver-side is quite complex, and

this makes the devices more expensive.

However, it could be worth paying a little

more, if you have offices all over Europe. TDF

has a transmitter power of 2000 kW and

covers the whole of Europe with the excep-

tion of northern Scandinavia.

date -s "2004-10-20 10:00:00"

This command sets the date to October

20 2004, and the system time to 10.00

a.m. Admins can use the “hwclock”

clock program to set the system clock to

UTC:

Protocols Compared

NTP is the typical timekeeping protocol

on Linux and other Unix variants. As

you might expect, NTP has a whole

bunch of options. The SNTP protocol,

hwclock --set --utc U

--date "2004-01-20 12:00:00"

If you use the “--localtime” option

instead of “--utc”, the clock will use the

local time instead. This is only recom-

www.linux-magazine.com November 2004

KNOW HOW

NTP

mended in smaller networks, and

assumes that none of your services syn-

chronizes across a WAN link.

and linuxmedialabs.com is in the USA.

The last server in the list, 127.127.1.0, is

the local clock, which is typically an

unstable time source. This it is your only

hope if the Internet connection goes

down. Incidentally, the Time Service

Department of the US Navy is the official

time source for the both the US Depart-

ment of Defense and the Global

Positioning System.

Configuring the Time

Daemon

The time daemon, “ntpd”, ensures that

all the hosts on the network have the

same time. To do this, it uses a kernel

function (among other things) which

transfers the system time to the hard-

ware clock. You can view this as follows:

Getting the Drift

Deviations of the system clock from the

time source over a period of time are

referred to as drift. The NTP daemon will

log the history of a slow drift in one or

the other direction. The logfile can reside

anywhere on a system. You need to

make sure that the drift file is not around

before the NTP daemon starts up, other-

wise the daemon will simply quit. Most

distros store the drift file somewhere

below /var/lib/ntp . You can configure

this parameter in your ntp.conf file, for

example:

adjtimex --print

Figure 2: The Hopf GPS card FG6039GPS [9] feeds

satellite time to your network. You need to attach

an external antenna to the card to receive the

GPS signal.

The ntpd daemon performs this task

automatically, offloading this responsi-

bility from the admin user. After

completing these preparatory steps, you

can start configuring stratum 2 servers in

your /etc/ntp.conf file. Stratum 2 servers

are preferable in a test scenario as stra-

tum 1 servers have to serve a lot of

clients.

Responsible admins should not forget

to inform the administrator of an Inter-

net based time server that they will

accessing the time service it provides.

The list of public NTP servers at [1] pro-

vides a list with the email addresses:

Depending on the deviation of the local

system, and the latency of your LAN

packages, NTP may take a few minutes

to start synchronizing and elect a

sys.peer .

The NTP configuration for your other

Linux servers is similar. The difference is

that the other Linux servers on your net-

work will use the local time source as a

reference:

driftfile /var/lib/ntp/ntp.drift

Getting the drift is time-consuming and

typically takes several days or weeks.

The local NTP daemon repeatedly com-

pares times to be able to keep the right

time despite a broken connection to the

Internet NTP server.

server time.linuxmag.local

server 127.127.1.0

driftfile /var/lib/ntp/ntp.drift

server ntp2a.mcc.ac.uk

server ntp1.linuxmedialabs.com

server ntp.saard.net

server ntp1.tuxfamily.net

server 127.127.1.0

The NTP package includes several useful

options for adnvanced management and

special situations. The monitoring fea-

ture, and the support for crypto keys,

may be of interest. See the FAQ [1] for

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: