From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Sun, 06 Jul 2014 20:42:27 +0000 Subject: Re: HFSC not working as expected Message-Id: <53B9B4B3.6010704@gmail.com> List-Id: References: <53AC30A8.2080403@yescomputersolutions.com> In-Reply-To: <53AC30A8.2080403@yescomputersolutions.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Alan Goodman wrote: > Thanks Andy, > > I have been playing around a bit and may have been slightly quick to > comment in regard of download... With hfsc engaged and total limit > set to 17100kbit the actual throughput I see is closer to 14mbit for > some reason. > > No traffic shaping: > http://www.thinkbroadband.com/speedtest/results.html?id0466829057682641064 > > > hfsc->sfq perturb 10 > http://www.thinkbroadband.com/speedtest/results.html?id0466829057682641064 > Wrong link - but that's data throughput which is < ip throughput which is < atm level throughput. Assuming you are using stab when setting the 17100kbit 14mbit date throughput is only a bit below expected. I assume your mtu is 1492, also assuming you have default linux settings of tcptimestamps on (costs 12 bytes), so with tcp + ip headers there is only 1440 bytes data /packet each of which after allowing for ppp/aal5 overheads will probably use 32 cells = 1696 bytes. 1440 / 1696 = 0.85 * 17.1 = 14.5. I am not sure what overhead you should add with stab for your pppoe as tc already sees eth as ip + 14 - maybe adding 40 is too much and you are getting 33 cells per packet. > On 06/07/14 17:42, Andy Furniss wrote: >> If you have the choice of pppoa vs pppoe why not use a so you can >> use overhead 10 and be more efficient for upload. >> >> THe 88.2 thing is not atm rate, they do limit slightly below sync, >> but that is a marketing (inexact) approximate ip rate. >> >> If you were really matching their rate after allowing for overheads >> your incoming shaping would do nothing at all. > > My understanding is that they limit the BRAS profile to 88.2% of your > downstream sync to prevent traffic backing up in the exchange > links. They do but they also call it the "IP Profile" so in addition to limiting slightly below sync rate they are also allowing for atm overheads in presenting the figure that they do. >>> This works great in almost every test case except 'excessive >>> p2p'. As a test I configured a 9mbit RATE and upper limit m2 >>> 10mbit on my bulk class. I then started downloading a CentOS >>> torrent with very high maximum connection limit set. I see >>> 10mbit coming in on my ppp0 interface however latency in my >>> priority queue (sc umax 1412b dmax 20ms rate 460kbit) however my >>> priority queue roundtrip is hitting 100+ms. Below is a clip from >>> a ping session which shows what happens when I pause the torrent >>> download. >> >> Shaping from the wrong end of the bottleneck is not ideal, if you >> really care about latency you need to set lower limit for bulk and >> short queue length. >> >> As you have found hitting hard with many connections is the worse >> case. > > Are you saying that in addition to setting the 10mbit upper limit I > should also set sfq limit to say 25 packets? Well, it's quite a fast link, maybe 25 is too short - I would test IIRC 128 is default for sfq. Thinking more about it, there could be other reasons that you got the latency you saw. As I said I don't know HFSC, but I notice on both your setups you give very little bandwidth to "syn ack rst", I assume ack here means you classified by length to get empty (s)acks as almost every packet has ack set. Personally I would give those < prio than time critical and you should be aware on a highly asymmetric 20:1 adsl line they can eat a fair bit of your upstream (2 cells each, 1 for every 2 incoming best case, 1 per incoming in recovery after loss). When using htb years ago, I found that latency was better if I way over allocated bandwidth for my interactive class and gave the bulks a low rate so they had to borrow.