Hochschule Augsburg
Network Services
NTP Subnet
NTP subnet imagemap
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
© B. Erdlenbruch
Legal Information