On Mon, Dec 8, 2014 at 10:52 AM, OmegaPhil <OmegaPhil@xxxxxxxxxxxxx> wrote: > 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 am all in favor of making sure ssh works. Having other forms of traffic fail completely (instead of just getting slow), is not something I care for. 5% of traffic for other stuff and 95% for ssh is ok (well, I would prefer ssh tunnels did more of the right thing, and ssh does try to use Tos markings to do more of the right thing) /me has switched to mosh entirely for interactive traffic. > > 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). I would have liked it if there were multiple classes for background traffic, not just CS1. The other markings (EF, AFxx) all fail the game theory test. But if the sender wants to be background-ish, it would be nice to be able to signal that end to end. CS1 is the only marking (besides ect(0) and ect(1) (ecn) that comcast preserves e2e, for example. > >> 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. you might be able to do it by using fw markings rather than messing with tos. if you are going to alter tos, try to preserve ecn marks. > 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. Yea.... I realize that how SFQ works has confused the issues here, and that is why we used DRR instead in fq_codel. I ranted a bit more here.... http://svn.dd-wrt.com/ticket/3366 > > >>> 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 > -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
