Oh, I found the 'bssid' option.
Try something like 'ifconfig wlanX create wlanmode hostap bssid mode 11g...'
See if the MAC addresses for each are different.
If you still see the "Discard message X" then that's an orthogonal
issue which we need to diagnose. I don't see that in my testing.
Ad
Hi,
In my recent ibss 11n work I made it automagically promote the channel
selection to an 11n channel. For non-11n IBSS nodes that's ok - they
won't negotiate 11n and they'll transmit at legacy rates.
However, this broke TDMA. TDMA came up fine (AR5416<->AR9280) but
traffic suffered. It's becaus
Right, but you're likely seeing a different issue to "hardware TXQ is stuck."
I think we've solved that. What we're likely seeing now is some odd
buffer exhaustion issues that I haven't yet seen in the driver. -HEAD
is supposed to be limiting how many ath_buf's are queued per node
_just_ so this
Hello, Adrian.
You wrote 19 мая 2013 г., 21:38:21:
AC> Compile up athratestats.
Ok, Now I can not reproduce problem without rebooting router. It
seems, that as it "pickup" N rates once, they work, even if client
was pgysically power-cycled. Reboot of router/AP "helps".
This time working sen
Well even if that is true, the 300mbit transmit rate isnt related to that.
Compile up athratestats.
Adrian
On May 19, 2013 1:35 PM, "Lev Serebryakov" wrote:
> Hello, Adrian.
> You wrote 19 мая 2013 г., 21:05:13:
>
> AC> No, the driver drops frames only on error and otherwise it sends
> ENOBUFS
Hello, Adrian.
You wrote 19 мая 2013 г., 21:05:13:
AC> No, the driver drops frames only on error and otherwise it sends ENOBUFS up
AC> to the nrt layer. This stalls the sender.
Hmmm... I remember thread about it inn net@ several years ago, and
as far as I remember it was said, that UDP never s
No, the driver drops frames only on error and otherwise it sends ENOBUFS up
to the nrt layer. This stalls the sender.
Check athratestats in tools/ath. See what the stats are during transmit.
Adrian
Adrian
On May 19, 2013 11:54 AM, "Lev Serebryakov" wrote:
> Hello, Adrian.
> You wrote 19 мая 20
Hello, Adrian.
You wrote 19 мая 2013 г., 19:49:48:
AC> Ok. So the hardware queue isnt hung. Good!
AC> The 30mbit is the transmit rate, not throughput. No idea why is isnt
AC> downgrading though.
300! It doesn't downgrading, because it is UDP and it is FreeBSD --
Linux blocks sendto() on UDP so
Ok. So the hardware queue isnt hung. Good!
The 30mbit is the transmit rate, not throughput. No idea why is isnt
downgrading though.
So lets do more testing to aee if the transmit queue stalls. Also, we can
diagnose the disassociate at some point. Then after that, rate control.
But woo!
Adrian
O
Hello, Adrian.
You wrote 19 мая 2013 г., 18:37:39:
AC> ... wait, so now you're saying the transmit doesn't stop, it just slows
down?
Previous tests looks like this:
Time|Sender (AP)|Receiver (client)
400 |300| 25
401 |300| 24
402 |300|
Hello, Adrian.
You wrote 19 мая 2013 г., 18:37:39:
AC> ... wait, so now you're saying the transmit doesn't stop, it just slows
down?
On transmission side (AP, where reported bandwidth is bogus, as it
shows configured 300Mbit no matter what is real bandwidth, it is
UDP!) its slows down (shows 2
... wait, so now you're saying the transmit doesn't stop, it just slows down?
Adrian
On 19 May 2013 03:10, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 19 мая 2013 г., 4:19:22:
>
> AC> I've gone and hacked on the TX path code a bunch more. I'd appreciate
> AC> it if people would give
Hello, Adrian.
You wrote 19 мая 2013 г., 4:19:22:
AC> I've gone and hacked on the TX path code a bunch more. I'd appreciate
AC> it if people would give it a good thrashing in STA and hostap modes.
Ok, situation somewhat changed.
Now "iperf" on receiver side doesn't freeze forever, but continue
13 matches
Mail list logo
