2. NTP
This section last updated: $Date: 2002/07/14 18:45:31 $If you know that all your machines are already in sync, then you can skip to the synctest.
Doors requires that the system clocks of all machines are in sync, ideally to within 5ms. You are free to use any software product which accomplishes this. I chose the standard NTP v4 distribution, and so I will now describe how to install this under Linux 2.4. This installation of NTP v4 consists of a server, which contains the 'reference' clock, and many clients (for Linux and Win32).
I actually had a great deal of difficulty getting NTP v4 up and running. There are thousands of options, and the log output is not very helpful. However, NTP v4 does perfectly synchronise system clocks. Hopefully these instructions will guide you through it painlessly.
2.1. NTP Server
You may already have the NTP server installed - type 'locate ntpd | grep bin' . If you see ntpd, skip to ntp.conf.
Download http://www.eecis.udel.edu/~mills/ntp/ntp4/ntp-4.1.72.tar.gz. To install the NTP server enter the following commands:
cd /usr/src tar xfz /your/path/to/ntp-4.1.72.tar.gz cd ntp-4.1.72 ./configure --enable-LOCAL-CLOCK make make install |
If all went well, create the file /etc/ntp.conf with the following contents:
# IP address of our NTP 'reference' server. # In this case, it's a special IP address, 127.127.t.u, where t is the # clock 'driver' and u is which instance of that driver (0 to 3). # Our driver is '1', which is the Undisciplined Local Clock server 127.127.1.1 # LCL, local clock fudge 127.127.1.1 stratum 12 # increase stratum # Our log file. Note that a minimum of messages are logged to this file. Many # other messages are logged to the system log files, eg. /var/log/daemon.log, # /var/log/sys.log or /var/log/messages logfile /var/log/ntp.log |
This conf file sets the NTP server to be an 'Undisciplined Local Clock'. This means that it does not have it's own 'upstream' server, and is not synchronised with global UTC. Providing that all machines on our LAN are in sync, we don't care what the globally acknowledged UTC is, so this setup is fine for our purposes.
Next start the NTP daemon by issuing /usr/local/bin/ntpd. If all goes well, your log files should contain something like the following:
==> /var/log/daemon.log <== May 21 21:57:38 landau ntpd[771]: ntpd 4.1.71 Thu Jan 24 13:59:39 CET 2002 (1) May 21 21:57:38 landau ntpd[771]: signal_no_reset: signal 13 had flags 4000000 May 21 21:57:38 landau ntpd[771]: precision = 15 usec May 21 21:57:38 landau ntpd[771]: kernel time discipline status 0040 ==> /var/log/ntp.log <== 21 May 22:00:55 ntpd[771]: time set 0.000000 s 21 May 22:00:55 ntpd[771]: synchronisation lost |
Add the NTP Daemon to your start-up scripts, so that it is started every time the server is booted. Note that the log message "time set 0.000000 s" is this 'undisciplined' server reporting that it has just synchronised with it's reference clock (ie. local clock).
2.2. Linux Client
Every machine (but not the NTP server) requires an NTP client. On each Linux client enter the following commands:
cd /usr/src tar xfz /your/path/to/ntp-4.1.72.tar.gz cd ntp-4.1.72 ./configure make make install |
If all went well, create the file /etc/ntp.conf with the following contents (change 192.168.0.1 to the IP address of your NTP Server):
# IP address of our NTP 'reference' server. # We use iburst mode which puts a greater load on the server, but which speeds # up initial synchronisation from XXX seconds to about 30 seconds. server 192.168.0.1 iburst # This file records the drift of the local clock relative to the reference # clock. This file may NOT be a symbollic link. driftfile /etc/ntp.drift # Our log file. Note that a minimum of messages are logged to this file. Many # other messages are logged to the system log files, eg. /var/log/daemon.log, # /var/log/sys.log or /var/log/messages logfile /var/log/ntp.log |
Next start the NTP daemon by issuing
/usr/local/bin/ntpd -g |
If all goes well, your log files should contain something like the following:
==> /var/log/daemon.log <== May 22 14:36:49 (none) ntpd[133]: ntpd 4.1.71 Mon Nov 5 20:04:25 CET 2001 (1) May 22 14:36:49 (none) ntpd[133]: signal_no_reset: signal 13 had flags 4000000 May 22 14:36:49 (none) ntpd[133]: precision = 6 usec May 22 14:36:49 (none) ntpd[133]: kernel time discipline status 0040 May 22 14:36:49 (none) ntpd[133]: frequency initialized 36.486 from /etc/ntp.drift ==> /var/log/ntp.log <== 22 May 14:41:10 ntpd[133]: time reset -7178.251341 s 22 May 14:41:10 ntpd[133]: kernel time discipline status change 41 22 May 14:41:10 ntpd[133]: synchronisation lost |
 | If your Linux machine is a DHCP client, see the above note. |
