-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings again Vadtec,
: After another two days of trying to get this to work like I think
: it should, I've still hit a brick wall.
This can be frustrating, I know.
[ snip ] (I admit, I didn't look at the rules very closely, but
fundamentally the rules themselves look good.)
You do use an ingress filter with a policer. Since the policer
applies equally to all inbound traffic flows, it doesn't really do
you any good here.
: Regardless of the values I use for any of the rates, I still have
: the same problem. I do not classify ANY traffic with iptables for
: this set of tc filters, so any traffic that is generated is
: solely shaped by tc in this case.
:
: The problem I have is this, whenever I allow any torrent client
: to use above 20k of outgoing bandwidth, *everything* becomes
: laggy for some reason. Most notable is SSH. While I have no
: accurate way to time the lag, as near as I can tell it lags about
: 2 seconds. When I press a key on my keyboard it takes ~2 seconds
: to show up in the SSH client. Or, if I enter lets say "ls" and
: press enter, it takes roughly 2 seconds for the ls output to
: reach me, and while its being displayed, its choppy appearing (as
: in it comes in chunks rather than a nice stream).
:
: I see absolutely no reason for this to be happening. Why should
: anything lag when I'm using more outgoing bandwidth? Why would
: more outgoing bandwidth cause a slow down on incoming bandwidth.
: Or, why would more outgoing bandwidth slow down the filters/tc?
: I've verified that this happens on more than just my modem. I've
: used two different routers and a cable modem. All suffer from the
: same symptoms.
You are neglecting one important consideration, and that is the
download traffic. You may well be shaping the upstream traffic, but
the queues transmitting downstream are also full.
So, once again--I'd suggest that you consider what it takes for your
"ls" keystrokes and then the output to make it back to you.
* you press a key ("l"), your ssh client transmits a packet
* this packet goes across your congested link (probably
significantly delayed, because there's congestion here)
* the packet arrives on the ultimate destination
* the sshd on the remote side receives the packet, passes it to
the application layer (blah blah, bash, fork, exec, ls)
* the sshd receives data from the application layer and transmits
a packet
* your traffic control structures take this inbound ssh packet and
give it its dedicated slot (however you have built your queues)
* packet returns quickly to your system
So, your shaping is great, but you aren't shaping all of the
paths through which your application flow must pass.
: For the record, my router PC is built as such:
: CentOS 5 64bit
: AMD Sempron 2800+ (64bit, 1.6Ghz)
: 2GB of DDR
: 2GB of swap
:
: As you can see, this PC is more than capable of acting as my router.
And then some. Very reasonable looking box.
Good luck,
- -Martin
- --
Martin A. Brown
http://linux-ip.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/)
iD8DBQFG32pfHEoZD1iZ+YcRAp8DAKDDb7eO6/cNZp+lLg8tyO07QffzuQCfcTA3
DnHkDHC/Ea09qNsuEBhi+vs=
=VBjg
-----END PGP SIGNATURE-----
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
