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.
Rick [*] For those who care, it works roughly like this:One or more polls are sent from the client to each of the servers. The servers respond with their ideas of the correct UTC time. There are details in the protocol that allow a server to indicate that it's idea of time may be suspect -- if none of those flags are set, the servers idea of time is assumed to be correct. This becomes the timestamp that the client takes from that server. The uncertainty in the timestamp is thus proportional to the round-trip time to the server and back. The timestamp with the smallest uncertainty is chosen and applied with some technical corrections to the client's clock.
So a long network delay indicates a large uncertainty in the resultant timestamp.
Admittedly, an uncertainty of even a few minutes may be better than nothing... But that should be a matter for the user to decide.
On Nov 1, 2007, at 1:59 PM, Joey Hess wrote:
Frans Pop wrote:This basically means that the current time-out is just too long for practical use as is.An alternative option could be to make it possible to cancel the action,just like we do for looking for a DHCP server.Yep, all network-facing progress bars in d-i need a cancel button. See other thread. ;-) Currently the timeout is just a standard tcp connection timeout, or insome cases, maybe several if it fails to connect to one server and triesanother one.It should be easy enough to make this operation cancelable. It would be possible to enforce some shorter timeout (this is done in the code that runs hwclock, which can hang on some hardware, for example), but I don'tfeel that's the right choice in network operations since a network operation can legitimately take an arbitrary time to succeed. -- see shy jo