From mboxrd@z Thu Jan 1 00:00:00 1970 From: OmegaPhil Date: Mon, 08 Dec 2014 18:52:40 +0000 Subject: Re: Auditing a broken and basic traffic shaping setup - PRIO Message-Id: <5485F378.4050902@startmail.com> MIME-Version: 1 Content-Type: multipart/mixed; boundary="WW2SCMNoNTPTeRTaox3VjKDdKHRUf4CGp" List-Id: References: <548359D6.7030505@startmail.com> In-Reply-To: <548359D6.7030505@startmail.com> To: lartc@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WW2SCMNoNTPTeRTaox3VjKDdKHRUf4CGp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/12/14 04:27, Dave Taht wrote: > On Sat, Dec 6, 2014 at 11:32 AM, OmegaPhil wr= ote: >> 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. >=20 > A couple quick notes: >=20 > 1) strict priority queuing as you do here is generally a hugely bad > idea, as the higher classes can completely starve the rest. >=20 > 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). >=20 > Here for example, I ran a netperf-wrapper rrul test, and the EF class > was completely starved. >=20 > 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. >=20 > http://en.wikipedia.org/wiki/Type_of_service >=20 > 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 s= ender. >=20 > and there is no need to fiddle with the lower level tcp flags here at a= ll. >=20 > 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 >=20 > No, this should be Background, CS1. IF you have control over your > torrent clients, most support setting the CS1 bit in their > configuration.... >=20 >> Band 3: Special programs, Minimize Monetary Cost >=20 > totally obsolete bit. dont do that. see ecn. Will read into Diffserv and ECN. Thanks for your feedback. --=20 Libre software on Github: https://github.com/OmegaPhil FSF member #9442 --WW2SCMNoNTPTeRTaox3VjKDdKHRUf4CGp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUhfOEAAoJEBfSPH39wvOPbD8P/0+9K3rVJTkQpLoUxJbK3b1P m5bz9r1/Jn4a7EEP9/Xe9MoFv0drUTxmoD+TlvXC3QB/3FtpmmM28eo8slr4hwZ1 aklgDPPwxZfPZvKtL9VZ04pi8o0Y2ern/ldmvFYyGFmdVolXMLuvqHIHdwKuVqX/ qqwgJ5pXw0hCuR1e9yYcnl36/DSuESSqg/BJ/cPwP7ltbCunK2vJYGlCWgszkqcs ZcGcKqCrdjFzWhJPiuOOiuzq6GcXLp0b+LVGXcJhbXo0pIaTSuXP1tYbZhjYI1pQ L92wQIGLUbxNawVxQqBjwyMTVi4rc/4h8qO/7/4gmRgXbPxeeJMZt5S1ktehMbLD jthh5FzKM1FrZwsGyBJkkckAjObtC72UZ16aNGCdaz2AzvkJYEJ4tNZblpYgaMnt xmxki9gfc2TsoQkp13h7K0WfTKKtOgb/kSWxnDIkaCbW+3OSDiHMIs5xD1c1BDo2 81v0hnkRrjwc6Hb3p96XT3hjhKp3ugCeE3rrj55T6TSAqDQ47k0/gaGKQYeqXDJv 6Er1Pli9z8nAVumtcGm6QJbeBBShfb9oe+PTpZW0SYrqiRZADt37RfqYGV0Mxo5D DGlBJxFx21FCbxCIitlIm1zovw0PgbuM25dQtc7tUqCjbJq3rZJqYVKHhJxMBKol zv1BSSr2UuS1VM2dhPEg =jsl/ -----END PGP SIGNATURE----- --WW2SCMNoNTPTeRTaox3VjKDdKHRUf4CGp--