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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.