Re: ntpdate-like functionality in ntpd
On Wed, Feb 18, 2015 at 12:30 PM, Sven-Göran Bergh wrote: >> 1. Run "something" such as ntpdate which sets an approximate time >> quickly, but that also terminates quickly if there is no network >> connectivity or NTP server does not respond >> 2. As soon as this is done, launch ntpd and leave it running in the >> background. If I am not wrong, Busybox's ntpd can be left running in >> the background mostly unattended and will just do its stuff when the >> network and NTP server is available. >> 3. Then proceed with the rest of the initialisation. >> >> So far the missing part of the puzzle is 1 :-) > > > As I understand it you are looking for q&d solution. In that case wouldn't > just something like this do the trick? > > busybox timeout -t 2 busybox ntpd -nqp > > Without a server reply ntpdate will not save you anyway. In fact this solution is not "dirty". It does exactly what was asked for: it tries to set the time, but aborts if this can't be done in alotted time. And in the old Unix tradition, both parts of the task (syncing time and aborting on timeout) are done with two separate tools. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
2015-02-18 12:30 GMT+01:00 Sven-Göran Bergh : > > On 02/18/2015 12:04 PM, Guillermo Rodriguez Garcia wrote: >> >> 2015-02-18 11:16 GMT+01:00 Denys Vlasenko : >>> >>> On Wed, Feb 18, 2015 at 10:10 AM, Guillermo Rodriguez Garcia >>> wrote: 2015-02-18 9:45 GMT+01:00 Denys Vlasenko : > > On Wed, Feb 18, 2015 at 8:38 AM, Guillermo Rodriguez Garcia > wrote: >> >> I ended up using rdate on this particular case but I think it would be >> nice if ntpd could be used as described. >> >> I don't have enough knowledge about the protocol to know what are the >> implications of not waiting for the burst mode to end for option -q >> (as per Miroslav's patch). Can anyone shed some light? > > > Time will be set after 2 reply packets from one peer. > Which normally would take 2-3 seconds. > > If network is down or NTP server is not replying at all, > "ntpd -q" can still wait indefinitely. I guess the same is true > for ntpdate. In my tests, if the network is down, or the server is unreachable or does not reply, ntpdate returns almost immediately with an error message. > > If you plan for your machines to not hang at boot time > in such a case, you need to think (and test) booting > with network down. Can you provide any recommendations about this? What would be the best way to run ntpd to make sure it does not hang at boot if the network is down and/or the NTP server does not reply, but still sync the time as soon as the network is back up and/or the NTP server becomes available? >>> >>> >>> I do not try to set time super-duper-early. I don't see a particular >>> reason >>> why that is important. >> >> >> This depends on the actual application but there are many cases where >> you want at least an "approximate" time being set before the user >> application is run. For example for applications that need to schedule >> work. >> >> Note that it is not a matter of accuracy -- if there is no hardware >> RTC or the battery is dead, then the time will be completely wrong. >> >> The following would be ideal: >> >> 1. Run "something" such as ntpdate which sets an approximate time >> quickly, but that also terminates quickly if there is no network >> connectivity or NTP server does not respond >> 2. As soon as this is done, launch ntpd and leave it running in the >> background. If I am not wrong, Busybox's ntpd can be left running in >> the background mostly unattended and will just do its stuff when the >> network and NTP server is available. >> 3. Then proceed with the rest of the initialisation. >> >> So far the missing part of the puzzle is 1 :-) > > > As I understand it you are looking for q&d solution. In that case wouldn't > just something like this do the trick? Why q&d? This is the typical (and intended) usage of ntpdate -- get the time approximately right before starting ntpd. > > busybox timeout -t 2 busybox ntpd -nqp > > Without a server reply ntpdate will not save you anyway. Uhm, yes I guess that's a feasible workaround but it feels a bit hackish. It would be nice if this could be done without this kind of trick :) Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
On 02/18/2015 12:04 PM, Guillermo Rodriguez Garcia wrote: 2015-02-18 11:16 GMT+01:00 Denys Vlasenko : On Wed, Feb 18, 2015 at 10:10 AM, Guillermo Rodriguez Garcia wrote: 2015-02-18 9:45 GMT+01:00 Denys Vlasenko : On Wed, Feb 18, 2015 at 8:38 AM, Guillermo Rodriguez Garcia wrote: I ended up using rdate on this particular case but I think it would be nice if ntpd could be used as described. I don't have enough knowledge about the protocol to know what are the implications of not waiting for the burst mode to end for option -q (as per Miroslav's patch). Can anyone shed some light? Time will be set after 2 reply packets from one peer. Which normally would take 2-3 seconds. If network is down or NTP server is not replying at all, "ntpd -q" can still wait indefinitely. I guess the same is true for ntpdate. In my tests, if the network is down, or the server is unreachable or does not reply, ntpdate returns almost immediately with an error message. If you plan for your machines to not hang at boot time in such a case, you need to think (and test) booting with network down. Can you provide any recommendations about this? What would be the best way to run ntpd to make sure it does not hang at boot if the network is down and/or the NTP server does not reply, but still sync the time as soon as the network is back up and/or the NTP server becomes available? I do not try to set time super-duper-early. I don't see a particular reason why that is important. This depends on the actual application but there are many cases where you want at least an "approximate" time being set before the user application is run. For example for applications that need to schedule work. Note that it is not a matter of accuracy -- if there is no hardware RTC or the battery is dead, then the time will be completely wrong. The following would be ideal: 1. Run "something" such as ntpdate which sets an approximate time quickly, but that also terminates quickly if there is no network connectivity or NTP server does not respond 2. As soon as this is done, launch ntpd and leave it running in the background. If I am not wrong, Busybox's ntpd can be left running in the background mostly unattended and will just do its stuff when the network and NTP server is available. 3. Then proceed with the rest of the initialisation. So far the missing part of the puzzle is 1 :-) As I understand it you are looking for q&d solution. In that case wouldn't just something like this do the trick? busybox timeout -t 2 busybox ntpd -nqp Without a server reply ntpdate will not save you anyway. Brgds /S-G ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
2015-02-18 11:16 GMT+01:00 Denys Vlasenko : > On Wed, Feb 18, 2015 at 10:10 AM, Guillermo Rodriguez Garcia > wrote: >> 2015-02-18 9:45 GMT+01:00 Denys Vlasenko : >>> On Wed, Feb 18, 2015 at 8:38 AM, Guillermo Rodriguez Garcia >>> wrote: I ended up using rdate on this particular case but I think it would be nice if ntpd could be used as described. I don't have enough knowledge about the protocol to know what are the implications of not waiting for the burst mode to end for option -q (as per Miroslav's patch). Can anyone shed some light? >>> >>> Time will be set after 2 reply packets from one peer. >>> Which normally would take 2-3 seconds. >>> >>> If network is down or NTP server is not replying at all, >>> "ntpd -q" can still wait indefinitely. I guess the same is true >>> for ntpdate. >> >> In my tests, if the network is down, or the server is unreachable or >> does not reply, ntpdate returns almost immediately with an error >> message. >> >>> >>> If you plan for your machines to not hang at boot time >>> in such a case, you need to think (and test) booting >>> with network down. >> >> Can you provide any recommendations about this? What would be the best >> way to run ntpd to make sure it does not hang at boot if the network >> is down and/or the NTP server does not reply, but still sync the time >> as soon as the network is back up and/or the NTP server becomes >> available? > > I do not try to set time super-duper-early. I don't see a particular reason > why that is important. This depends on the actual application but there are many cases where you want at least an "approximate" time being set before the user application is run. For example for applications that need to schedule work. Note that it is not a matter of accuracy -- if there is no hardware RTC or the battery is dead, then the time will be completely wrong. The following would be ideal: 1. Run "something" such as ntpdate which sets an approximate time quickly, but that also terminates quickly if there is no network connectivity or NTP server does not respond 2. As soon as this is done, launch ntpd and leave it running in the background. If I am not wrong, Busybox's ntpd can be left running in the background mostly unattended and will just do its stuff when the network and NTP server is available. 3. Then proceed with the rest of the initialisation. So far the missing part of the puzzle is 1 :-) BR, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
On Wed, Feb 18, 2015 at 10:10 AM, Guillermo Rodriguez Garcia wrote: > 2015-02-18 9:45 GMT+01:00 Denys Vlasenko : >> On Wed, Feb 18, 2015 at 8:38 AM, Guillermo Rodriguez Garcia >> wrote: >>> I ended up using rdate on this particular case but I think it would be >>> nice if ntpd could be used as described. >>> >>> I don't have enough knowledge about the protocol to know what are the >>> implications of not waiting for the burst mode to end for option -q >>> (as per Miroslav's patch). Can anyone shed some light? >> >> Time will be set after 2 reply packets from one peer. >> Which normally would take 2-3 seconds. >> >> If network is down or NTP server is not replying at all, >> "ntpd -q" can still wait indefinitely. I guess the same is true >> for ntpdate. > > In my tests, if the network is down, or the server is unreachable or > does not reply, ntpdate returns almost immediately with an error > message. > >> >> If you plan for your machines to not hang at boot time >> in such a case, you need to think (and test) booting >> with network down. > > Can you provide any recommendations about this? What would be the best > way to run ntpd to make sure it does not hang at boot if the network > is down and/or the NTP server does not reply, but still sync the time > as soon as the network is back up and/or the NTP server becomes > available? I do not try to set time super-duper-early. I don't see a particular reason why that is important. I start and run ntpd just the same as I run any other daemon. I use this method: http://git.busybox.net/busybox/tree/examples/var_service/README http://git.busybox.net/busybox/tree/examples/var_service/ntpd/README ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
2015-02-18 9:45 GMT+01:00 Denys Vlasenko : > On Wed, Feb 18, 2015 at 8:38 AM, Guillermo Rodriguez Garcia > wrote: >> I ended up using rdate on this particular case but I think it would be >> nice if ntpd could be used as described. >> >> I don't have enough knowledge about the protocol to know what are the >> implications of not waiting for the burst mode to end for option -q >> (as per Miroslav's patch). Can anyone shed some light? > > Time will be set after 2 reply packets from one peer. > Which normally would take 2-3 seconds. > > If network is down or NTP server is not replying at all, > "ntpd -q" can still wait indefinitely. I guess the same is true > for ntpdate. In my tests, if the network is down, or the server is unreachable or does not reply, ntpdate returns almost immediately with an error message. > > If you plan for your machines to not hang at boot time > in such a case, you need to think (and test) booting > with network down. Can you provide any recommendations about this? What would be the best way to run ntpd to make sure it does not hang at boot if the network is down and/or the NTP server does not reply, but still sync the time as soon as the network is back up and/or the NTP server becomes available? Best, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
On Wed, Feb 18, 2015 at 8:38 AM, Guillermo Rodriguez Garcia wrote: > I ended up using rdate on this particular case but I think it would be > nice if ntpd could be used as described. > > I don't have enough knowledge about the protocol to know what are the > implications of not waiting for the burst mode to end for option -q > (as per Miroslav's patch). Can anyone shed some light? Time will be set after 2 reply packets from one peer. Which normally would take 2-3 seconds. If network is down or NTP server is not replying at all, "ntpd -q" can still wait indefinitely. I guess the same is true for ntpdate. If you plan for your machines to not hang at boot time in such a case, you need to think (and test) booting with network down. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
Hi all,
I ended up using rdate on this particular case but I think it would be
nice if ntpd could be used as described.
I don't have enough knowledge about the protocol to know what are the
implications of not waiting for the burst mode to end for option -q
(as per Miroslav's patch). Can anyone shed some light?
Thank you,
Guillermo
2015-01-29 13:47 GMT+01:00 Miroslav Lichvar :
> On Tue, Jan 27, 2015 at 07:27:18PM +0100, Guillermo Rodriguez Garcia wrote:
>> Is there a way to make ntpd work just like ntpdate (just use the first
>> response received to set the time)? This is to set the approximate
>> time at boot as quickly as possible before starting other time sensitive
>> services.
>
> By default, ntpdate actually makes 4 measurements before it sets the
> clock, but older versions didn't wait between queries so it appeared
> like there was only one. With current versions, which use 2s polling
> interval, it takes at least 6 seconds.
>
>> The closest I can get is ntpd -nqp but this seems to need
>> 5 valid samples in order to set the time.
>
> It seems it waits for the burst mode to end before it tries to select
> a source. I'm not sure that is necessary.
>
> --- a/networking/ntpd.c
> +++ b/networking/ntpd.c
> @@ -1084,7 +1084,7 @@ select_and_cluster(void)
>
> num_points = 0;
> item = G.ntp_peers;
> - if (G.initial_poll_complete) while (item != NULL) {
> + while (item != NULL) {
> double rd, offset;
>
> p = (peer_t *) item->data;
>
>
> With this change ntpd -q will set the clock with just two samples,
> that's about 1-2 seconds total time.
>
> --
> Miroslav Lichvar
--
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
On Tue, Jan 27, 2015 at 07:27:18PM +0100, Guillermo Rodriguez Garcia wrote:
> Is there a way to make ntpd work just like ntpdate (just use the first
> response received to set the time)? This is to set the approximate
> time at boot as quickly as possible before starting other time sensitive
> services.
By default, ntpdate actually makes 4 measurements before it sets the
clock, but older versions didn't wait between queries so it appeared
like there was only one. With current versions, which use 2s polling
interval, it takes at least 6 seconds.
> The closest I can get is ntpd -nqp but this seems to need
> 5 valid samples in order to set the time.
It seems it waits for the burst mode to end before it tries to select
a source. I'm not sure that is necessary.
--- a/networking/ntpd.c
+++ b/networking/ntpd.c
@@ -1084,7 +1084,7 @@ select_and_cluster(void)
num_points = 0;
item = G.ntp_peers;
- if (G.initial_poll_complete) while (item != NULL) {
+ while (item != NULL) {
double rd, offset;
p = (peer_t *) item->data;
With this change ntpd -q will set the clock with just two samples,
that's about 1-2 seconds total time.
--
Miroslav Lichvar
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
On Thu, Jan 29, 2015 at 11:14 AM, Guillermo Rodriguez Garcia wrote: > Does this warrant a separate applet? > > I thought that perhaps a command line option to the existing ntpd applet > would be enough -- but I am no expert in this field. Having sntp would be more compatible than adding a bbox-specific option to ntpd. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
Does this warrant a separate applet? I thought that perhaps a command line option to the existing ntpd applet would be enough -- but I am no expert in this field. Guillermo 2015-01-29 11:03 GMT+01:00 Denys Vlasenko : > On Tue, Jan 27, 2015 at 11:01 PM, Guillermo Rodriguez Garcia > wrote: > > Hello Denys, > > > > El martes, 27 de enero de 2015, Denys Vlasenko > > > escribió: > > > >> On Tue, Jan 27, 2015 at 7:27 PM, Guillermo Rodriguez Garcia > >> wrote: > >> > Hello all, > >> > > >> > Is there a way to make ntpd work just like ntpdate (just use the first > >> > response received to set the time)? This is to set the approximate > >> > time at boot as quickly as possible before starting other time > sensitive > >> > services. > >> > > >> > The closest I can get is ntpd -nqp but this seems to need > >> > 5 valid samples in order to set the time. > >> > >> Would it work for you if you simply background it > >> and let it do its work in parallel with the rest of the boot? > > > > > > Not in this particular case; I don't need time to be extremely accurate > but > > I need "approximate" time to be set as quickly as possible before > starting > > other services. That is (was) the typical use case of ntpdate: set the > time > > quickly to an approximate value, then let ntpd do it's job. > > I think the best way to achieve this is to implement a sntp applet > > http://linux.die.net/man/8/sntp > > It can reuse ntpd's code. > > -- > vda > -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
Good idea +1 Le jeu. 29 janv. 2015 11:04, Denys Vlasenko a écrit : > On Tue, Jan 27, 2015 at 11:01 PM, Guillermo Rodriguez Garcia > wrote: > > Hello Denys, > > > > El martes, 27 de enero de 2015, Denys Vlasenko > > > escribió: > > > >> On Tue, Jan 27, 2015 at 7:27 PM, Guillermo Rodriguez Garcia > >> wrote: > >> > Hello all, > >> > > >> > Is there a way to make ntpd work just like ntpdate (just use the first > >> > response received to set the time)? This is to set the approximate > >> > time at boot as quickly as possible before starting other time > sensitive > >> > services. > >> > > >> > The closest I can get is ntpd -nqp but this seems to need > >> > 5 valid samples in order to set the time. > >> > >> Would it work for you if you simply background it > >> and let it do its work in parallel with the rest of the boot? > > > > > > Not in this particular case; I don't need time to be extremely accurate > but > > I need "approximate" time to be set as quickly as possible before > starting > > other services. That is (was) the typical use case of ntpdate: set the > time > > quickly to an approximate value, then let ntpd do it's job. > > I think the best way to achieve this is to implement a sntp applet > > http://linux.die.net/man/8/sntp > > It can reuse ntpd's code. > > -- > vda > ___ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
On Tue, Jan 27, 2015 at 11:01 PM, Guillermo Rodriguez Garcia wrote: > Hello Denys, > > El martes, 27 de enero de 2015, Denys Vlasenko > escribió: > >> On Tue, Jan 27, 2015 at 7:27 PM, Guillermo Rodriguez Garcia >> wrote: >> > Hello all, >> > >> > Is there a way to make ntpd work just like ntpdate (just use the first >> > response received to set the time)? This is to set the approximate >> > time at boot as quickly as possible before starting other time sensitive >> > services. >> > >> > The closest I can get is ntpd -nqp but this seems to need >> > 5 valid samples in order to set the time. >> >> Would it work for you if you simply background it >> and let it do its work in parallel with the rest of the boot? > > > Not in this particular case; I don't need time to be extremely accurate but > I need "approximate" time to be set as quickly as possible before starting > other services. That is (was) the typical use case of ntpdate: set the time > quickly to an approximate value, then let ntpd do it's job. I think the best way to achieve this is to implement a sntp applet http://linux.die.net/man/8/sntp It can reuse ntpd's code. -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
Hello Denys, El martes, 27 de enero de 2015, Denys Vlasenko escribió: > On Tue, Jan 27, 2015 at 7:27 PM, Guillermo Rodriguez Garcia > > wrote: > > Hello all, > > > > Is there a way to make ntpd work just like ntpdate (just use the first > > response received to set the time)? This is to set the approximate > > time at boot as quickly as possible before starting other time sensitive > > services. > > > > The closest I can get is ntpd -nqp but this seems to need > > 5 valid samples in order to set the time. > > Would it work for you if you simply background it > and let it do its work in parallel with the rest of the boot? > Not in this particular case; I don't need time to be extremely accurate but I need "approximate" time to be set as quickly as possible before starting other services. That is (was) the typical use case of ntpdate: set the time quickly to an approximate value, then let ntpd do it's job. (Note that ntpdate is deprecated now; alternatives for each typical ntpdate use case are described here: https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate) One alternative (which is supported by busybox) would be rdate. However If ntpd can be made to behave like ntpdate, I would rather use that to avoid depending on two different servers (since rdate does not speak NTP). Guillermo -- Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: ntpdate-like functionality in ntpd
>I doubt having the boot process continue with the wrong time would be >acceptable. File timestamps will be wrong until the background process >completes. You really want to wait synchronously for an answer. That, of course, is not the tool-maker's call. The _system_ designer gets to decide how important early timestamping is. In some cases I could think of, not at all! (Pre-pivot on a ROFS, etc.) -- Jim ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
On Tue, Jan 27, 2015 at 10:26:47PM +0100, Denys Vlasenko wrote: > On Tue, Jan 27, 2015 at 7:27 PM, Guillermo Rodriguez Garcia > wrote: > > Hello all, > > > > Is there a way to make ntpd work just like ntpdate (just use the first > > response received to set the time)? This is to set the approximate > > time at boot as quickly as possible before starting other time sensitive > > services. > > > > The closest I can get is ntpd -nqp but this seems to need > > 5 valid samples in order to set the time. > > Would it work for you if you simply background it > and let it do its work in parallel with the rest of the boot? I doubt having the boot process continue with the wrong time would be acceptable. File timestamps will be wrong until the background process completes. You really want to wait synchronously for an answer. Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ntpdate-like functionality in ntpd
On Tue, Jan 27, 2015 at 7:27 PM, Guillermo Rodriguez Garcia wrote: > Hello all, > > Is there a way to make ntpd work just like ntpdate (just use the first > response received to set the time)? This is to set the approximate > time at boot as quickly as possible before starting other time sensitive > services. > > The closest I can get is ntpd -nqp but this seems to need > 5 valid samples in order to set the time. Would it work for you if you simply background it and let it do its work in parallel with the rest of the boot? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
ntpdate-like functionality in ntpd
Hello all, Is there a way to make ntpd work just like ntpdate (just use the first response received to set the time)? This is to set the approximate time at boot as quickly as possible before starting other time sensitive services. The closest I can get is ntpd -nqp but this seems to need 5 valid samples in order to set the time. Thank you, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
