On Nov 1, 2007, at 7:02 PM, Joey Hess wrote:
rdate, as used by the installer, uses SNTP.
A... (again) This was added fairly recently. Interesting.
The point remains. The uncertainty in the time from the server is
proportional (or worse) to the network delay.
Not with SNTP it isn'
Rick Thomas wrote:
> 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.
rdate, as used by the installer, uses SNTP.
> The point r
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 i
On Nov 1, 2007, at 3:06 PM, Jim Paris 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.
Unless it's slow becuase of something like the init
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 corre
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.
Unless it's slow becuase of something like the initial DNS lookup.
-jim
--
To UNSUBSCRI
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
block 448871 436497
thanks
The clock-setup progress bar cannot safely be made cancelable until this
bug in newt is fixed. To make the progress bar cancelable, clock-setup
would need to use PROGRESS INFO or PROGRESS_STEP periodically to poll
for a return code indicating cancel was hit. But both of
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
Frans Pop <[EMAIL PROTECTED]> writes:
> reassign 448871 clock-setup 0.92
> severity 448871 important
> thanks
>
> On Thursday 01 November 2007, Kumar Appaiah wrote:
>> I just tried one of the daily build netboot installer, and the only
>> problem I faced is that it just waited at the ntp syncing s
reassign 448871 clock-setup 0.92
severity 448871 important
thanks
On Thursday 01 November 2007, Kumar Appaiah wrote:
> I just tried one of the daily build netboot installer, and the only
> problem I faced is that it just waited at the ntp syncing stage. I
> don't know whether it times out, but I j
Processing commands for [EMAIL PROTECTED]:
> reassign 448871 clock-setup 0.92
Bug#448871: Should give us the option of syncing time
Bug reassigned from package `debian-installer' to `clock-setup'.
> severity 448871 important
Bug#448871: Should give us the option of syncing time
Package: debian-installer
Severity: normal
Dear Debian Installer team,
First of all, I reside in a place where all access to internet is
through HTTP proxy, but we have a Debian mirror which is accessible
from inside without proxy.
I just tried one of the daily build netboot installer, and the o
13 matches
Mail list logo
