From: Jarek Poplawski <jarkao2@gmail•com>
To: Patrick McHardy <kaber@trash•net>
Cc: Antonio Almeida <vexwek@gmail•com>,
Stephen Hemminger <shemminger@vyatta•com>,
netdev@vger•kernel.org, davem@davemloft•net, devik@cdi•cz,
Eric Dumazet <dada1@cosmosbay•com>,
Vladimir Ivashchenko <hazard@francoudi•com>
Subject: Re: [PATCH iproute2] Re: HTB accuracy for high speed
Date: Wed, 3 Jun 2009 07:40:49 +0000 [thread overview]
Message-ID: <20090603074049.GA5254@ff.dom.local> (raw)
In-Reply-To: <4A2620FD.8030708@trash.net>
On Wed, Jun 03, 2009 at 09:06:37AM +0200, Patrick McHardy wrote:
> Jarek Poplawski wrote:
>> Jarek Poplawski wrote, On 06/02/2009 11:37 PM:
>> ...
>>
>>> I described the reasoning here:
>>> http://permalink.gmane.org/gmane.linux.network/128189
>>
>> The link is stuck now, so here is a quote:
>
> Thanks.
>
>> Jarek Poplawski wrote, On 05/17/2009 10:15 PM:
>>
>>> Here is some additional explanation. It looks like these rates above
>>> 500Mbit hit the design limits of packet scheduling. Currently used
>>> internal resolution PSCHED_TICKS_PER_SEC is 1,000,000. 550Mbit rate
>>> with 800byte packets means 550M/8/800 = 85938 packets/s, so on average
>>> 1000000/85938 = 11.6 ticks per packet. Accounting only 11 ticks means
>>> we leave 0.6*85938 = 51563 ticks per second, letting for additional
>>> sending of 51563/11 = 4687 packets/s or 4687*800*8 = 30Mbit. Of course
>>> it could be worse (0.9 tick/packet lost) depending on packet sizes vs.
>>> rates, and the effect rises for higher rates.
>
> I see. Unfortunately changing the scaling factors is pushing the lower
> end towards overflowing. For example Denys Fedoryshchenko reported some
> breakage a few years ago when I changed the iproute-internal factors
> triggered by this command:
>
> .. tbf buffer 1024kb latency 500ms rate 128kbit peakrate 256kbit
> minburst 16384
>
> The burst size calculated by TBF with the current parameters is
> 64000000. Increasing it by a factor of 16 as in your patch results
> in 1024000000. Which means we're getting dangerously close to
> overflowing, a buffer size increase or a rate decrease of slightly
> bigger than factor 4 will already overflow.
>
> Mid-term we really need to move to 64 bit values and ns resolution,
> otherwise this problem is just going to reappear as soon as someone
> tries 10gbit. Not sure what the best short term fix is, I feel a bit
> uneasy about changing the current factors given how close this brings
> us towards overflowing.
I completely agree it's on the verge of overflow, and actually would
overflow for some insanely low (for today's standards) rates. So I
treat it's as a temporary solution, until people start asking about
more than 1 or 2Gbit. And of course we will have to move to 64 bit
anyway. Or we can do it now...
Btw., I've some doubts about HFSC; it's really different than others
wrt. rate tables/time accounting, and these PSCHED_TICKS look only
like an unnecesary compatibility; it works OK with usecs and doesn't
need this change now, unless I miss something. So maybe we would
simply stop using common psched_get_time() for it, and only do a
conversion for qdisc_watchdog_schedule() etc.?
Thanks,
Jarek P.
next prev parent reply other threads:[~2009-06-03 7:40 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <298f5c050905150745p13dc226eia1ff50ffa8c4b300@mail.gmail.com>
2009-05-15 14:49 ` HTB accuracy for high speed Antonio Almeida
2009-05-15 18:12 ` Stephen Hemminger
2009-05-18 10:01 ` Antonio Almeida
2009-05-18 10:45 ` Jarek Poplawski
2009-05-18 12:27 ` Antonio Almeida
2009-05-18 12:32 ` Jarek Poplawski
2009-05-18 16:13 ` Stephen Hemminger
2009-05-18 18:03 ` Antonio Almeida
2009-05-18 22:02 ` Stephen Hemminger
2009-05-19 11:48 ` Antonio Almeida
2009-05-19 13:08 ` Antonio Almeida
2009-05-16 8:31 ` Jarek Poplawski
2009-05-18 10:39 ` Antonio Almeida
2009-05-18 11:14 ` Jarek Poplawski
2009-05-18 12:05 ` Antonio Almeida
2009-05-16 14:14 ` Jarek Poplawski
2009-05-18 14:36 ` Antonio Almeida
2009-05-18 23:14 ` Vladimir Ivashchenko
2009-05-18 23:27 ` Vladimir Ivashchenko
2009-05-19 11:03 ` Jarek Poplawski
2009-05-19 14:04 ` Vladimir Ivashchenko
2009-05-19 20:10 ` Jarek Poplawski
2009-05-20 22:07 ` Vladimir Ivashchenko
2009-05-20 22:46 ` Eric Dumazet
2009-05-21 7:20 ` Jarek Poplawski
2009-05-21 7:44 ` Vladimir Ivashchenko
2009-05-21 8:28 ` Jarek Poplawski
2009-05-21 9:07 ` Eric Dumazet
2009-05-21 9:22 ` Jarek Poplawski
2009-05-23 10:37 ` HTB accuracy for high speed (and bonding) Vladimir Ivashchenko
2009-05-23 14:34 ` Jarek Poplawski
2009-05-23 15:06 ` Vladimir Ivashchenko
2009-05-23 15:35 ` Jarek Poplawski
2009-05-23 15:53 ` Vladimir Ivashchenko
2009-05-23 16:02 ` Jarek Poplawski
2009-05-18 16:40 ` HTB accuracy for high speed Eric Dumazet
2009-05-18 17:23 ` Jarek Poplawski
2009-05-18 21:52 ` David Miller
2009-05-18 23:59 ` [PATCH] pkt_sched: gen_estimator: use 64 bits intermediate counters for bps Eric Dumazet
2009-05-19 2:27 ` David Miller
2009-05-19 7:02 ` Jarek Poplawski
2009-05-19 7:31 ` Eric Dumazet
2009-05-19 7:42 ` Jarek Poplawski
2009-05-19 7:57 ` Jarek Poplawski
2009-05-19 18:03 ` Eric Dumazet
2009-05-19 19:09 ` [PATCH] pkt_sched: gen_estimator: Fix signed integers right-shifts Jarek Poplawski
2009-05-26 5:47 ` David Miller
2009-05-19 8:18 ` [PATCH] pkt_sched: gen_estimator: use 64 bits intermediate counters for bps David Miller
2009-05-17 20:15 ` HTB accuracy for high speed Jarek Poplawski
2009-05-18 6:56 ` [PATCH iproute2] " Jarek Poplawski
2009-05-18 16:54 ` Antonio Almeida
2009-05-18 17:16 ` Antonio Almeida
2009-05-21 8:51 ` Jarek Poplawski
2009-05-22 17:42 ` Antonio Almeida
2009-05-23 7:32 ` Jarek Poplawski
2009-05-28 18:13 ` Antonio Almeida
2009-05-28 21:12 ` Jarek Poplawski
2009-05-29 17:02 ` Antonio Almeida
2009-05-29 17:28 ` Stephen Hemminger
2009-05-29 19:58 ` Jarek Poplawski
2009-05-29 19:46 ` Jarek Poplawski
2009-05-29 20:49 ` Stephen Hemminger
2009-05-29 20:59 ` Jarek Poplawski
2009-05-30 20:07 ` Jarek Poplawski
2009-06-02 10:12 ` Antonio Almeida
2009-06-02 11:45 ` Antonio Almeida
2009-06-02 12:36 ` Jarek Poplawski
2009-06-02 12:45 ` Patrick McHardy
2009-06-02 13:08 ` Jarek Poplawski
2009-06-02 13:20 ` Patrick McHardy
2009-06-02 21:37 ` Jarek Poplawski
2009-06-02 21:50 ` Jarek Poplawski
2009-06-03 7:06 ` Patrick McHardy
2009-06-03 7:40 ` Jarek Poplawski [this message]
2009-06-03 7:53 ` Patrick McHardy
2009-06-03 8:01 ` Jarek Poplawski
2009-06-03 8:29 ` Patrick McHardy
2009-06-03 8:45 ` Jarek Poplawski
2009-06-03 9:54 ` Jarek Poplawski
2009-06-03 10:01 ` Patrick McHardy
2009-06-03 10:05 ` Patrick McHardy
2009-06-03 10:06 ` Patrick McHardy
2009-06-03 10:27 ` Jarek Poplawski
2009-06-04 13:50 ` Antonio Almeida
[not found] ` <20090604193013.GA2755@ami.dom.local>
[not found] ` <4A282216.20203@trash.net>
[not found] ` <20090604194203.GB2755@ami.dom.local>
2009-06-09 5:25 ` Badalian Vyacheslav
2009-06-09 5:49 ` Jarek Poplawski
2009-06-04 4:53 ` David Miller
2009-06-04 7:50 ` Jarek Poplawski
2009-05-18 17:53 ` Jarek Poplawski
2009-05-18 18:23 ` Antonio Almeida
2009-05-18 18:32 ` Jarek Poplawski
2009-05-18 18:56 ` Antonio Almeida
2009-05-18 19:05 ` Jarek Poplawski
2009-05-19 10:55 ` Antonio Almeida
2009-05-19 11:04 ` Denys Fedoryschenko
2009-05-19 11:18 ` Jarek Poplawski
2009-05-19 11:21 ` Denys Fedoryschenko
2009-05-19 11:28 ` Jarek Poplawski
2009-05-19 14:31 ` Antonio Almeida
2009-05-19 11:09 ` Jarek Poplawski
2009-05-19 13:18 ` Jesper Dangaard Brouer
2009-05-19 19:35 ` Jarek Poplawski
2009-05-18 7:01 ` [PATCH iproute2 v2] " Jarek Poplawski
2009-05-17 20:29 ` Vladimir Ivashchenko
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090603074049.GA5254@ff.dom.local \
--to=jarkao2@gmail$(echo .)com \
--cc=dada1@cosmosbay$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=devik@cdi$(echo .)cz \
--cc=hazard@francoudi$(echo .)com \
--cc=kaber@trash$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shemminger@vyatta$(echo .)com \
--cc=vexwek@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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