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 --]
next prev 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