We are certainly looking for more high-speed testers of the new "cake" qdisc which we hope to be a successor to htb + fq_codel in many respects. It is still out of tree but can be made to compile on most kernels between 3.13 and 4.0. It solves the burst problem in particular, and also runs pretty fast. A recent preso: http://battlemesh.org/BattleMeshV8/Agenda?action=AttachFile&do=view&target=cake-battlemesh-v8.pdf More info and where to get it: http://www.bufferbloat.net/projects/codel/wiki/Cake On Fri, Aug 7, 2015 at 10:30 AM, LAMBRUSCHI Yannick (EXT) <yannick.lambruschi-ext@xxxxxxxxxx> wrote: > Hi Andy, > > > I forgot to mention that but I'm not limited at all when I don't set a peakrate, it works well. But doesn't setting a peak rate means that it will allow big 10G bursts at some instant (too much for the 1G servers I think). I only get issue when I set the peak rate (which kind of linked with the jiffy if I'm not mistaken). > > > Regards, > > Yannick > > -----Original Message----- > From: Andy Furniss [mailto:adf.lists@xxxxxxxxx] > Sent: Thursday 6 August 2015 19:01 > To: LAMBRUSCHI Yannick (EXT) ResgGtsMktMdm; lartc > Subject: Re: Using Unix TC to shape high bandwidth traffic > > LAMBRUSCHI Yannick (EXT) wrote: >> Hello, >> >> >> Thanks for the post. We also played with mtu 1514 (and even greater) >> but did not change anything. I really think it comes from the jiffy >> limit but can't find another way.. > > Strangely I have now tested with your command and mtu 1514 and I can get > gig speed OK. > > I was thinking possibly you could just omit the peak rate and mtu (which > seems to be another buffer size) and see if it was OK. > > I don't know why I am not limited like you but - > > I am using tcp netperf. > > My mobo gig nic is dumb so doesn't offload. I guess a 10 gig nic will > offload, so unless you already turned it off with ethtool it's possible > the kernel is sending huge packets to the nic. > > Maybe try far bigger mtu or not bother with peakrate/mtu - FWIW setting > 1000mbit peakrate is still going to be faster than a gig nic can go as > there are overheads above what tc sees. > > It could be kernel settings - you mention jiffies, tbf is ancient and I > don't know whether it was ever changed, or if kernel settings can change > things. > > I don't know why I am not limited like you grepping hz from my config > looks like - > > ph4[1080i25]$ grep -i hz /boot/config-4.2.0-rc4-g194a336 > CONFIG_HZ_PERIODIC=y > # CONFIG_NO_HZ_IDLE is not set > # CONFIG_NO_HZ_FULL is not set > # CONFIG_NO_HZ is not set > # CONFIG_HZ_100 is not set > # CONFIG_HZ_250 is not set > # CONFIG_HZ_300 is not set > CONFIG_HZ_1000=y > CONFIG_HZ=1000 > # CONFIG_MACHZ_WDT is not set -- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast -- 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
