From: Dave Taht <dave.taht@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: codel@lists.bufferbloat.net
Subject: Re: [Codel] fp sqrt vis int sqrt?
Date: Fri, 4 May 2012 12:04:54 -0700 [thread overview]
Message-ID: <CAA93jw6vjJvtdYyiWDJhgZ3ze-g=e=VjBYDeCMg5+Qt=MbXxXg@mail.gmail.com> (raw)
In-Reply-To: <1336157416.3752.378.camel@edumazet-glaptop>
On Fri, May 4, 2012 at 11:50 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2012-05-04 at 11:39 -0700, Dave Taht wrote:
>> Heh. I'd only gotten as far as
>>
>> #include <stdio.h>
>> #include <math.h>
>> main() {
>>
>>
>>
>>
>>
>> before your mail arrived.
>
> Yep, so maybe we can use a precomputed table of 25 values (100 bytes),
> using the reciprocal trick to get precise integer approximation.
>
> (interval/sqrt(count)).
>
> So that control_law() has no multiply or divide to do, just a lookup in
> the array.
>
> Then for count values >= 25, either we can afford an error less than 20%
> using the q->sqrt_count maintained in // with q->count, either we
> compute the reciprocal each time we change q->count.
We end up with cumulative error and we are trying to match in inverse
tcp's behavior on the flip side, over a variety of RTTs and bandwidths
ranging from nearly 0 to 10GigE....
table[sch->len] in size doesn't bother me much. Except that I'd hoped
to get away with ~ infinite queue length and not bother with that.
More noise presumably helps with randomization down to some point to
where we fall below kernel time granularity.
> (cost : one divide + int_sqrt() call )
> plus one multiply in control_law()
>
> Not sure we need to be ultra precise.
I'd like to toss these concepts back over the wall to kathie to simulate.
I think seeing the oscillation in queue length with just int_sqrt vs
fp sqrt would be fun too, but I'm weird that way.
Late this evening I'll have time to incorporate the progress so far
today (thx for the cleanups and help!!!) and I'll try to get another
patch out late tonight. Unless you beat me to it.
About the only thing left bugging me is the netlink interface.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
next prev parent reply other threads:[~2012-05-04 19:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-04 15:11 Dave Taht
2012-05-04 15:14 ` Jim Gettys
2012-05-04 15:19 ` Dave Taht
2012-05-04 15:26 ` Jim Gettys
2012-05-04 15:56 ` Eric Dumazet
2012-05-04 17:23 ` Dave Taht
2012-05-04 17:43 ` Dave Taht
2012-05-04 17:44 ` Dave Taht
2012-05-04 17:46 ` Dave Taht
2012-05-04 23:42 ` Kathleen Nichols
2012-05-05 0:01 ` Dave Taht
2012-05-04 17:47 ` Eric Dumazet
2012-05-04 18:26 ` Eric Dumazet
2012-05-04 18:39 ` Dave Taht
2012-05-04 18:50 ` Eric Dumazet
2012-05-04 19:04 ` Dave Taht [this message]
2012-05-04 19:16 ` Eric Dumazet
2012-05-05 8:14 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/codel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw6vjJvtdYyiWDJhgZ3ze-g=e=VjBYDeCMg5+Qt=MbXxXg@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=codel@lists.bufferbloat.net \
--cc=eric.dumazet@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox