All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Pearson <matthew.pearson@infomatrix.com>
To: lartc@vger.kernel.org
Subject: [LARTC] __Very__ Low Bandwidth
Date: Fri, 31 Mar 2006 15:04:30 +0000	[thread overview]
Message-ID: <442D44FE.7070105@infomatrix.com> (raw)

I am using the script below to simulate a very low bandwidth connection. 
  I found that I could turn the bandwidth knob down to about 4kbit, but 
below that I didn't get any traffic through. I've had a look at this 
generally, but couldn't find an answer. It doesn't even seem like the 
first reply packet gets through. I have tried it with much bigger 
buffers, but this doesn't help.

I found that if I put a web proxy on the machine that is running this, 
then the minimum I can turn the bandwidth down to is 12kbit and below 
that the web browser doesn't get anything back.

Is this because the delay is so great that things are getting thrown 
away by the kernel? Could I munge the packets to turn up the TTL or 
something similar?

Many thanks for some excellent tools.

Matthew Pearson

#!/bin/bash

CLIENT1\x192.168.1.190/32
CLIENT2\x192.168.1.191/32
OPER­d;
DEV=eth0
RATE=3kbit
PEAKRATE=3kbit
BUFFER1\x10kb
BUFFER2\x10kb

echo -e "Attach Egress policy..."
tc qdisc $OPER dev $DEV root handle 1:0 htb default 15
tc class $OPER dev $DEV parent 1:0 classid 1:1 htb rate 240kbit

tc class $OPER dev $DEV parent 1:1 classid 1:2 htb rate 240kbit ceil 240kbit
tc class $OPER dev $DEV parent 1:1 classid 1:3 htb rate 240kbit ceil 240kbit
tc class $OPER dev $DEV parent 1:1 classid 1:15 htb rate 240kbit ceil 
240kbit

tc qdisc $OPER dev $DEV parent 1:2 handle 2:0 tbf rate $RATE burst $RATE 
limit $BUFFER1 peakrate $PEAKRATE mtu 1600
tc qdisc $OPER dev $DEV parent 1:3 handle 3:0 tbf rate $RATE burst $RATE 
limit $BUFFER2 peakrate $PEAKRATE mtu 1600

tc filter $OPER dev $DEV protocol ip parent 1:0 u32 match ip dst 
$CLIENT1 flowid 1:2
tc filter $OPER dev $DEV protocol ip parent 1:0 u32 match ip dst 
$CLIENT2 flowid 1:3

echo -e "Attach Ingress policy..."
tc qdisc $OPER dev $DEV handle ffff: ingress

tc filter $OPER dev $DEV parent ffff: protocol ip u32 match ip src 
$CLIENT1 police rate $RATE buffer $BUFFER1 drop flowid :1

tc filter $OPER dev $DEV parent ffff: protocol ip u32 match ip src 
$CLIENT2 police rate $RATE buffer $BUFFER2 drop flowid :2

echo -e "Status Information:\nShowing QDiscs...\n"
tc qdisc show

echo -e "Showing classes...\n"
tc class show dev $DEV
echo -e "Showing filters...\n"
tc filter show dev $DEV
echo -e "Finished.\n"
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

             reply	other threads:[~2006-03-31 15:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-31 15:04 Matthew Pearson [this message]
2006-04-07 21:46 ` [LARTC] __Very__ Low Bandwidth Andy Furniss
2006-04-10  7:52 ` Matthew Pearson

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=442D44FE.7070105@infomatrix.com \
    --to=matthew.pearson@infomatrix.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.