Old but useful! Long used PC components are assembled in new boxes:
- Baby AT board with ISA bus
- i486 25/33/50 MHz and 8/16 MB RAM
- IDE and RS232 interface card
- IDE harddisk 200 MB / 1.2 GB
- NE2000 compatible Ethernet adapter

This hardware ist fast enough to run the NTP deamon with a radio clock receiver attached. The RS232 interface interrupt latency is acceptable.

We started with the slow 25 MHz 8 MB 200 MB machine. Not much later followed the 33 MHz 8 MB 200 MB machine. After a while my retired PC (50 MHz 16 MB 1.2 GB) was reactivated to test run NTP version 4.

See the page about our NTP subnet for more actual information or view pictures of our NTP hosts.

For the low cost PC hardware Linux is a natural choice as operating system. First we installed the distribution of Red Hat Software, Inc. via the Net (FTP or NFS), but other distributions are as good as this. Currently the server is running under SuSE Linux 5.2 from CD-ROM.

Dave Mills' system clock stabilization software is already built into Linux. In the current version it should work correctly.

The ntpd software distribution is prepared for Linux. The current version will install smoothly, though the former versions required minor patches for the DCF77 receiver.

To start without problems we took the patched xntp distribution from Stephan Seidl (no longer available). He installed the NTP service in the university computing centre (ZIH) of Dresden Technical University (TU Dresden). At last we installed xntp3-5.93-export with the generic parse clock driver compiled in and all others excluded (no problems).

First time we set up our campus NTP service following Stephan Seidl's excellent guide. Unfortunately, this page is no longer available. You may install and setup a NTP client according to another recipe.

Our configuration file was adapted to our network addresses and our DCF77 receiver. The time offset between the DCF77 pulse and the system time is 271 milliseconds due to the receiver and the slow 25 MHz PC. Stephan Seidl must have had an i486 50 MHz.

A correction of the system clock tick is required. The tickadj value of 10004 was found out by trial, using Frank Kardel's special raw DCF77 receiver deamon dcfd. After it was run for a while, the value was computed from the ntp.drift file. There is a Perl script named calc_tickadj in the xntp distribution.

The remaining drift value was about 12 ppm. The offset between true time and system time was in a range of +5/-6 milliseconds with about 70% within ±3 milliseconds. That's a nice result for such a cheap system.

The xntpd daemon is started and halted automatically by a start/stop script at the end of the boot sequence or at the beginning of the halt sequence, respectively. The same script is used to halt and restart the daemon to trim the log file to smaller size.

Shortly after the hour an entry in /etc/crontab calls: 'clock -wu' This will set the internal (hardware) clock to correct time. The -u is needed since our system clock is running at UTC (not local time).

In the early morning hours of every day cron runs a script to process the xntpd statistics files which are written at the end of each day. Actual graphics files are written to a WWW directory and old files are deleted or shrinked.

For our purposes a low cost DCF77 receiver is by far sufficient. There are very low cost kits, but the soldering work doesn't pay. In 1993 I purchased an 'Expert mouseCLOCK' passive raw DCF77 receiver. The software delivered with it is good, but not needed for NTP.

'Passive' means that there is no power supply. The receiver is attached to a RS232 port and powered by positive DTR and negative RTS line voltage. 'Raw' means that there is no processor. The secondly time signals are received at the RxD line and interpreted by software.

The Fachhochschule owns another DCF77 receiver, an 'IGEL:clock'. It is passive and raw too, but it comes with an additional RS232 adapter. Usually raw DCF77 signals are received at a rate of 50 bps. The adapter transforms the signals to a shorter duration to be received at 1200 bps.

The intended effect of the adapter may be to get more precise time signals. Unfortunately, in our configuration this effect is missed, perhaps because the PC hardware is too slow. In any case, our NTP server runs more accurately if only the receiver without the adapter is used.

Moreover the 'IGEL:clock' receiver turned out to actually be an 'Expert mouseCLOCK'. It is now used without the adapter on our second server.

If you intend to purchase a receiver of your own you should have all relevant information to make the right choice. Here are some about our receivers and their vendors.