All of lore.kernel.org
 help / color / mirror / Atom feed
From: don-lartc@isis.cs3-inc.com (Don Cohen)
To: lartc@vger.kernel.org
Subject: [LARTC] HTB burstable for 2 interface , how ?
Date: Fri, 04 Jul 2003 16:39:50 +0000	[thread overview]
Message-ID: <marc-lartc-105733784302790@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105722285902235@msgid-missing>


 > INTERNET
 > |
 > |eth0 202.14.41.1
 > BW.Manager
 > | |
 > | +----eth1----192.168.1.0/24
 > |
 > +------eth2----192.168.2.0/24
 > 
 > Total incoming bandwidth to eth0 is 1024kbps
 > should be shared to eth1 and eth2, which mean each get 512Kbps and
 > burstable to 1024Kbps if other host is idle.

This doesn't make sense to me.
The fact that an internal host is idle does not justify not sending
traffic TO it.

The suggestions to use IMQ+HTB seem to miss the problem that 
if someone sends 1024 to eth1 then nobody has a chance to even
begine to send anything to eth2.

I think you want to allow "borrowing" only as long as the total
incoming rate from eth0 is sufficiently less than 1024 to be sure
that those sending to the lesser used internal interface can speed up.
In effect I think you have to sacrifice some part of your 1024 to make
sure the shaping is done at your machine.  I'm not sure how much you
have to sacrifice.  But suppose it's 24K, so you then have two htb
classes that have rate 500, ceil 1000.  And the parent class also
has ceil 1000.  That's critical.  That means that if we send at full
rate to eth1 then we still have room for someone to start sending to
eth2.  Then when someone does start sending, he initially gets 24K to
eth2.  At that point HTB reduces the traffic to eth1 by 24K in order
to stay below total 1000.  Then the guy sending to eth2 can increase
by 24K which will cause eth1 to drop another 24, etc.
As you can see, the amount you "reserve" (you might say "waste") also
limits how fast the traffic equalizes.  

Does this make sense to everyone out there?
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2003-07-04 16:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-03  8:56 [LARTC] HTB burstable for 2 interface , how ? rio
2003-07-03  9:12 ` Stef Coene
2003-07-03  9:12 ` ???????? ?????
2003-07-03  9:18 ` Martin Devera
2003-07-03  9:38 ` rio
2003-07-03  9:50 ` Stef Coene
2003-07-03 11:45 ` Joel
2003-07-04 16:39 ` Don Cohen [this message]
2003-07-07  3:54 ` Leonardo Balliache
2003-07-09  3:22 ` Leonardo Balliache

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-105733784302790@msgid-missing \
    --to=don-lartc@isis.cs3-inc.com \
    --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.