RE: [LARTC] Question on prio qdisc

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you Lars and Wing for your responses.

I just ran another experiment using RED on the
lowest priority flow as suggested by Wing. I had
used RED before (on all flows) without success.
In this experiment, specified a large queue size for the interface.
In this case the result was roughly the same.
I overloaded the interface with 9.5 Mb/s of 
flow with 8 Mb/s at the lowest priority, 1 Mb/s
at the medium priority, and 0.5 Mb/s at the highest
priority hoping that RED would discard lowest
priority packets to make room for the higher priority
packets. The result was that all flows suffered
approximately the same packet loss rate (about 45%).
The interface was an 802.11b interface at 11 Mb/s
with the two nodes very close to each other so that
link quality was very high. Apparently RED does not
discard the lowest priority packets that are overloading
the interface. The following script was
used:

#############
tc qdisc add dev wlan0 root handle 1: prio
tc qdisc add dev wlan0 parent 1:3 handle 30: red min 4000 max 8000 burst 5 limit
18000 avpkt 1000 probability 0.2

ifconfig wlan0 txqueuelen 10000
###############################

My next step will be to modify the enqueue function to call
prio_drop() if there is not enough room to enqueue a new
packet as you have both suggested. I will have to get some help
for this from some of our engineers that can understand the code
better than I could.

Thanks for the help!

Bibb Cain







-----Original Message-----
From: Lars Landmark [mailto:larslan@xxxxxxxxxxxxxxx]
Sent: Wednesday, July 02, 2003 12:42 PM
To: Cain, Joseph
Cc: lartc
Subject: Re: [LARTC] Question on prio qdisc


On Wed, 2 Jul 2003, Cain, Joseph wrote:

> 
> I have been doing some experiments with the 
> prio qdisc. I haven't tried to understand the
> code, but the behavior I have observed in the
> experiments leads me to believe that the prio
> qdisc operates in the following manner when the
> interface queue is full:
> 1) Suppose that we are operating with the default
> 3 priority bands and the interface queue is full
> of packets of the lowest priority (indicated by the
> TOS byte).
> 2) Then suppose a new packet of highest priority is to be 
> sent to the interface for queuing.
> 3) It appears to me that the newly arriving packet of 
> highest priority will be dropped because the queue is
> full. Prio does not appear to drop one of the lower priority
> packets waiting in the queue to make room for the 
> higher priority packet.
> 
> The evidence for this conclusion is that I can set the
> "txqueuelen" to a large value to make ample room for 
> queuing high priority packets. Then if the interface 
> is sent a mixture of an overload of low priority
> packets and a small load of high priority packets, the
> high priority packet suffer just as high a packet loss
> percentage as the low priority packets. To me this indicates
> that they are getting dropped at the interface because the
> queue is full.

In prio_init(), a FIFO queue is establish for each of these 
three bands.  I thought that each of these FIFO queues could occupy 
txqueuelen packages.  According to you, this is not true.  however if your 
assumption is right, and you want to achieve dropping low priority package 
if high priority package is entering, then you could just make a small 
extension to the prio_enqueue code in linux/net/sched/sch_prio.c.   

Class/band 0 has highest priority. If you unsuccessfully try to enqueue a 
package to this class, you could make a call to prio_drop(). 
This function drop the package from lowest priority class, that has a package.
When returning from this function, there should be enough place to your high 
priority package.  Try now to enqueue this package once more, 
and you should be done.  Hopefully this will work. But it will work only if 
Linux only count packages and do not count how many bytes each of these 
FIFO queue holds.


Lars


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux