[lug] NIST servers and RDATE

[Judah Levine]

Hello,
  Thank you for sending me the source code for RDATE. I have looked
at it and also done some testing here, and here are some results.

   1. The Linux version of RDATE does NOT use broadcast packets as
I suggested in my earlier comments. It sends a request only to the
host that you specify. This is different from the UNIX version of
RDATE, which sends a broadcast packet to an entire network that you 
specify and not just to a single host. Please ignore my comments
with respect to broadcast packets, since they are not relevant to
Linux folks.

   2. The Linux version of RDATE sends a request to tcp/ip port 37
on the server. Our servers support this type of request, but it is
relatively expensive because of the overhead of setting up a tcp/ip 
connection for a response message that will only contain 4 bytes
(a 32-bit binary time value). The same time service is also supported
on udp/ip port 37, and I would recommend that the authors of RDATE
change to code to use udp/ip instead of tcp/ip. The response format
will be the same, but the overhead on the servers and the network
will be much lower. You can see an example program that uses udp/ip
in directory /pub/daytime on any of our servers. Look for file
udp_time_client.c. This is effectively the same program as rdate,
except that it uses udp/ip.

   3. Since tcp/ip connections are expensive to set up, most of
our servers cannot handle more than about 500 tcp/ip requests per 
second, and the busiest ones are running close to that level most
of the time. I would suggest that you try to use the existing RDATE
program with our other servers. The following table contains some
suggestions based on your location:

	East Coast and Central Time zone

		    nist1.aol-va.truetime.com  205.188.185.33
		    nist1-dc.glassey.com       216.200.93.8

	Central and Mountain zones

		    utcnist.colorado.edu       128.138.140.44

	Pacific
		    nist1.datum.com		63.149.208.50
		    nist1.aol-ca.truetime.com   207.200.81.113

We operaate all of these servers, and the messages are directly
traceable to UTC(NIST).

I hope that these suggestions will fix the problems.


Judah Levine
Time and Frequency Division
NIST Boulder