Hello, Adrian.
You wrote 28 мая 2013 г., 2:15:28:
AC And as always, please keep retesting whenever you csn.
I'm trying to test every bunch of changes in ath (I do daily svn up
and watch for changes in ath*), but no more often than 1 per day, and
sometimes don't spent my time at computer on
Hello, Adrian.
You wrote 27 мая 2013 г., 11:29:29:
AC Would you mind re-testing with what's now in -HEAD?
I've built new firmware already and I'll give it try tonight :)
AC I'm glad that we're now not seeing any stuff hangs issues; but now
AC we need to sit down and fix the rekeying fails
Hello, Adrian.
You wrote 27 мая 2013 г., 11:29:29:
AC Would you mind re-testing with what's now in -HEAD?
Ok, now I can not force connection NOT TO PICK UP n-rates (without
disabling N on sever or client).
Performance is better, than usual (150-180Mbit/s UDP), and SOMETIMES
here are such
Sweet. I think the problem getting n rates here are likely due to buffer
starvation when queuing the addba request or response frames.
So I still have to properly fix that. But it'll happen.
Cool, keep testing!
Adrian
Sent from my Palm Pre on ATamp;T
On May 27, 2013 5:02 PM, Lev
On 27 May 2013 14:22, Lev Serebryakov l...@freebsd.org wrote:
Hello, Adrian.
You wrote 28 мая 2013 г., 1:10:33:
AC Sweet. I think the problem getting n rates here are likely due to
AC buffer starvation when queuing the addba request or response frames.
AC So I still have to properly fix
And as always, please keep retesting whenever you csn.
I'm going to spend some time now tidying up the tx path, fixing lock deadlocks
in various places, fixing rate control and some other ancilliary stuff. So nows
the time to properly thrash things.
Now, we should try to get even more users
Hello, Adrian.
You wrote 20 мая 2013 г., 0:27:52:
AC Right, but you're likely seeing a different issue to hardware TXQ is
stuck.
AC I think we've solved that. What we're likely seeing now is some odd
AC buffer exhaustion issues that I haven't yet seen in the driver. -HEAD
AC is supposed to be
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 to
... wait, so now you're saying the transmit doesn't stop, it just slows down?
Adrian
On 19 May 2013 03:10, Lev Serebryakov l...@freebsd.org 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
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
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
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
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
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 l...@freebsd.org wrote:
Hello, Adrian.
You wrote 19 мая 2013 г., 21:05:13:
AC No, the driver drops frames only on error and otherwise it sends
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 sender
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
Hi,
I've gone and hacked on the TX path code a bunch more. I'd appreciate
it if people would give it a good thrashing in STA and hostap modes.
I'll test out STA, HOSTAP and TDMA modes sometime tomorrow and Monday.
Also, I found something new - the clone mechanism can optionally use
new mac
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs -fdiagnostics-show-option
On Sat, May 18, 2013 at 8:51 PM, Adrian Chadd adr...@freebsd.org wrote:
Hm. Ok ill fix that. Ta!
Thanks
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to
Just fixed this one in -HEAD too.
thanks!
Adrian
On 18 May 2013 18:03, Outback Dingo outbackdi...@gmail.com wrote:
On Sat, May 18, 2013 at 8:54 PM, Outback Dingo outbackdi...@gmail.com
wrote:
On Sat, May 18, 2013 at 8:51 PM, Adrian Chadd adr...@freebsd.org wrote:
Hm. Ok ill fix
20 matches
Mail list logo
