# TC HTB link sharing again.

## venquessa2

My brother, is downloading full speed ahead with BitTorrent.

I am trying to listen to net radio.

I have what appears to be the correct TC classes and filters in place, and traffic is registering correctly, but it's just not working!

The NIC parent class:

```

class htb 1:1 root rate 100000Kbit ceil 100000Kbit burst 14087b cburst 14087b

 Sent 6776207 bytes 7055 pkt (dropped 0, overlimits 0 requeues 0)

 rate 475800bit 64pps backlog 0b 0p requeues 0

 lended: 0 borrowed: 0 giants: 0

 tokens: 1038 ctokens: 1038

```

ADSL Traffic class:

```

class htb 1:10 parent 1:1 rate 512000bit ceil 512000bit burst 1663b cburst 1499b

 Sent 6776207 bytes 7055 pkt (dropped 0, overlimits 0 requeues 0)

 rate 475800bit 64pps backlog 0b 0p requeues 0

 lended: 5960 borrowed: 0 giants: 0

 tokens: 3456 ctokens: 831

```

My Class...

```

class htb 1:11 parent 1:10 leaf 10: prio 0 rate 256000bit ceil 512000bit burst 1631b cburst 1499b

 Sent 342059 bytes 240 pkt (dropped 0, overlimits 0 requeues 0)

 rate 22448bit 1pps backlog 0b 0p requeues 0

 lended: 239 borrowed: 1 giants: 0

 tokens: 4864 ctokens: 319

```

My Brothers class:

```

class htb 1:12 parent 1:10 leaf 20: prio 7 rate 64000bit ceil 512000bit burst 1607b cburst 1499b

 Sent 6433897 bytes 6814 pkt (dropped 0, overlimits 0 requeues 0)

 rate 453896bit 62pps backlog 0b 0p requeues 0

 lended: 855 borrowed: 5959 giants: 0

 tokens: -295704 ctokens: 831

```

"Other traffic (main server)" class:

```

class htb 1:13 parent 1:10 leaf 30: prio 7 rate 64000bit ceil 512000bit burst 1607b cburst 1499b

 Sent 251 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)

 rate 8bit 0pps backlog 0b 0p requeues 0

 lended: 1 borrowed: 0 giants: 0

 tokens: 174080 ctokens: 20031

```

Note that although I am trying to listen to a 160kbit/s mp3 stream, I can only get 22.4kbit/s while my brother maintains over 400kbit/s!.  Yet the classes are set to gaurantee me 256kbit and my brother only 64kbit/s.  Bursts are all set for 1 packet in an attempt to enforce things, but nothing will cut through this bit torrent.

Okay, so I can manually over-ride him by dropping the 160kbit/s +10% OH off his peak rate.  I've been doing this from time to time, but I would prefer that tc work the way it's been sold to me.

I just don't know where I'm going wrong.

The traffic graphs for this can be found:

http://campbell-multimedia.co.uk/cacti/

guest:guest

Page:  Router  or QoS & Traffic Control.

[edit]  time span 18:00 BST to 18:40 is the period under test.

Thanks for any help you can send my way.

----------

## kaksi

I'm not sure but with tc you can only control/limit the upload speed pf your connection.  So The only thing you limit when your brother is downloading with bittorent is his upload speed and his ack packages. Maybe this is your problem? But if the problem is that he is using all the donwload speed then you have alot more problems...

I'm searching for a solution on howto limit the download speed but that is quite a problem. You can not control how fast someone is sending packages to you. What you can do is to drop packages if someone is sending you packase at high speed. Hopefully the sender will lower the speed until you stop dropping packages. Although not all programs does this but I believe most do.

----------

## venquessa2

Thanks, but I'm aware of all that.  The info I showed is for my LAN side interface.  Works like this....

Packets arrive from the web and before they are forwarded to the client on the LAN, they are passed to the HTBs.

