Hi Andy Furniss, On Mon, 04 Apr 2005 12:42:21 +0100, Andy Furniss <andy.furniss@xxxxxxxxxxxxx> wrote: > > Wow - I wish I could write that in 2 days :-) > I think if you have a deadline, then you can do that :-) > > > > The test scenario is like this > > > > www server <- [ eth0 eth1 ] -> www clients > > > > The attached t.sh is used to generate test rules. Clients download a > > big ISO file from www server, so flows' rate can be estimated by view > > progress. However I use wget to test the speed, so the speed is > > accumulated, not current. > > What if the client uses a download accelerator and has 12 connections (I > suppose server could limit this - but if client is behind nat you may > hurt others - which is what sfq does now AIUI, because it doesn't hash > on dst port.) > The test scenario is not the real scenario under which it will be used. I just use this for test, because it is simple. This per flow control is good when used for VoIP (Voice and Video). > > > > The problems I know: > > > > 1. The rtnetlink related code is quick hack. I am not familiar with > > rtnetlink, so I look at other queue's code and use the simplest one. > > > > 2. perflow queue has no stats code. It will be added later. > > > > 3. I don't know what is the dump() method 's purpose, so I didn't write > > dump() method. I will add it later when I know what it is for and how to > > write rtnetlink code. > > > > Any feedback is welcome. And test it if you can :) > > > > PS: the code is licensed under GPL. If it is acceptable by upstream, it > > will be submitted. > > Having per flow without the drawbacks of sfq is really cool, but I agree > with Patrick about letting htb/hfsc limit. You say in the code - > > "You should use HTB or other classful qdisc to enclose this qdisc" > > So if you do that (unless you meant should not) then you can't guarentee > per flow rate anyway without knowing the number of flows, unless you can > set rate so high that max flows x flow rate < htb rate. HTB is providing guaranteed bandwidth. per flow control has its own bandwidth limit ( rate * 1.05 * limit ). > > I think you can still limit per flow ceil if you use htb/hfsc to ratelimit. > > I suppose you are solving a different problem with this than I normally > shape for ie. you have loads of bandwidth and I have hardly any. > Let me explain the idea more clear. For example, you may have 50 streams. These stream can work perfectly at 10kbps - 15kbps. With HTB + SFQ, you should give 50*15 guaranteed. but then, if only one stream is using this, it can use up to 50*15 guaranteed. You have risk of waste 49*15 on it. In another hand, if your have more than 50 streams, say, 80 streams. With perfect fairness, every stream can get less than 10kbps. The quality is not met however, no one is satisfied with fairness. So, you have risk of waste and still you don't have guarantee. With per flow rate control, you can give a guaranteed 12*65, and set per flow control to rate=12,ceil=15,limit=60. When you have only a few streams, you don't worry that you waste bandwidth. If more than 60 streams occurs, the first 60 streams still works fine. Fairness is good, but sometimes, fairness means everyone hurts. If you have more than enough bandwidth, you can use fairness to get good QoS. But it is not the case when bandwidth is not so enough. BTW: Are there any good document for HFSC? I don't even know how it works :( Maybe it's can be used to achieve per flow control. > It still could be something really usefull for me though, as I suspect > it wouldn't be too hard to add lots of features/switches which (e)sfq > doesn't have like - > > Per flow queue length limit - and more choice than just tail drop (I am > thinking of me shaping from wrong and of link here - server with BIC tcp > is horrible with tail drop - others are not as bad). > > For people who use esfq for hundreds of users, you could still do > fairness of tcp flows within fairness per user address. > > Requeue properly which (e)sfq doesn't. Because this per-flow queue is new, you can add things useful to it. > > Andy. -- lark _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
