All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Takács Bálint" <deim@inf.elte.hu>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] HTB shares equally when borrowing enabled :(
Date: Mon, 02 Sep 2002 11:24:59 +0000	[thread overview]
Message-ID: <marc-lartc-103096558908110@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103083477529203@msgid-missing>

Thanks Stef! The trick with setting lower maximum bandwidth works. I 
convinced me that I understand now what happens :) The ISP starts to 
build queues when maximal input rate is reached and releases packets 
from these queues equally. Thus the prioritized connections had to wait 
sometimes and it lends its guaranteed bw instead of waiting.

I had to set the ceil to as low as 50 kbps (!). My usual maximal 
throughput rate is about 55 kb/sec, while my ISP says the maximal input 
rate is 512 kbit/sec. I always assigned the difference to IP 
administration. Now, the maximal throughput  seems to not drop until 
ceil is lowered below 55 kbps. Thus I assume the rates calculated by HTB 
measure the REAL throughput without IP administration. Is it true?

Sometimes the maximal input rate drops (damn ISP) and it seems to enable 
small  "bursts"  with high throughputs. Does it mean that I should to 
decrease/increase the ceil when it happens? I think it depends on the 
ISP queues: if they start to build, then I must. It can mean that I 
can't use traffic shaping, or at least not HTB qdisc - maybe some prio 
setup will do the job.

What if I try to shape the outgoing traffic? Maybe it has an effect on 
incoming, too. I mean if "acknowledged" information goes back slow, I 
can manipulate the ISP queues, hm?

Bálint

Stef Coene wrote:

>On Sunday 01 September 2002 01:04, Takács Bálint wrote:
>
>>Hi,
>>
>>I'm fighting seriously with a most simple HTB setup. I'd like to share
>>the incoming 64kbps into 5 and 59 for two different machines under NAT.
>>HTB seems to hold the required limits when ceil is not set  (no
>>borrowing), but when borrowing enabled it seems to share equally rather
>>then keeping the specified ratio.
>>My setup is below. A typical output of "tc -s -d qdisc show dev eth1"
>>and "tc -s -d class show dev eth1" is given. HTB seems to disobey the
>>specified rate (last entry: rate 40Kbit is set for 1:10 and 16466bps is
>>measured, while rate 472Kbit is set for 1:11 and  rate 20755bps is
>>measured).
>>Setting the explicit bandwith (ceildkbps everywhere) does not work.
>>Playing with burst and cburst did not any change.
>>
>You have to put a ceil of 64kbps everywhere so class 1:10 and 1:11 share the 
>same 64 kbps :
>
>run_tc class add dev eth1 parent 1: classid 1:1 htb rate ceil 64kbps
>
>run_tc class add dev eth1 parent 1:1 classid 1:10 htb rate 5kbps ceil  64kbps 
>prio 2
>run_tc class add dev eth1 parent 1:1 classid 1:11 htb rate 59kbps ceil  64kbps 
>prio 1
>
>And if that's not working, try ceilbkbps.  You have to do this so YOU are 
>controlling the link and not the modem.  And take sum of class = 62kbps.
>
>Stef
>


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2002-09-02 11:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-31 22:59 [LARTC] HTB shares equally when borrowing enabled :( Takács Bálint
2002-09-01  8:44 ` Stef Coene
2002-09-02 11:24 ` Takács Bálint [this message]
2002-09-02 18:50 ` Stef Coene

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=marc-lartc-103096558908110@msgid-missing \
    --to=deim@inf.elte.hu \
    --cc=lartc@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.