In theory, when I am not using my 256kbit/s it will be loaned to my brother and he can use it all.  His packets will not queue as he can't recieve faster than the ceiling rate which is teh same as teh actually link speed.  512kbit/s.

However, what is "meant" to happen is when I need those 256kbit/s I get them, because his packets will be queued while there are packets for me, so I should get the 256kbit/s and make him wait on his packets.  His ACK's will return after an increasing delay and the sender will slow down a bit allowing more of my packets in.  This should happen quite quickly over maybe 20 seconds until I have all of my 256kbit/s and he has the remainder.

It doesn't work though.  I believe the catch is...

If he is receiving 450kbit/s there is only room for me to get 50kbit/s or so.  Before the TC even comes into effect at link capacity this is whats in the pipe.  There is enough forwarding bandwidth for it not to queue at all, so it doesn't.  No shaping occurs, no delay is imposed on his ACKs' and so the other ends of the connection don't know to slow up or speed up.

I suppose all I can do is lower the overall rate to just below the actual link speed, lose 1 or 2 % BW and create some queues as the ISP will send faster than my router will forward.

Unless anyone else has other ideas?

----------

## nobspangle

You can't shape your downloads, even if you try to shape them as they leave your LAN interface, the data has already come down your WAN connection and filled that up.

You can only get really effective QoS when you have control of all the routers on route.

----------

## venquessa2

 *nobspangle wrote:*   

> You can't shape your downloads, even if you try to shape them as they leave your LAN interface, the data has already come down your WAN connection and filled that up.
> 
> You can only get really effective QoS when you have control of all the routers on route.

 

No, not true controI I realise that.  But you can make an impact on the sharing and allocation of the bandwidth you get.  Well with TCP anyway, UDP less so, but still some.

I confirmed that if I lower the overall bitrate to just a fraction lower than what I am actually recieving, lower priority packets are queued in their respective bands.  The higher priority gets through unqueued.  TCP catches up over a period of about 10 seconds and the allocated bandwidths are achieved.

The result is that the recieving application gets it later than it would have and therefore repiies later.  Due to the TCP sliding windows algorhythm the lower priority connections slow down and the intended QoS works perfectly.  I just need to set the queues much longer on the bullk band.

Occasonally, like every 5 minutes, cutting 10% off the incoming ADSL link speed for 20 or 30 seconds, then releasing should help keep it active.... without dropping a single packet... or wasting (much) incomnig bandwidth.

----------

## venquessa2

To better explain....

The QoS system discribed only works when there is congestion.  Lower priority packets are then delayed to their destination.   The replies are equally delayed, and the TCP flow control takes effect.

All I have to do is find the most efficent way to create congestion by limiting the out side of the link at appropriate intervals and times.

When the link is NOT congested, however, there may still be problems for the QoS.

Dynamically allowing the ceil rate to expand with the incoming rate, sounds like too far to go.  eg:

poll every 1 minute:

    Incoming = modem.getInomingRate();

    MasterRate = 90% of Incoming

    Sleep 10 seconds

    MasterRate = Full rate.

Something like that anyway.

----------

## venquessa2

Sorry to keep replying to my own post but I had an idea in the loo there now...

What about.... I pipe fake packets into the HTB tree every 10 seconds?  That way, the "real" incoming packets are only queued, I dont have to take the risk of losing inbound traffic by overlimiting the queues and the HTB's should respond as designed.

Now... how do I inject a finite amount of ttraffic that will trigger the queues to believe congestion... hmmm.

----------

## bigfunkymo

First, have a look here:

https://forums.gentoo.org/viewtopic-t-347779.html

Second, find about your internet radio's traffic using tcpdump. Does it use TCP or UDP? What is the source port on the incoming packets?

Third, use that information and the referenced HOWTO to add tc rules that will actually make your stuff work.

I imagine you will probably just have to set your RXRATE between 50% and 75% of your home connections maximum downstream rate and then set up the ingress filter to never drop your internet radio packets.

----------

