Hochschule Augsburg
Network Services
NTP Subnet
This sketch of our NTP subnet shows the relationships
between the various hosts. Lines with one arrowhead point
from the client to the server in a relationship, lines with
arrowheads at both ends mean peer relationships.
The yellow circles in the top row depict external primary
(stratum 1) servers we refer to. Clicking on one of them will
link to the WWW page of the respective operator.
The blue rounded rectangles are our DCF77 receivers (stratum 1).
Clicking on them will display a status report of this
radio clock by calling the ´ntpq -c ps´ command.
The yellow rectangles in the middle row are the NTP reference
(stratum 2) servers for our campus network, and the ones in the
bottom row are the distribution (stratum 3) servers. Clicking on
their name will display a peer status report of this host by calling
the ´ntpq -c pe´ command. Clicking on the yellow background
around the name links to a statistics page about the local loop
and the servers the host refers to.
Structure
Structuring our campus subnet we followed the recommendations in
'Configuring NTP and Setting up a NTP Subnet'.
Four hosts (the minimum number for robustness is three)
each refer to three different servers in the internet.
They peer with each other, and two of them have a radio
clock attached. Some other hosts (used mainly as file
and application servers) refer to the four internal NTP
reference servers and are peeked by several clients.
There should be two primary servers and one secondary
(buddy) server per campus reference server. In Germany,
there are no public secondary (stratum 2) servers and
only a few
primary. So we need them all, though they are peering
each other and may form disadvantageous loops. Fortunately,
as primary servers, they are normally ruled by primary time
sources (GPS, DCF77, PTB). Three foreign primary servers are
used, giving a total of (4 times 3) 12 different external
servers.
Actually,
our DCF77 receivers should enable us to participate
in the world wide NTP network as a primary reference.
But these devices are rather primitive and unprecise.
So we use them only as a backup time source,
automatically chosen by the NTP daemon when our
connection to the Internet is down or bad (which
sometimes happens). This is accomplished by forcing
down the radio clocks to stratum 1, the same stratum
as that of the external servers. Our reference servers
are therefore at stratum 2.
By trial we found out that
our NTP servers have a clock offset of ±7 milliseconds
(sigma 3 ms) when controlled by one of our radio clock receivers.
Controlled by the external references, the servers perform
better even if our Internet connection is not good.
Clock offset is ±2 to 3 milliseconds (sigma 0.5 to 1 ms),
which is a fairly good value. Now we are able to offer them
internally and externally as buddy servers for other campus
networks.
The distribution servers referring to the reference servers are
at stratum 3 and still have a clock offset of ±7 milliseconds
(sigma 2 ms). They are peeked by several clients at boot time and
regularly, assigning those clients to stratum 4.
NTP broadcast but no multicast is installed so far.
Reference Servers
Three of the reference servers (tick, tock, tack)
are simple PCs running Linux. Resting on one desk,
two of them even share monitor and keyboard, and
their radio clock receivers
lie adjacently on the desktop.
Despite of this, they are still viewed as
backing up each other, and in fact they are.
There is not much to do for these hosts.
Normally servicing NTP, only a few network
daemons are held active.
The fourth host (pps) is an IBM RS/6000 type 7044 model 270
with four 375 MHz Power3 processors, 3 GB RAM,
two 100 MBps Ethernet adapters, and an UPS.
It is our SAP® R/3® database and application server
but fairly fast and should hardly notice any
NTP workload.
When power supply is interrupted, tick, tock and tack are
down immediately and have to boot after return of voltage.
But the same is true for all workstations, so that pps has
no more load and can perform NTP steadily. It has an
uninterruptible power supply (UPS) attached, but is cut off
the network since the switches are down. Several hours the
NTP deamon could survive with only the hardware clock, but
the UPS battery will reach not nearly as long. After a while,
pps will go down too, as already the rest of our NTP subnet.
In practice, there is no problem at all. All works very well
and makes a pretty stable and robust NTP network.
Distribution Servers
We have PCs, Apples and Unix machines (mostly Suns)
in our campus Network. The so called Computing Centre
(Rechenzentrum, RZ) serves the whole campus, but the
computer science department has a network of its own,
including servers and administration.
Most of the PCs run some sort of MS Windows. The PCs
available for students are collected in one domain
controlled by a Samba server running on the main campus
server. The other PCs are in two other domains controlled
by a MS Windows NT server (compactus) and a Linux/Samba
server (imperium). These machines are running the NT
version 3 of xntpd and the Linux version 4 of ntpd,
respectively.
bilbo is a fast SUN, fairly able to serve all Unix machines
of the computer science department. It will cope with NTP
service too.
tuck is a former NT workstation, reactivated and now running
fine under Linux. It even has good crystal and hardware clock
and therefore is a good redundant (backup) NTP distribution
server. Sometimes it has to be busy as HTTP server (for the
pages you are just viewing and some private pages), but that's
not so often.
kim is an old (and slow) RS/6000-220 used for application
development and as a FDC server. It is used as one more
(backup) NTP distribution server as it has to run all time
in any case as a SAP® R/3® FDC subsystem gateway.
spider is the main campus server, a fast SUN V880 operated
by the computing center, running nearly all network services,
just including NTP service. This machine is the campus
NTP broadcast server.
Clients
The MS Windows clients synchronize at boot time by the
'net time \\compactus /set /yes' command.
During runtime, the old MS Windows NT clients use the
TimeSync service to regularly poll the servers
compactus and kim or other ones. The TimeSync
configuration file is pulled from tick by HTTP.
The MS Windows 2000 or XP clients synchronize regularly
with the here extended (using SNTP)
'net time ...' command.
The Unix machines today have the ntpd daemon
included in their operating system. So we only
have to copy a ntp.conf file and start the
daemon.
Apple machines are synchronized as far as
OS X is installed.
Network
We have a direct Internet connection for some time now.
Our router connects to the German Research Network G-WiN.
Speed is good under todays conditions, and connection
is interrupted only sometimes for a (usually) short while.
The reference servers tick, tock and tack each have a 10 MBit
NIC, but are attached to a switch on a 100 MBit line, crossing
two switches to the Internet router. pps has even two 100 MBit
NICs and as well two switches to the Internet router.
The Windows NT server compactus and the Linux servers imperium and
tuck each have a 100 MBit NIC, Sun / Solaris server bilbo has
two. kim will stay at 10 MBit, attached to the same switch as
tick, tock and tack. As the central campus server, spider has a
1 GBit NIC.
Network congestion sometimes occurs when our multimedia folks
are demonstrating their bandwidth-exhausting applications.
We (and you) have to be patient.
2004-12-16