Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-27 Thread Lev Serebryakov
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 wee

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-27 Thread Adrian Chadd
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 onb

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-27 Thread Adrian Chadd
On 27 May 2013 14:22, Lev Serebryakov 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 that. But it

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-27 Thread Lev Serebryakov
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 that. But it'll happen. Cool! It is not show-stopper and could be d

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-27 Thread Adrian Chadd
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 AT&T On May 27, 2013 5:02 PM, Lev Serebryakov

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-27 Thread Lev Serebryakov
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 mess

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-27 Thread Lev Serebryakov
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 fa

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-27 Thread Adrian Chadd
Hi, Would you mind re-testing with what's now in -HEAD? I have some rate control fixes to go in soon but other than that I'd just like to concentrate on tidying up loose ends and improving stability. I'm glad that we're now not seeing any "stuff hangs" issues; but now we need to sit down and fix

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-20 Thread Lev Serebryakov
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

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-19 Thread Adrian Chadd
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

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-19 Thread Lev Serebryakov
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

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-19 Thread Adrian Chadd
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

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-19 Thread Lev Serebryakov
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

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-19 Thread Adrian Chadd
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

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-19 Thread Lev Serebryakov
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

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-19 Thread Adrian Chadd
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

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-19 Thread Lev Serebryakov
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|

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-19 Thread Lev Serebryakov
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

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-19 Thread Adrian Chadd
... 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

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-19 Thread Lev Serebryakov
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

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-18 Thread Adrian Chadd
Just fixed this one in -HEAD too. thanks! Adrian On 18 May 2013 18:03, Outback Dingo wrote: > > > > On Sat, May 18, 2013 at 8:54 PM, Outback Dingo > wrote: >> >> >> >> >> On Sat, May 18, 2013 at 8:51 PM, Adrian Chadd wrote: >>> >>> Hm. Ok ill fix that. Ta! >>> >>> Thanks > > Heres another

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-18 Thread Outback Dingo
On Sat, May 18, 2013 at 8:54 PM, Outback Dingo wrote: > > > > On Sat, May 18, 2013 at 8:51 PM, Adrian Chadd wrote: > >> Hm. Ok ill fix that. Ta! >> Thanks >> > Heres another cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-18 Thread Outback Dingo
On Sat, May 18, 2013 at 8:51 PM, Adrian Chadd 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 "freebsd-wireless-unsubs

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-18 Thread Adrian Chadd
Hm. Ok ill fix that. Ta! On May 18, 2013 8:33 PM, "Outback Dingo" wrote: > 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

Re: [rft] please test -HEAD ath; lots of TX changes

2013-05-18 Thread Outback Dingo
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 -Wno-error-tautological-compar

[rft] please test -HEAD ath; lots of TX changes

2013-05-18 Thread Adrian Chadd
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 add