Re: Auditing a broken and basic traffic shaping setup - PRIO

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/12/14 04:27, Dave Taht wrote:
> On Sat, Dec 6, 2014 at 11:32 AM, OmegaPhil <OmegaPhil@xxxxxxxxxxxxx> wrote:
>> Disclaimer: I don't do this very often so there is probably a retard
>> error in here somewhere. I'm not expecting people to do my work for me,
>> I'm just after a better understanding of the problem so I can get more
>> control of the situation.
> 
> A couple quick notes:
> 
> 1) strict priority queuing as you do here is generally a hugely bad
> idea, as the higher classes can completely starve the rest.
> 
> DRR with weights or QFQ with weights are better alternatives, or htb
> if you want to strictly rate limit each class. (and been working on
> something easier to setup than all that called cake... aint done yet,
> if you want patches to test, contact me off list).
> 
> Here for example, I ran a netperf-wrapper rrul test, and the EF class
> was completely starved.
> 
> http://pastebin.com/WaKRDATx


Thanks for the reply :) For reference all traffic on this server is
mine, and therefore I can do what I want with it.

I do know about strict priority stuff - that is the aim, to make sure
that important packets are not affected by those of less importance
(e.g. so I don't care that there are 100 torrent UDP streams hammering a
connection, my SSH connection always wins and the lag impact of any
other traffic is minimal).

I will read into DRR and QFQ - I originally settled in PRIO because of
the KISS principle, it sounded exactly what I wanted and should be easy
to set up and maintain.

Will email off list - while the remote server wouldn't be a good idea
for testing I do have the local Ubuntu server running the default
priomap that I can test on - cheers.


> 2) ToS as used here, was obsoleted in *1998* by the ietf and replaced
> with Diffserv and ECN.
> 
> http://en.wikipedia.org/wiki/Type_of_service
> 
> CS1 would have been the right thing for minimize-cost in particular.


I know that ToS is old, I thought it was 1:1 with the new Diffserv
stuff, but since you said that I guess not. I will read into it again
(if it isn't then I'll need to look into how iptables is supposed to tag
the packets without --set-tos).


> By peeing on the markings here you are messing with the intent of the sender.
> 
> and there is no need to fiddle with the lower level tcp flags here at all.
> 
> fq_codel automagically recognises sparse flows (like tcp syns) and
> does the right thing already. IF you are on an asymmetric network you
> might want to use fq_codel with a lower quantum so to give acks a
> little more priority that way.

I am the sender, so the ToS stuff is my intent? Its just relevant for
the local prioritisation, while deluge can flag ToS I can't properly
audit it (the Wireshark issue), and the other programs don't have the
functionality.

Right, I see with fq_codel - that was a recent advancement for me,
originally the PRIO children were just normal queues. Good, I'll get rid
of that complexity.


>> Band 1: Normal (nothing targetted here)
>> Band 2: Torrenting, Maximize Throughput
> 
> No, this should be Background, CS1. IF you have control over your
> torrent clients, most support setting the CS1 bit in their
> configuration....
> 
>> Band 3: Special programs, Minimize Monetary Cost
> 
> totally obsolete bit. dont do that. see ecn.

Will read into Diffserv and ECN.

Thanks for your feedback.


-- 
Libre software on Github: https://github.com/OmegaPhil
FSF member #9442

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux