yet another traffic control issue...

[mani001]

I'm trying to use a simple traffic control scheme: I want ssh to have less priority than everything else (I use to rsync a lot from remote computers). I'm trying this:

[Hu]

I do not see anything there which would shape the traffic. Reordering the traffic is not effective if you have a fast connection to a slow device, as is the case for most home users. Your rules will reorder the ssh traffic to be sent out last, but your local router is accepting the traffic rapidly and placing it in internal queues until your the traffic is sent up to your ISP. So even though your ssh traffic is sent last, the rsync traffic has already used up most of the queue and your browsing traffic is deferred until the queue clears.

You need to restrict the rate at which rsync traffic leaves, not just reorder it. You can do this by using a shaping rule or by using the rsync --bwlimit option to ask rsync to slow down.

[frostschutz]

You say you want SSH to have less priority than everything else, but then you create a PRIO qdisc with three bands and default traffic going in all the bands according to the (very strange) priomap.

Why not create a 4 band PRIO and then putting SSH in the fourth band? That would give it the lowest priority and you'd only need a filter for SSH, not for the rest.

However the whole thing is a terrible idea, if there constantly is any other traffic, PRIO will choke your SSH to death, and thanks to SFQ it will queue up before doing so. SFQ is prone to cause a lot of latency especially on slow dialup / DSL connections.

HTB is a better choice if you want balance. Also, rsync has a --bwlimit option, which would be the better choice, if you want to be able to use interactive SSH sessions.

I sometimes use a 4 bands prio on machines running gameservers. I put the gameserver UDP packets in the first band, the other bands will be priomap incremented by 1. This way, the gameserver packets will always be sent out first, even if at the same time, someone downloads maps from the HTTP server which is running on the same machine. The other packets are prioritized by TOS. On a 100mbit connection, the gameservers don't produce enough bandwidth to completely choke the other bands. On dialup connections that's exactly what would happen though.

I also used a 4 bands prio on a machine where I put P2P traffic in the fourth band. This was a case where I didn't care whether P2P choked to death or not.

[mani001]

Thank you very much for your comments!

I think I see your point: though the packets from "everything else" are first in the queue, there are very few of them because rsync produces packets at a much faster rate, it is something like that, right?
About the --bwlimit option...I knew about it but the idea behind all this was to give rsync all the bandwith if there is nothing else using internet. Is this hard to do? If it is and implies reading another one hundred pages of tc manuals and tutorials...I think I will go for the --bwlimit option (cowards option )

[Hu]

[mani001]

mmm...that makes sense...but I just realized I'm copying files (by using rsync) FROM a remote computer TO my computer...and you can't shape incoming traffic (well, I guess) So I think the only solution for me is the --bwlimit option of rsync am I right?

[Hu]

You can police incoming traffic to try to slow it down, but that is generally less effective and less precise than shaping it.