Hello all:
Is CBQ broken in RedHat 8.0?
It seems that my CBQ is not using priorities.
I have this setup:
Internet <-> DSL Modem <-> Linux router <-> IP Switch
<-> Laptop
The Linux computer is running a fresh, unmodified installation
of RedHat 8.0?
On the Linux computer, eth0 points to the DSL modem
and eth1 points to my internal network.
The Linux compter runs DHCP and masquerade.
I want to make sure that ssh traffic is prioritied above
all other traffic.
After reading the HOWTO and the wondershaper code, I set-up the following
tc rules on the Linux computer:
# The downlink speed, in kilobits
DOWNLINK=300
# The uplink speed, in kilobits
UPLINK=100
# The device to control
DEV=eth0
# Install the root CBQ at 1:0
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit
# Add a cbq at 1:1 to limit the total bandwidth to the uplink speed
tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit allot
1500 prio 1 bounded isolated
# Create a queue for the high priority traffic
tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit allot
1600 prio 1 avpkt 1000 bounded isolated
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
# Create a queue for the low priority traffic
tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit
allot 1600 prio 2 avpkt 1000 bounded isolated
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
# Filter ssh traffic into the high prioirty queue
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 match ip sport 22
0xffff flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 match ip dport 22
0xffff flowid 1:10
# Filter the rest of the traffic into the low priority queue, policing the
rate and dropping any overflow packets
tc filter add dev $DEV parent 1:0 protocol ip prio 13 u32 match ip dst
0.0.0.0/0 police rate $[9*$UPLINK/10]kbit burst 10k drop flowid 1:20
# Police the incoming traffic to the rate we specified
tc qdisc add dev $DEV handle ffff: ingress
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
What I am expecting from these rules is that the ssh traffic will take
complete priority over
anything else. Other traffic will only get what is left over.
To test this, I set-up a large FTP upload from my laptop to a machine over
the Internet
and then set up and ssh transfer of a large file to another machine.
After letting things settle down, I ran my traffic control script.
After a while, I ran this command to see the results:
tc -s qdisc ls dev eth0
Here is what I got:
qdisc ingress ffff: ----------------
Sent 514549 bytes 9924 pkts (dropped 0, overlimits 0)
qdisc sfq 20: quantum 1514b perturb 10sec
Sent 10522893 bytes 7296 pkts (dropped 0, overlimits 0)
backlog 5p
qdisc sfq 10: quantum 1514b perturb 10sec
Sent 7648142 bytes 5449 pkts (dropped 0, overlimits 0)
qdisc cbq 1: rate 10Mbit (bounded,isolated) prio no-transmit
Sent 18173599 bytes 12771 pkts (dropped 120, overlimits 18412)
backlog 5p
borrowed 0 overactions 0 avgidle 624 undertime 0
The low priority traffic is getting more traffic sent thru.
This is not what I wanted.
Any ideas why this is happening?
Thanks,
Neil.
--
Neil Aggarwal
JAMM Consulting, Inc. (972) 612-6056, http://www.JAMMConsulting.com
Custom Internet Development Websites, Ecommerce, Java, databases
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
When I was playing with wondershaper I ran into this too.
After reviewing the docs I think that the wondershaper merely gives certain
traffic more bandwidth, but does not prioritize it. The CBQ qdisc does not
appear to prioritize. If you reduce your uplink rate to less than your
slowest transfer speed, you should get the results you expect.
I am not sure what it would do for latency - during my testing with VoIP,
the wondershaper put packets in the right queues, but could not prevent
computer traffic from hogging the bandwidth.
What would be ideal is a bandwidth limiting CBQ qdisc encapsulating a PRIO
qdisc. I think that can only be obtained with an HBT qdisc (I would be
delighted to be corrected!). I am installing SuSE 8.1 so that I have kernel
2.4.19 which I hope will accept the HBT and tc patches (from
<http://www.docum.org>''s pointer to HBT''s home page)
better than SuSE 7.3''s
2.4.10.
If anyone has sample scripts used for prioritizing VoIP traffic over a VPN
(or over anything else), I would really appreciate a chance to see what was
done. The only way I have been able to get good VoIP quality is by reducing
the bandwidth available to everything else to unacceptably low levels.
Regards,
Robert
----- Original Message -----
From: "Neil Aggarwal" <neil@JAMMConsulting.com>
To: "LARTC Mailing List" <lartc@mailman.ds9a.nl>
Sent: Saturday, October 26, 2002 6:53 PM
Subject: [LARTC] CBQ broken in RedHat 8.0?
Hello all:
Is CBQ broken in RedHat 8.0?
It seems that my CBQ is not using priorities.
I have this setup:
Internet <-> DSL Modem <-> Linux router <-> IP Switch
<-> Laptop
The Linux computer is running a fresh, unmodified installation
of RedHat 8.0?
On the Linux computer, eth0 points to the DSL modem
and eth1 points to my internal network.
The Linux compter runs DHCP and masquerade.
I want to make sure that ssh traffic is prioritied above
all other traffic.
After reading the HOWTO and the wondershaper code, I set-up the following
tc rules on the Linux computer:
# The downlink speed, in kilobits
DOWNLINK=300
# The uplink speed, in kilobits
UPLINK=100
# The device to control
DEV=eth0
# Install the root CBQ at 1:0
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit
# Add a cbq at 1:1 to limit the total bandwidth to the uplink speed
tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit allot
1500 prio 1 bounded isolated
# Create a queue for the high priority traffic
tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit allot
1600 prio 1 avpkt 1000 bounded isolated
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
# Create a queue for the low priority traffic
tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit
allot 1600 prio 2 avpkt 1000 bounded isolated
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
# Filter ssh traffic into the high prioirty queue
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 match ip sport 22
0xffff flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 match ip dport 22
0xffff flowid 1:10
# Filter the rest of the traffic into the low priority queue, policing the
rate and dropping any overflow packets
tc filter add dev $DEV parent 1:0 protocol ip prio 13 u32 match ip dst
0.0.0.0/0 police rate $[9*$UPLINK/10]kbit burst 10k drop flowid 1:20
# Police the incoming traffic to the rate we specified
tc qdisc add dev $DEV handle ffff: ingress
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
What I am expecting from these rules is that the ssh traffic will take
complete priority over
anything else. Other traffic will only get what is left over.
To test this, I set-up a large FTP upload from my laptop to a machine over
the Internet
and then set up and ssh transfer of a large file to another machine.
After letting things settle down, I ran my traffic control script.
After a while, I ran this command to see the results:
tc -s qdisc ls dev eth0
Here is what I got:
qdisc ingress ffff: ----------------
Sent 514549 bytes 9924 pkts (dropped 0, overlimits 0)
qdisc sfq 20: quantum 1514b perturb 10sec
Sent 10522893 bytes 7296 pkts (dropped 0, overlimits 0)
backlog 5p
qdisc sfq 10: quantum 1514b perturb 10sec
Sent 7648142 bytes 5449 pkts (dropped 0, overlimits 0)
qdisc cbq 1: rate 10Mbit (bounded,isolated) prio no-transmit
Sent 18173599 bytes 12771 pkts (dropped 120, overlimits 18412)
backlog 5p
borrowed 0 overactions 0 avgidle 624 undertime 0
The low priority traffic is getting more traffic sent thru.
This is not what I wanted.
Any ideas why this is happening?
Thanks,
Neil.
--
Neil Aggarwal
JAMM Consulting, Inc. (972) 612-6056, http://www.JAMMConsulting.com
Custom Internet Development Websites, Ecommerce, Java, databases
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Sunday 27 October 2002 04:10, Robert Davidson wrote:> When I was playing with wondershaper I ran into this too. > > After reviewing the docs I think that the wondershaper merely gives certain > traffic more bandwidth, but does not prioritize it. The CBQ qdisc does not > appear to prioritize. If you reduce your uplink rate to less than your > slowest transfer speed, you should get the results you expect. > > I am not sure what it would do for latency - during my testing with VoIP, > the wondershaper put packets in the right queues, but could not prevent > computer traffic from hogging the bandwidth. > > What would be ideal is a bandwidth limiting CBQ qdisc encapsulating a PRIO > qdisc. I think that can only be obtained with an HBT qdisc (I would be > delighted to be corrected!).It can be done, but I (stil) didn''t tried it. If you read the htb pages carefully, you can get very low delays. To do so, you have to give the class a lower priority AND you have to be sure you never send more data in the class then it''s rate. (chapter 6 on the htb manual) I am installing SuSE 8.1 so that I have kernel> 2.4.19 which I hope will accept the HBT and tc patches (from > <http://www.docum.org>''s pointer to HBT''s home page) better than SuSE 7.3''s > 2.4.10.Why upgrading your SUSE? You can also download 2.4.19 from ftp.kernel.org and patch with the lates htb patch ??> If anyone has sample scripts used for prioritizing VoIP traffic over a VPN > (or over anything else), I would really appreciate a chance to see what was > done. The only way I have been able to get good VoIP quality is by reducing > the bandwidth available to everything else to unacceptably low levels.I know a lot of people are trying it, but I have no such script. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
how can we do to assign flows in the shaping rules to an AS number in BGP routing? I want to allocate some of my bandwidth for the local internet exchange, which is BGP routed. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Sunday 27 October 2002 04:09, Stef Coene wrote:>Why upgrading your SUSE? You can also download 2.4.19 from ftp.kernel.org > and patch with the lates htb patch ??What better way to support the distro I know how to use and avoid hairy compiling problems? SuSE has 7.3 kernel rpms available for 2.4.16, but not 2.4.17, so I decided to go ahead. It is just a test server in any case - no worrying about reconfiguring. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> >Why upgrading your SUSE? You can also download 2.4.19 fromftp.kernel.org> > and patch with the lates htb patch ??I find that inserting a stock kernel into a machine originally running a distro (RH, Mandrake etc) is often a painful and unrewarding experience. My personal preference these days is to get the source RPM for the kernel for the target distro. Then modify the spec file to patch the kernel the way I want it (e.g. Mandrake 8.2 you must _remove_ the HTB2 patches, and add the HTB3 patches and the IMQ patches). Build the RPM and you now have a way to upgrade the kernel and modules on any machine running that distro, guaranteed to work with the user space code, since the kernel is identical to what was there before, modulo the desired patches. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hello, On Sun, 27 Oct 2002 09:23:52 -0800, "David Boreham" <david_list@boreham.org> wrote:> > >Why upgrading your SUSE? You can also download 2.4.19 from > ftp.kernel.org > > > and patch with the lates htb patch ?? > > I find that inserting a stock kernel into a machine originally > running a distro (RH, Mandrake etc) is often a painful and > unrewarding experience.That is only true for distros that do heavy patching of stock kernels, which is bad IMHO. For example Debain only patches the kernel to fix bad bugs discovered after kernel release and to exclude non-free data from kernel. Thus the stock kernel works perfectly fine on a Debian system AND if you run unstable you can get Debian versions of kernels in few days after kernel release. -- Best regards, Aigars Mahinovs mailto:aigarius@debian.org #--------------------------------------------------# | .''''`. | | : :'' : Debian GNU/Linux | | `. `'' http://www.debian.org | | `- | #--------------------------------------------------#