Ahhh... So the installer time-setter uses rdate, not NTP? A wise
choice, now that I think about it. Much lighter weight protocol, and
the client is much *much* smaller.
Infact, rdate doesn't even use SNTP. It just asks the server for the
time of day (one second resolution) and puts it into the local
clock. No sanity checks; no "this may be unreliable" flags; no magic
to take account of network delays; nothing.
The point remains. The uncertainty in the time from the server is
proportional (or worse) to the network delay. If the network delay
is long, the user should have the option of which source of time to
trust.
Rick
On Nov 1, 2007, at 4:02 PM, Joey Hess wrote:
Rick Thomas wrote:
Using ntp to set the time should be a short operation. If it
takes a long
time, the validity of the time that results is in question -- by
virtue of
the process[*] being used.
Careful, you're confusing SNTP and NTP. You're also
oversimplifying. NTP
is very good at correcting for latency and other issues and is capable
of accuracies of a few milliseconds over the network. (Far less than
typical round trip times.) SNTP, which rdate uses, can also correct
for
latency, but is supposed to be less accurate. How much less, I'm not
sure, but it's not going to be in the order of minutes of innaccuracy,
and I'd be suprised if it was in the order of seconds of innaccuracy.
--
see shy jo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]