Description of Problem: /sbin/cbq sets up the traffic queues with an avgpkt rate of 1000 packets per second, which is too low for shaping to work correctly on very busy sites. I have found that a rate of 3000 packets per second works much better. Version-Release number of selected component (if applicable): shapecfg-2.2.12-7 (/sbin/cbq is version v0.3alpha2) Steps to Reproduce: 1. Try to shape a 100Mb interface using the follwoing: DEVICE=eth0,100Mbit,10Mbit RATE=30Mbit WEIGHT=3Mbit PRIO=5 BUFFER=800Kb/8 LIMIT=800Kb RULE=<your ip address>, 2. Monitor the actual bandwidth output from that port. 3. Notice that it is much less than what you expect of 30Mbit Actual Results: In testing, I've found that a setting of RATE=35Mbit, WEIGHT=4Mbit only gives an actual rate of ~26Mbit with avgpkt set to 1000. With avgpkt set to 3000, RATE=30Mbit, and WEIGHT=3Mbit (as above) the rates are much closer to the rate setting requested of 30Mbit. Expected Results: I expect that when I set a RATE=30Mbit line in the cbq configuration, that the actual rate will be 30Mbit, not some value less than 30Mbit. Additional Information: This RFE is basically s/avgpkt 1000/avgpkt 3000/ on the cbq.sh in shapecfg. It has already been tested on high traffic servers, and no abnormal side-effects were noticed. I've also noticed that raising the shaping above ~26Mbit does not appear possible with avgpkt set to 1000, no matter what you set RATE to. I've not seen the same problem with avgpkt set to 3000.
Do you have any idea who maintains shapecfg, where it's homepage is, or any other info on it or cbq, etc? I'm unable to update this package because it seems to not exist outside of various distro packaging.
There's a page registerd with freshmeat that points to a web site with various versions of cbq.init on it, but it does not appear to be run by the original maintainer: http://freshmeat.net/projects/cbq.init/ There's also a pointer to the home ftp site in http://www.linuxdoc.org/HOWTO/Bandwidth-Limiting-HOWTO/cbq.html which points to ftp://ftp.equinox.gu.net/pub/linux/cbq/
* Thu Mar 21 2002 Mike A. Harris <mharris> 2.2.12-8 - Updated cbq.sh to change all instances of "avpkt 1000" to "avpkt $AVPKT", and set AVPKT=3000 at top of script for enhancement request (#53904) Please test this package as soon as possible and confirm the changes work properly as expected. There were 5 places where I changed avpkt. If it works ok, we can close RAWHIDE.
I have deployed shapecfg-2.2.12-8, and tested applying shaping from 10-40Mb, and this appears to handle that entire range much better than before. Above 40Mb, it looks like things start getting unpredicatable again, so the best long-term answer is likely to be breaking out AVPKT into a sysconfig tunable, so that the packet rates can be adjusted indepenently of the actual script. Something like this, perhaps? --- /sbin/cbq Thu Mar 21 19:26:45 2002 +++ cbq Sun Mar 24 23:14:20 2002 @@ -23,7 +23,9 @@ CBQ_PATH="/etc/sysconfig/cbq" CBQ_INIT="/etc/rc.d/cbq.init" -AVPKT=3000 + +. /etc/sysconfig/cbq/avpkt +AVPKT=${AVPKT:-3000} ### Function for remove CBQ from all devices cbq_off () {
Can this be rolled into the next release?
This bug was left in MODIFIED state, and if these changes were wanted it should have been placed into ASSIGNED state. MODIFIED bugs do not get reviewed. They're either closed as RAWHIDE or some other resolution by the reporter, or re ASSIGNED by the reporter. Bugs that don't get either resolution by the reporter, are either closed RAWHIDE/ASSGINED/etc. by the QA team after some point. Now that this has been brought to my attention, it is too late in the development cycle to make the change. It should be something that gets put into a beta test round, and also needs to be in in time for our docs team to document the files in the Red Hat manuals. Changing to ASSIGNED for consideration next release.
That's a joke, right? We're talking about a 2 line patch and a sysconfig file with a sane default value in it. Should I re-open this against the limbo beta to have a better chance of getting it fixed in the near term rather than waiting another 6-12 months for the next release cycle?
No, it's not a joke. I do not monitor MODIFIED bugs. When a bug is in MODIFIED state, it is awaiting the reporter or QA to either: 1) put it into CLOSED->SOMETHING state or 2) determine it is not resolved, or needs something else done and put it back into ASSIGNED state. If a bug stays in MODIFIED, it is CLOSED for all intents and purposes and just awaiting an actual resolution. QA takes care of that. You can reopen it against limbo or whatever, but it is not happening for our final release. New files in /etc/sysconfig need to be documented by the documentation team, translated, etc. Regardless of how small and simple this 2 line patch is, it is too late to change now, and there are MUCH bigger fish to fry. I will make the change once the new development cycle picks up.
kicking priority to high since all production boxes use this and are affected by it
Updated to new cbq.init off sourceforge, and new change above made. It's built in dist-8.0.1 and currently untested. Can you test and provide go/no-go results? Setting to MODIFIED state. Thanks Andrew.
The new kernel timer resolution of HZ=1000 has made cbq able to effectively shape traffic up to 75Mbit (maybe more, we have not tested beyond that).