Bug 53904 - /sbin/cbq avgpkt defaults are too low
Summary: /sbin/cbq avgpkt defaults are too low
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: shapecfg   
(Show other bugs)
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2001-09-21 05:24 UTC by Need Real Name
Modified: 2007-03-27 03:48 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-23 16:43:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2001-09-21 05:24:26 UTC
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:

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.

Comment 1 Mike A. Harris 2002-01-25 17:59:31 UTC
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

Comment 2 Need Real Name 2002-01-25 19:22:12 UTC
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
which points to ftp://ftp.equinox.gu.net/pub/linux/cbq/

Comment 3 Mike A. Harris 2002-03-22 00:26:54 UTC
* Thu Mar 21 2002 Mike A. Harris <mharris@redhat.com> 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.

Comment 4 Need Real Name 2002-03-25 04:21:47 UTC
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 @@
+. /etc/sysconfig/cbq/avpkt
 ### Function for remove CBQ from all devices
 cbq_off () {

Comment 5 Need Real Name 2002-07-30 02:29:13 UTC
Can this be rolled into the next release?

Comment 6 Mike A. Harris 2002-07-30 02:37:17 UTC
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.

Comment 7 Need Real Name 2002-07-30 16:32:41 UTC
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?

Comment 8 Mike A. Harris 2002-08-08 10:58:30 UTC
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


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.

Comment 9 Cristian Gafton 2002-10-02 20:19:05 UTC
kicking priority to high since all production boxes use this and are affected by it

Comment 10 Mike A. Harris 2002-10-04 03:35:38 UTC
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.

Comment 11 Need Real Name 2003-06-23 16:43:13 UTC
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).

Note You need to log in before you can comment on or make changes to this bug.