Matthew Toseland ([EMAIL PROTECTED]) wrote:

> The disadvantage is that it can't possibly work because TCP does not
> provide a way beyond the most crude imaginable to tell the other end to
> use a given bandwidth.

That's irrelevant.  My download speed is twice my upload speed, and I
consider that a fairly uncommon ratio.  Most cable modem users have
download speeds that are 5, 10 or more times their upload.

I control my outgoing bandwidth on OpenBSD 3.1 using ALTQ.  (The Linux
equivalent of this would be netfilter, I think.)

Here's the setup I'm using:

$ cat /etc/ppp/ppp.linkup
MYADDR:
 !bg /sbin/pfctl -N /etc/nat.conf -R /etc/pf.conf
 !bg /usr/local/sbin/ntpd -p /var/run/ntpd.pid >>/var/log/daemon 2>&1
 !bg /usr/sbin/tbrconfig tun0 256k auto >>/var/log/daemon 2>&1
 !bg /usr/sbin/altqd >>/var/log/daemon 2>&1

$ cat /etc/altq.conf 
interface tun0 bandwidth 256k cbq

class cbq tun0 root_class NULL priority 0 pbandwidth 100
class cbq tun0 def_class root_class pbandwidth 95 default
class cbq tun0 gift_class def_class borrow pbandwidth 50
        filter tun0 gift_class 0 0 0 1257 6
class cbq tun0 web_class def_class borrow pbandwidth 40
        filter tun0 web_class 0 0 0 8080 6

Now, I'm CERTAINLY not a networking/firewall guru, so this may be a
suboptimal setup.  But it definitely seems to help over the default
queueing.  Here's my pitiful understanding of what it's doing:

First, tbrconfig sets up a throttle on the tun0 interface (which is
my PPPoE interface).  My upload is capped at 256 kbps, but the physical
ethernet interface can happily spit out 100 Mbps.  If the kernel doesn't
know any better, it will think tun0 can go 100 Mbps.  So I need to tell
the kernel to slow tun0 to 256k, or nothing else will have any effect.
(The ALTQ docs explain this better than I can.)

Then I tell altqd that tun0 has 256k of outgoing bandwidth, and to use
it as follows:

 * The default class is allowed to use 95% of outgoing bandwidth, period.

 * The "gift_class", which is a child of default, can use 50% of outgoing
   bandwidth, but it can borrow from its siblings if they're not using
   their share.  gift_class is defined as TCP port 1257 (my giFT node).

 * The "web_class", which is also a child of default, can use 40% of
   outgoing bandwidth, and can borrow from its siblings.  web_class is
   defined as TCP port 8080 (my second Apache instance, which has not
   been running lately because I'm trying to give Freenet some bandwidth).

You'll note that I don't define Freenet here.  That's because compared
to giFT and Apache, Freenet is friendly.  When I start that Apache
instance, people suck my Oggs and MP3s like there's no music stores
in the whole world.  Apache alone will slam my outgoing bandwidth
usage to 100% and keep it there forever.

The reason I reserve 5% of outgoing bandwidth is because ADSL is
half duplex.  If 100% of outgoing bandwidth is used, then I can't
download anything -- packets can't come in.  Also remember that any
TCP/IP connection requires two-way communications.  TCP needs to
send acknowledgement packets every so often to keep things running.

-- 
Greg Wooledge                  |   "Truth belongs to everybody."
[EMAIL PROTECTED]              |    - The Red Hot Chili Peppers
http://wooledge.org/~greg/     |

Attachment: msg01873/pgp00000.pgp
Description: PGP signature

Reply via email to