[Click] buffersizes

[Wenjun Hu]

In most cases (Certainly in all the experiments I've done), only queue 1 is used (for best effort traffic, i.e., typical Internet traffic). You can check by adding some logging statement in ath_tx_draintxq() to print out txq->axq_qnum, the queue number. I'm not sure how things stand if other hw queues are involved.

Also, I have the impression that queue interactions may be more complicated with userlevel click because the 'bottleneck' may be present in both the user space queue(s) and kernel queues. But I don't know this part very well myself.  

Wenjun

> This sure gives me a lot of things to try! Thanks a lot, Wenjun!
> 
> I also noticed from the syslog output, that the madwifi driver uses various
> queues:
> 
> ath0: Use hw queue 1 for WME_AC_BE traffic
> ath0: Use hw queue 0 for WME_AC_BK traffic
> ath0: Use hw queue 2 for WME_AC_VI traffic
> ath0: Use hw queue 3 for WME_AC_VO traffic
> ath0: Use hw queue 8 for CAB traffic
> ath0: Use hw queue 9 for beacons
> 
> Would it be possible to address them from click? Maybe by changing the
> ToDevice element and adding some parameters to the raw packet socket? I'm
> not really familiar with this level of programming. I'm using click in
> userlevel, I'm not sure if this limits my possibilities.
> 
> thanks again for the input!
> 
> Peter
> 
> On 3/6/06, Wenjun Hu <Wenjun.Hu at cl.cam.ac.uk> wrote:
> >
> > A few things to try:
> >
> > Assuming your wireless interface is called ath0,
> >
> > ifconfig ath0 txqueuelen 1
> > ifconfig ath0raw txqueuelen 1 (if you're using the raw device)
> >
> > Then in if_athvar.h within the madwifi source code, there's a constant
> > called
> > ATH_TXBUF that's probably set to 200. That's the default value for
> > txqueuelen
> > when you load the driver module. You could reduce this number, but beware
> > that
> > it might cause packet (frame) drops on the card if you make it too small.
> >
> > There's also a linked list structure in the driver (e.g., you'll see
> > netif_wake_queue and netif_sleep_queue in a few functions in if_ath.c)
> > that
> > contains frames to be sent. You could make sure there's only ever one
> > frame in
> > the list (i.e., call sleep queue as soon as one frame is there), but this
> > could cause a lot of interrupts, and I'm not sure about the general
> > implications for performance.
> >
> > If your packets will go through some socket buffer in the kernel, then you
> > might want to change the size of that too.
> >
> > There's probably some buffer on the card too, but you probably can't
> > change
> > that unless you can access the firmware.
> >
> > Hope this helps,
> >
> > Wenjun
> >
> >
> > > Hello list,
> > >
> > > Not really a Click issue, but maybe you came across the same problem.
> > >
> > > I'm using 2 queues in a script and merge them with a priorityscheduler.
> > The
> > > high priority queueu will contain L2 management packets (beacons, asso
> > reqs
> > > etc) while all other traffic will pass the low priority queue.
> > >
> > > The problem I encounter now is that packets will be delivered to the
> > device
> > > and will be queued there (in the driver/kernel ?) too. So I can only
> > > prioritize the management packets to a certain extend. I suppose I could
> > > iptimize things if I could cut the buffers outside of Click to size one,
> > > thus forcing the FromDevice only to pull from the queue when a packet
> > has
> > > been send and as a consequence doing all buffering inside click.
> > >
> > > Does anyone know how I could do this? I'm using the madwifi driver , but
> > > maybe there are also some general kernel networking parameters to
> > change.
> > >
> > > Any suggestions are welcome!
> > >
> > > Peter De Cleyn
> > > _______________________________________________
> > > click mailing list
> > > click at amsterdam.lcs.mit.edu
> > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> >
> >
> >
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click