| The NTP v4 distribution uses some esoteric algorithms which do things like gradually 'slur' your system clock into sync. Do not expect NTP to instantly sync your clock on startup, like the popular Win32 clients do. Instead, let it run for at least 2 hours before hacking the config files. |
If you don't see the above output, see ntp-troubleshooting. Otherwise, add /usr/local/bin/ntpd -g to your start-up scripts, so that it is started every time the client is booted.
2.3. synctest
Now we test that all Linux machines are in sync by making them all play a simple melody together. To do this enter the following commands:
cd /usr/src/doors-0.1.1/midifileplayer/src/doorsx/midifileplayer/server/adamlib make synctest # If you know your /dev/sequencer2 is working then play the melody using your # MIDI hardware: ./synctest # If you're not sure, then use the PC speaker: su root ./synctest -b |
You should now hear an endlessly looped rising scale. Repeat the above on all Linux machines which are supposed to be synchronised (including the NTP server). All machines should play the melody in sync. The PC speaker method produces more accurate results, because sound is generated almost instantaneously - your MIDI hardware might take a few milliseconds to actually produce audible sound.
2.4. Win32 Client
No Doors devices exist for Win32 machines yet. However, you can still use your Win32 machine to run the User Interface (written in Java/Swing). If so, then this machine also needs to be synced with the NTP server. This is very easy to do:
Download and install AboutTime from http://www.arachnoid.com/abouttime/index.html.
Click the Time Hosts tab >> Add. Enter the host name/IP address of your NTP server. Protocol should be SNTP. Click OK. The new entry should be top in the list.
Click the Time Servers tab and disable all the servers.
Click the Control/Time Client tab. Click Set Time. The activity log should display the following:
Connecting to ntp-server using SNTP. Resolved address for ntp-server (192.168.0.1). Received time (ping 60 ms), error 54 ms. New time: Wednesday, May 22, 2002 15:26:54.
2.5. NTP Troubleshooting
Make sure no ntpd processes are running, and then execute the following command:
/usr/local/bin/ntpd -gd |
This will produce output similar to the following (where an error has occured):
create_sockets(123) interface <lo> OK interface <eth0> OK bind() fd 4, family 2, port 123, addr 0.0.0.0, flags=1 bind() fd 5, family 2, port 123, addr 127.0.0.1, flags=0 bind() fd 6, family 2, port 123, addr 172.16.224.253, flags=1 init_io: maxactivefd 6 resolving landau report_event: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010) auth_agekeys: at 1 keys 1 expired 0 peer_clear: at 2 assoc ID 0 newpeer: 172.16.224.253->172.16.224.250 mode 3 vers 4 poll 6 10 flags 0x201 0x1 ttl 0 key 00000000 transmit: at 6 172.16.224.253->172.16.224.250 mode 3 receive: at 6 172.16.224.253<-172.16.224.250 mode 4 code 1 packet: bad header 020 |
I think the "bad header 020" message means that the server returned a response that the client didn't like. The client, you see, is not very forgiving - if a server is over 1000 seconds out of sync with the client, the client decides this is a 'bogus' server and refuses to synchronise with it. Use the -g option to force the client to ignore this first sanity check.
Furthermore, if the server fails to synchronise with it's own upstream server, it will decide that it is no longer a valid NTP server, and therefore not authorised to deliver the time to any clients - instead delivering a "bad header 020" message. This happens if your NTP server has problems starting up. Check /var/log/ntp.log on the server for any errors.
More NTP troubleshooting information is available at http://www.eecis.udel.edu/~ntp/.