tcp-ip@ucbvax.ARPA (08/18/85)
From: jsq%tzec.UTEXAS@ut-sally.ARPA (John Quarterman)
After the incident when dcn1's time was eight hours off, Dave Mills
suggested that the client should check with a neighbor or two before
believing what any host says about the time. I have followed this up
and written a time client program for 4.2BSD which allows letting an
arbitrary number of hosts vote on the time. It also can connect using
either TCP or UDP, since the set of really accurate hosts which run
time servers using either protocol is very small.
The program is available by anonymous ftp from ut-sally.ARPA (soon to
be sally.UTEXAS.EDU) as ~ftp/pub/netdate.c and ~ftp/pub/netdate.8.
Here are a couple of usage examples from the manual entry:
EXAMPLE
The most accurate hosts are named first in each example.
/etc/netdate -l 30 udp dcn-gateway tcp neighbor
_D_c_n-_g_a_t_e_w_a_y is a hypothetical host which usually keeps time
accurate to within milliseconds of Coordinated Universal
Time, but may occasionally be eight hours off. _N_e_i_g_h_b_o_r is
a neighbor of the local host which keeps time with moderate
accuracy. The time will be set to that of _d_c_n-_g_a_t_e_w_a_y if
that and _n_e_i_g_h_b_o_r agree to within thirty seconds, else it
will not be set at all. This is almost good enough for most
circumstances, but won't do when the local host's time is
known to be wrong (e.g., after a long downtime or a bad
crash) and must be set to something. If one of the hosts
named is inaccurate or not responding, there is a problem.
/etc/netdate -l 30 udp dcn-gateway tcp neighbor neighbor2
Only two of the three hosts named must agree on the time.
The time will still be set (to that of the first neighbor),
even if _d_c_n-_g_a_t_e_w_a_y is far off as long as the two neighbors
agree. This is probably good enough for most cases. One
can arbitrarily gerrymander the vote for more insurance (and
less clarity), as in the following example.
[end of excerpt]tcp-ip@ucbvax.ARPA (08/20/85)
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA> When voting on the time, another piece of information which almost everyone has at their disposal is the reference date of certain files which must be accessed when the system is run. This can be used as an error check against the propogation of bad times (which has happenned occasionally on our local network). Network (or other) times preceeding the file date are probably bogus.
tcp-ip@ucbvax.ARPA (08/20/85)
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Date: Tue, 20 Aug 85 12:19:13 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
When voting on the time, another piece of information which almost
everyone has at their disposal is the reference date of certain files
which must be accessed when the system is run. This can be used as an
error check against the propogation of bad times (which has happenned
occasionally on our local network). Network (or other) times preceeding
the file date are probably bogus.
But what happens if somebody spazzes and warps MIT-MC 9 months into the
future. (It has happened before.) What if one of the files you check
against was created by such a time-warped machine? Indeed, the normal
case will be caught by your probable-bogosity meter, but when the
baseline is bogus, then what?tcp-ip@ucbvax.ARPA (08/20/85)
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Date: Tue, 20 Aug 85 12:19:13 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
When voting on the time, another piece of information which almost
everyone has at their disposal is the reference date of certain files
which must be accessed when the system is run. This can be used as an
error check against the propogation of bad times (which has happenned
occasionally on our local network). Network (or other) times preceeding
the file date are probably bogus.
But what happens if somebody spazzes and warps MIT-MC 9 months into the
future. (It has happened before.) What if one of the files you check
against was created by such a time-warped machine? Indeed, the normal
case will be caught by your probable-bogosity meter, but when the
baseline is bogus, then what? What about systems who can't access the
filesystem until the time is known?tcp-ip@ucbvax.ARPA (08/21/85)
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
Date: Tue, 20 Aug 85 13:39 EDT
From: David C. Plummer in disguise <DCP at SCRC-QUABBIN.ARPA>
To: Christopher C. Stacy <CSTACY at MIT-MC.ARPA>,
jsq%tzec.UTEXAS at UT-SALLY.ARPA
cc: TCP-IP at SRI-NIC.ARPA
Re: voting on the time
In-Reply-To: <[MIT-MC.ARPA].618951.850820.CSTACY>
Date: Tue, 20 Aug 85 12:19:13 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
When voting on the time, another piece of information which almost
everyone has at their disposal is the reference date of certain files
which must be accessed when the system is run. This can be used as an
error check against the propogation of bad times (which has happenned
occasionally on our local network). Network (or other) times preceeding
the file date are probably bogus.
But what happens if somebody spazzes and warps MIT-MC 9 months into the
future. (It has happened before.) What if one of the files you check
against was created by such a time-warped machine? Indeed, the normal
case will be caught by your probable-bogosity meter, but when the
baseline is bogus, then what?
Yeah, that's a pretty awful state to get into. Part of the
recovery strategy for a file system which was active with
the wrong time should be to locate (important) files which
may have been written with the wrong date and fix them to
sometime in the past, perhaps the shutdown time.
The file date hack is not intended as a recovery mechanism
for bad times. It is merely another source of information
that tells you when things appear inconsistant. Some human
who knows better can come along and consult a sundial or
something to decide which time is really correct.
Also, the file date check is only useful for fairly gross
times. It might be appropriate to use it when booting the
system to see if tomorrow is yesterday, but I wouldn't
bother trying to use it for second (or minute) accuracy.
What about systems who can't access the filesystem until the time
is known?
That's what "almost everyone" in my statement refers to. You obviously
can't use this hack if you can't read the file directory information.tcp-ip@ucbvax.ARPA (08/21/85)
From: jsq%tzec.UTEXAS@ut-sally.ARPA (John Quarterman) My assumption was that checking the time of independent hosts should be more dependable than checking anything on the local host, especially after a bad crash or operator error. There are many other things which netdate could do. Once it's chosen what it thinks is the set of most accurate hosts, it could take the RMS average, toss out anything which deviates too far, average again, and use the result as the time. It could poll the whole set of accurate hosts several times when averaging, or it could just poll the single most accurate host several times and average. It could notice the network latency and adjust for it. I may add some of these things (preferably after wiser heads remark on which ones would be most useful). What I wanted to start with was something simple which could be depended upon to reject truly bogus times.
tcp-ip@ucbvax.ARPA (08/21/85)
From: Richard Johnson <raj@uci-icsa> > There are many other things which netdate could do. Once it's chosen > what it thinks is the set of most accurate hosts, it could take the > RMS average, toss out anything which deviates too far, average again, > and use the result as the time. My program takes a simple average, not RMS. However, the rest of the description is exactly what it does. > It could notice the network latency and adjust for it. I do this also. ------------------------------------------------------------------------ Richard Johnson raj@uci.arpa (ARPA) UCI ICS Research Systems Manager ucbvax!ucivax!raj (UUCP)