# 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:

```

# delete everything

tc qdisc del dev eth0 root

tc qdisc add dev eth0 root handle 1: prio priomap 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 0

tc qdisc add dev eth0 parent 1:1 handle 10: sfq

tc qdisc add dev eth0 parent 1:2 handle 20: sfq

tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 10

# ssh

tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:3

tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip sport 22 0xffff flowid 1:3

# everything else (192.168.1.129 being my IP)

tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip src 192.168.1.129 flowid 1:1

tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dst 192.168.1.129 flowid 1:1

```

isn't it as simple as this? When I run

```

tc -s qdisc ls dev eth0

```

it seems the packets get queued into their corresponding bands...but when I rsync a bit chunk of data from a remote computer, I cant' browse internet   :Sad: 

Any idea? Am I missing something?

----------

## 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    :Very Happy:   )

----------

## Hu

 *mani001 wrote:*   

> 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?

 Right.  By the time you produce some high priority traffic, the upstream queue is already saturated with rsync traffic and your priority traffic is still forced to wait. *mani001 wrote:*   

> 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     )

 This is not too difficult to do.  As frostschutz mentioned, HTB is appropriate here.  The key is to ensure that your WAN-facing NIC generates traffic at about the rate that the upstream router will accept packets from you.  If you generate slower than that, you leave the link idle.  If you generate faster than that, you get into the situation that you have now: the upstream router queues your traffic and defeats your ability to prioritize.

----------

## mani001

mmm...that makes sense...but I just realized   :Embarassed:   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   :Confused:   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.

----------

