[Click] buffersizes

Peter De Cleyn peter.decleyn at gmail.com
Mon Mar 6 13:46:20 EST 2006


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
>
>
>


More information about the click mailing list