Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: OmegaPhil <OmegaPhil@startmail.com>
To: lartc@vger.kernel.org
Subject: Re: Auditing a broken and basic traffic shaping setup - PRIO
Date: Mon, 08 Dec 2014 18:52:40 +0000	[thread overview]
Message-ID: <5485F378.4050902@startmail.com> (raw)
In-Reply-To: <548359D6.7030505@startmail.com>

[-- Attachment #1: Type: text/plain, Size: 3538 bytes --]

On 07/12/14 04:27, Dave Taht wrote:
> On Sat, Dec 6, 2014 at 11:32 AM, OmegaPhil <OmegaPhil@startmail.com> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2014-12-08 18:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-06 19:32 Auditing a broken and basic traffic shaping setup - PRIO OmegaPhil
2014-12-07  4:27 ` Dave Taht
2014-12-08 18:52 ` OmegaPhil [this message]
2014-12-08 19:25 ` Dave Taht
2015-08-23 19:45 ` OmegaPhil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5485F378.4050902@startmail.com \
    --to=omegaphil@startmail.com \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox