From: Ane Roos <apr@xs4all.nl>
To: lartc@vger.kernel.org
Subject: [LARTC] Fw filtering.
Date: Tue, 27 Nov 2001 10:53:36 +0000 [thread overview]
Message-ID: <marc-lartc-100685830223678@msgid-missing> (raw)
Situation: PC at home, ADSL connection (Mxstream basic).
This form of ADSL is quite skewed (8:1) and has the annoying
peculiarity that uploads totally suffocate simultaneous downloads.
I'm trying to find out if this behaviour can be improved using
iptables MARK and fw filters. The following is not meant to be a realistic
scheduling scheme, the idea is more to get clear testresults and develop
a feel for tc (this is my first effort).
#!/bin/sh
tc qdisc add dev ppp0 root handle 1: prio
#2 fifo queues for our prio
tc qdisc add dev ppp0 parent 1:1 handle 10: pfifo limit 3
tc qdisc add dev ppp0 parent 1:2 handle 20: pfifo limit 3
#MARK 7 will go to q 10, MARK 11 to q 20
tc filter add dev ppp0 protocol ip parent 1:0 prio 1 handle 7 fw classid 1:1
tc filter add dev ppp0 protocol ip parent 1:0 prio 2 handle 11 fw classid 1:2
#tc -s qdisc show
My test relays a 200K mail to smtp.xs4all.nl (35 sec standalone) and
downloads a 900K file from dl.xs4all.nl (20 sec standalone).
The iptables rules are:
#!/bin/sh
iptables -t mangle -F OUTPUT
iptables -t mangle -A OUTPUT -p tcp -d smtp.xs4all.nl -j MARK --set-mark 11
iptables -t mangle -A OUTPUT -p tcp -d dl.xs4all.nl -j MARK --set-mark 7
and after the first test tc -s qdisc show gives
qdisc pfifo 20: dev ppp0 limit 3p
Sent 224934 bytes 201 pkts (dropped 0, overlimits 0)
qdisc pfifo 10: dev ppp0 limit 3p
Sent 19569 bytes 376 pkts (dropped 0, overlimits 0)
qdisc prio 1: dev ppp0 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 244503 bytes 577 pkts (dropped 0, overlimits 0)
Now I invert the marks and run the test again:
qdisc pfifo 20: dev ppp0 limit 3p
Sent 245102 bytes 587 pkts (dropped 0, overlimits 0)
qdisc pfifo 10: dev ppp0 limit 3p
Sent 241008 bytes 534 pkts (dropped 0, overlimits 0)
qdisc prio 1: dev ppp0 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 486110 bytes 1121 pkts (dropped 0, overlimits 0)
So everything appears to land in its intended queue.
The output from the testscript is:
Test1 Test2
Start mail 10:14:26 10:19:43
Start download 10:14:32 10:19:48
End mail 10:15:03 10:20:19
End download 10:15:21 10:20:37
and the time difference End mail/End download in both tests is still
almost the 20 seconds of the standalone download
A case of operation successful, patient dead (it was already dead to
begin with so nothing's lost).
Your comments please.
--
Ane Roos | Nice,nice,very nice-- | Calypso 53,
apr@xs4all.nl | So many different people | The Book of Bokonon,
| In the same device. | - Kurt Vonnegut
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
reply other threads:[~2001-11-27 10:53 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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-100685830223678@msgid-missing \
--to=apr@xs4all.nl \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox