[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#448871: Should give us the option of syncing time



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





Reply to: