[ath9k-devel] Performance degradation when monitor interface is enabled

[ath9k-devel] Performance degradation when monitor interface is enabled

[Ali Abedi]

Hi,
I am writing this response to my own question since I have found a
workaround for this problem and this may help others as well.
So the problem is that if you have an interface wlan0 in managed mode
and then add another interface wlan1 in monitor mode it lowers your
outgoing throughput. It does not affect the incoming traffic though. The
trick is to add the monitor interface wlan1 then remove wlan0 by using
"iw dev wlan0 del" and then create wlan0 again. This way the incoming
and outgoing traffic is not affected by the monitor interface. This can
be caused by a bug in the driver. Those folks who know more about this
part of the driver may figure out what is going on after seeing this
solution.

Best,
Ali

On 23/10/2012 3:06 PM, Ali Abedi wrote:
> Hello,
>
> I asked this question once before but didn't get a satisfying answer. In
> our experiments, with two laptops running Ath9k driver we get about 29
> Mbps bandwidth (802.11g configuration  + UDP traffic), but when the
> monitor mode interface is enabled on the sender the throughput drops to
> 25 Mbps. This is not a performance issue. The performance is unaffected
> if monitor mode interface is enabled on the receiver (no monitor
> interface on sender). I really appropriate your answer.
>
> Regards,
> Ali Abedi
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] Performance degradation when monitor interface is enabled

[Mohammed Shafi]

On Thu, Dec 20, 2012 at 10:11 PM, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
> Hi,
> I am writing this response to my own question since I have found a
> workaround for this problem and this may help others as well.
> So the problem is that if you have an interface wlan0 in managed mode
> and then add another interface wlan1 in monitor mode it lowers your
> outgoing throughput. It does not affect the incoming traffic though. The
> trick is to add the monitor interface wlan1 then remove wlan0 by using
> "iw dev wlan0 del" and then create wlan0 again. This way the incoming
> and outgoing traffic is not affected by the monitor interface. This can
> be caused by a bug in the driver. Those folks who know more about this
> part of the driver may figure out what is going on after seeing this
> solution.

sure, lets take a look at this(new year). if its a straight forward one
we should go ahead and fix it.

>
> Best,
> Ali
>
> On 23/10/2012 3:06 PM, Ali Abedi wrote:
>> Hello,
>>
>> I asked this question once before but didn't get a satisfying answer. In
>> our experiments, with two laptops running Ath9k driver we get about 29
>> Mbps bandwidth (802.11g configuration  + UDP traffic), but when the
>> monitor mode interface is enabled on the sender the throughput drops to
>> 25 Mbps. This is not a performance issue. The performance is unaffected
>> if monitor mode interface is enabled on the receiver (no monitor
>> interface on sender). I really appropriate your answer.
>>
>> Regards,
>> Ali Abedi
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel



-- 
thanks,
shafi

[ath9k-devel] ath9k_htc and reported mactime

[Thomas Pedersen]

Hi list,

We're seeing some issue with reported mactime by the ath9k_htc (AR9271)
card. Here is a mesh node sampling peer beacons:

[  327.928774] got beacon from 00:03:7f:10:4e:1a at 80969926, now is:
80940131. offset == 29795
[  329.716530] got beacon from 64:70:02:0a:4e:a8 at 82824946, now is:
82727604. offset == 97342
[  329.974276] got beacon from 00:03:7f:10:4d:f7 at 83082820, now is:
82985314. offset == 97506
[  329.977528] got beacon from 00:03:7f:10:4e:1a at 83084622, now is:
82988562. offset == 96060
[  331.764782] got beacon from 64:70:02:0a:4e:a8 at 84774638, now is:
84775531. offset == -893
[  332.022278] got beacon from 00:03:7f:10:4e:1a at 85064980, now is:
85033000. offset == 31980
[  332.025529] got beacon from 00:03:7f:10:4d:f7 at 85033451, now is:
85036249. offset == -2798
[  333.814536] got beacon from 64:70:02:0a:4e:a8 at 86824159, now is:
86824975. offset == -816
[  334.260908] got beacon from 00:03:7f:10:4e:11 at 87270487, now is:
87271277. offset == -790
[  335.861412] got beacon from 64:70:02:0a:4e:a8 at 89100008, now is:
88871534. offset == 228474
[  336.119176] got beacon from 00:03:7f:10:4d:f7 at 89128456, now is:
89129238. offset == -782
[  336.308535] got beacon from 00:03:7f:10:4e:11 at 89317801, now is:
89318590. offset == -789
[  337.909662] got beacon from 64:70:02:0a:4e:a8 at 90951396, now is:
90919468. offset == 31928
[  338.168034] got beacon from 00:03:7f:10:4e:1a at 91209720, now is:
91177797. offset == 31923
[  338.171285] got beacon from 00:03:7f:10:4d:f7 at 91211047, now is:
91181053. offset == 29994
[  338.356286] got beacon from 00:03:7f:10:4e:11 at 91463481, now is:
91366022. offset == 97459
[  338.734784] got beacon from f8:d1:11:65:92:e4 at 91743653, now is:
91744461. offset == -808
[  339.958041] got beacon from 64:70:02:0a:4e:a8 at 92966623, now is:
92967531. offset == -908
[  340.217914] got beacon from 00:03:7f:10:4d:f7 at 93226490, now is:
93227356. offset == -866
[  340.408290] got beacon from 00:03:7f:10:4e:11 at 93449578, now is:
93417704. offset == 31874
[  342.006291] got beacon from 64:70:02:0a:4e:a8 at 95014620, now is:
95015461. offset == -841
[  342.264413] got beacon from 00:03:7f:10:4e:1a at 95272637, now is:
95273538. offset == -901
[  342.453286] got beacon from 00:03:7f:10:4e:11 at 95461607, now is:
95462386. offset == -779
[  342.833168] got beacon from f8:d1:11:65:92:e4 at 95939657, now is:
95842204. offset == 97453

The number after "at" is rx_status->mactime, "now" is drv_get_tsf(), and
offset (ie. stack delay) is mactime - tsf. RX_FLAG_MACTIME_MPDU is on for
all frames, and mesh sync is not adjusting the TSF.

How can we possibly receive frames from the future!?

Thanks in advance,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20121020/f93a87df/attachment.htm 

Re: [ath9k-devel] ath9k_htc and reported mactime

[Adrian Chadd]

Hi,


On 20 October 2012 19:32, Thomas Pedersen <thomas@cozybit.com> wrote:
> Hi list,
>
> We're seeing some issue with reported mactime by the ath9k_htc (AR9271)
> card. Here is a mesh node sampling peer beacons:
>

[snip]

> The number after "at" is rx_status->mactime, "now" is drv_get_tsf(), and
> offset (ie. stack delay) is mactime - tsf. RX_FLAG_MACTIME_MPDU is on for
> all frames, and mesh sync is not adjusting the TSF.
>
> How can we possibly receive frames from the future!?
>

1) Are you correctly merging the TSF32 values? Are you comparing TSF32
to TSF64, are you converting 32->64, etc? TSF32 wraps pretty quickly
and there's some kooky logic needed to make sure your TSF64 calculated
value is correct.

2) Are all your mesh nodes synchronised? Why don't you print out the
timestamp inside the beacon frame as well, and compare whether they're
all in reasonable sync?



Adrian

[ath9k-devel] Performance degradation when monitor interface is enabled

[Ali Abedi]

Hello,

I asked this question once before but didn't get a satisfying answer. In 
our experiments, with two laptops running Ath9k driver we get about 29 
Mbps bandwidth (802.11g configuration  + UDP traffic), but when the 
monitor mode interface is enabled on the sender the throughput drops to 
25 Mbps. This is not a performance issue. The performance is unaffected 
if monitor mode interface is enabled on the receiver (no monitor 
interface on sender). I really appropriate your answer.

Regards,
Ali Abedi

[ath9k-devel] Performance degradation when monitor interface is enabled

[Adrian Chadd]

On 23 October 2012 12:06, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
> Hello,
>
> I asked this question once before but didn't get a satisfying answer. In
> our experiments, with two laptops running Ath9k driver we get about 29
> Mbps bandwidth (802.11g configuration  + UDP traffic), but when the
> monitor mode interface is enabled on the sender the throughput drops to
> 25 Mbps. This is not a performance issue. The performance is unaffected
> if monitor mode interface is enabled on the receiver (no monitor
> interface on sender). I really appropriate your answer.

Start by looking at what's different. The only real change monitor
mode makes int he driver is fondling the RX filter.

It's possible that with monitor mode on, there's more stuff being
punted up to the driver on the receive side (all the other stuff in
the air) and that's causing things to slow down.


Adrian

[ath9k-devel] Performance degradation when monitor interface is enabled

[Ali Abedi]

Thanks Adrian. But there is no problem on the receiver side I assume 
(monitor mode is not enabled on the receiver). There are gaps between 
frames sent by the sender. It seems that the sender is waiting or doing 
something between frames (other than back-off, DIFS, ...) when the 
monitor mode is enabled on the sender.

Ali

On 10/23/2012 3:20 PM, Adrian Chadd wrote:
> On 23 October 2012 12:06, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>> Hello,
>>
>> I asked this question once before but didn't get a satisfying answer. In
>> our experiments, with two laptops running Ath9k driver we get about 29
>> Mbps bandwidth (802.11g configuration  + UDP traffic), but when the
>> monitor mode interface is enabled on the sender the throughput drops to
>> 25 Mbps. This is not a performance issue. The performance is unaffected
>> if monitor mode interface is enabled on the receiver (no monitor
>> interface on sender). I really appropriate your answer.
> Start by looking at what's different. The only real change monitor
> mode makes int he driver is fondling the RX filter.
>
> It's possible that with monitor mode on, there's more stuff being
> punted up to the driver on the receive side (all the other stuff in
> the air) and that's causing things to slow down.
>
>
> Adrian

[ath9k-devel] Performance degradation when monitor interface is enabled

[Adrian Chadd]

On 23 October 2012 13:36, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
> Thanks Adrian. But there is no problem on the receiver side I assume
> (monitor mode is not enabled on the receiver). There are gaps between frames
> sent by the sender. It seems that the sender is waiting or doing something
> between frames (other than back-off, DIFS, ...) when the monitor mode is
> enabled on the sender.

I've no idea. You can try manually overriding the RX filter register
when monitor mode is enabled. See if that fixes it.


Adrian

[ath9k-devel] Performance degradation when monitor interface is enabled

[Ali Abedi]

Thanks for the answers. The performance issue theory doesn't make sense 
as we get the same lower (and stable) throughput on different machines 
with difference CPU powers or when power saving mode is enabled/disabled 
(which changes CPU clock frequency) on this machines.
The interesting thing is that when I remove the monitor interface the 
throughput remains the same (low). Isn't this a bug?

Thanks,
Ali


On 10/23/2012 4:51 PM, Adrian Chadd wrote:
> On 23 October 2012 13:36, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
>> Thanks Adrian. But there is no problem on the receiver side I assume
>> (monitor mode is not enabled on the receiver). There are gaps between frames
>> sent by the sender. It seems that the sender is waiting or doing something
>> between frames (other than back-off, DIFS, ...) when the monitor mode is
>> enabled on the sender.
> I've no idea. You can try manually overriding the RX filter register
> when monitor mode is enabled. See if that fixes it.
>
>
> Adrian

[ath9k-devel] Performance degradation when monitor interface is enabled

[abhinav narain]

Can you elaborate on what is the bug exactly?
By this mail, you have proved; monitor mode doesn't cause any throughput
degradation !
You should see if the channel is really bad causing the throughput to go
down.
-
Abhinav Narain

On Thu, Oct 25, 2012 at 3:46 PM, Ali Abedi <a2abedi@uwaterloo.ca> wrote:

> Thanks for the answers. The performance issue theory doesn't make sense
> as we get the same lower (and stable) throughput on different machines
> with difference CPU powers or when power saving mode is enabled/disabled
> (which changes CPU clock frequency) on this machines.
> The interesting thing is that when I remove the monitor interface the
> throughput remains the same (low). Isn't this a bug?
>
> Thanks,
> Ali
>
>
> On 10/23/2012 4:51 PM, Adrian Chadd wrote:
> > On 23 October 2012 13:36, Ali Abedi <a2abedi@uwaterloo.ca> wrote:
> >> Thanks Adrian. But there is no problem on the receiver side I assume
> >> (monitor mode is not enabled on the receiver). There are gaps between
> frames
> >> sent by the sender. It seems that the sender is waiting or doing
> something
> >> between frames (other than back-off, DIFS, ...) when the monitor mode is
> >> enabled on the sender.
> > I've no idea. You can try manually overriding the RX filter register
> > when monitor mode is enabled. See if that fixes it.
> >
> >
> > Adrian
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20121025/0db3425f/attachment.htm