[arch-projects] [netcfg] [PATCH 3/4] Lower latency in timeout_wait

Jouke Witteveen j.witteveen at gmail.com
Tue Jul 3 07:49:29 EDT 2012


On Tue, Jul 3, 2012 at 2:49 AM, Henrik Hallberg <henrik at k2h.se> wrote:
> On Tue, Jul 03, 2012 at 01:08:34AM +0200, Jouke Witteveen wrote:
>> On Mon, Jul 2, 2012 at 11:07 PM, Henrik Hallberg <henrik at k2h.se>
>> wrote:
>> > --- src/globals | 3 ++- 1 file changed, 2 insertions(+), 1
>> > deletion(-)
>> >
>> > diff --git a/src/globals b/src/globals index 436334a..62cce3e 100644
>> > --- a/src/globals +++ b/src/globals @@ -100,10 +100,11 @@ function
>> > checkyesno() { # $2...: condition command function timeout_wait() {
>> > local timeout="$1" +    (( timeout *= 10 )) shift while ! eval "$*";
>> > do (( timeout-- > 0 )) || return 1 -        sleep 1 +        sleep
>> > 0.1 done return 0 } -- 1.7.11.1
>> >
>>
>> I don't think this is such a good idea. This saves less than .45
>> seconds on average per timeout_wait (old expected waste: .5s, new
>> expected waste: .05s, added polling overhead).
>
> If you assume uniform distribution, yes. However, this is not the case.
> For the cases which I fixed in patch 4, the first eval (no sleep at all)
> was sufficient. (Then, of course, the sleep time does not matter). If
> not, the second always was.
>
>> If you want to do it > this way, you should probably decouple ((
>> timeout-- > 0 )) into (( timeout -= .1 )) and (( timeout > 0 )).
>
> I could have sworn that I tested floating point calculations in bash,
> failed, and found texts claiming that it was not possible without e.g.
> `bc`. TIL.

Shame on me, you're right of course :-P.

>> Why would we try to make a bash script super fast?
>
> Why keep unnescessary waiting times in? I'm happier to boot and have my net
> connected by the time my shell is. than waiting a little longer. With
> this and DHCP_OPTIONS='--noarp', it takes four seconds instead of
> twelve.

Well, they're not entirely unnecessary.

Because it's a rather harmless, small patch I threw it in, but I
hereby declare that I oppose the next suggestion to upgrade to 1/100th
second polling ;-).


More information about the arch-projects mailing list