From: Thingly Transparence (sqrt_1_at_yahoo.com)
Date: 2002-03-23 08:28:35 UTC
I figured out what was going on. First off, the high latencies were occurring in AP-AP communication as well as AP->client communications.
The CNFMULTICASTPMBUFFERING rid is set to 1 by default. The effect of this is that multicast / broadcast MAC frames are buffered for transmission after DTIM. If this is set to 0, the frames are directly placed in the output queue.
The CNFOWNDTIMPERIOD rid was set to 3 and the
CNFBEACONINT was set to 100 (ms). So the card was
sleeping for 300 ms in between sending
multicast/broadcast frames. It lets bcast frames pile up for 300 ms, checks in, sends off all
multi/broadcast frames queued for transmission, then goes back to waiting for another 300 ms.
I changed the DTIMPERIOD to 1 and noticed a 3x improvement in latencies on broadcasts (to other APs as well as to clients).
What I think would be a better solution for me is to
set CNFMULTICASTPMBUFFERING to 0, which puts the
broadcast frames directly in the output queue. When I
tried to do this using hfa384x_cmd(), I got the
following error message:
wlan0: CMD=0x0121 => res = 0x7f, resp0 = 0x0004 wlan0: hfa384x_set_rid: CMDCODE_ACCESS_WRITE failed (res=127)
I also noticed that under /proc/net/prism2/wlan0/rids the CNFMULTICASTPMBUFFERING rid shows a read error.
Any ideas on how to set this rid?