From: Marlon Smith <marlon.smith10@gmail.com>
To: Ben Greear <greearb@candelatech.com>, linux-wireless@vger.kernel.org
Subject: Re: Strange performance issue when using two devices at once
Date: Thu, 30 Jan 2020 09:43:59 -0500 [thread overview]
Message-ID: <1580395439.26012.75.camel@gmail.com> (raw)
In-Reply-To: <c8788984-3de0-b41c-e2a1-66b67d0674a6@candelatech.com>
On Wed, 2020-01-29 at 12:01 -0800, Ben Greear wrote:
> On 1/29/20 11:48 AM, Marlon Smith wrote:
> >
> > On Wed, 2020-01-29 at 11:27 -0800, Ben Greear wrote:
> > >
> > > On 1/29/20 11:22 AM, Marlon Smith wrote:
> > > >
> > > >
> > > > On Wed, 2020-01-29 at 10:42 -0800, Ben Greear wrote:
> > > > >
> > > > >
> > > > > On 1/29/20 10:39 AM, Marlon Smith wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > I have two RT5370 devices connected to the same access
> > > > > > point.
> > > > > > Both
> > > > > > devices are very slow, but the instant I disconnect one
> > > > > > device,
> > > > > > the
> > > > > > other speeds up by a factor of 10.
> > > > > Out of curiosity, are both of the RT5370 used on the same
> > > > > client
> > > > > device?
> > > > > >
> > > > > >
> > > > > > Did you check that they have unique MAC addresses?
> > > > > > Thanks,
> > > > > Ben
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > The really strange part is that one device will perform
> > > > > > slowly
> > > > > > even
> > > > > > if
> > > > > > the other device is basically idle! I've confirmed this
> > > > > > with a
> > > > > > packet
> > > > > > sniffer.
> > > > > >
> > > > > > I've been trying to do some debugging, and I've found that
> > > > > > when
> > > > > > both
> > > > > > devices are connected to the access point, they report a
> > > > > > large
> > > > > > number
> > > > > > of duplicate frames. I added some debug output
> > > > > > in ieee80211_rx_h_check_dup() to confirm that this only
> > > > > > happens
> > > > > > while
> > > > > > both devices are connected. The packet sniffer also shows a
> > > > > > large
> > > > > > number of retries while this is occurring.
> > > > > >
> > > > > > Using backports 5.3-rc4 for this, but also tested on 4.14-
> > > > > > rc2.
> > > > > >
> > > > > > I did post about this previously on this mailing list
> > > > > > (RT5370
> > > > > > performance issues), but I thought I'd post again with this
> > > > > > new
> > > > > > information and more descriptive title. I'm a little bit
> > > > > > stuck
> > > > > > on
> > > > > > this
> > > > > > for a while now, so any ideas are much appreciated.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > Marlon
> > > > > >
> > > > They are on separate devices, although the mac addresses are
> > > > close.
> > > > 70:F1:1C:2E:AF:B4 and
> > > > 70:F1:1C:2E:AF:B6.
> > > >
> > > > However, I have a third device 70:F1:1C:2E:AF:BB which performs
> > > > well
> > > > and does not affect the performance of the other two.
> > > >
> > > Have you tried a different AP?
> > >
> > > And also tried using the exact same MAC addresses configured on a
> > > different
> > > radio (like ath9k)?
> > >
> > > Thanks,
> > > Ben
> > >
> > >
> > I have tried a different access point in a different environment
> > but no
> > luck. I'll see if I can configure my laptop to use one of the
> > problematic devices' mac address.
> It might be tricky to determine, but if you can notice whether one of
> your station devices
> is (block-)acking the other's frames, that would be a good clue that
> it is a station
> side bug. A carefully inspected sniff, especially if you can put
> sniffer near one station
> and far from the other and so use RSSI as a sorting factor, should
> allow you to determine
> this.
>
> Thanks,
> Ben
>
>
So I did a few tests and got some pretty interesting results.
With the two devices connected to the access point and performing
slowly, I changed the MAC address of one of the devices (Just from a B6
to a BA). Immediately, both devices began working properly!
Back to the original MAC address, I looked at my sniffer, and I do not
see any evidence of one device acking another device's frames. With one
device sitting idle and the other transferring data, I see high numbers
of retransmitted frames, and then an eventual ack from the correct
device, but very little activity from the idle device. While this is
happening, the device driver indicates that it is dropping lots of
duplicate received packets.
next prev parent reply other threads:[~2020-01-30 14:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-29 18:39 Strange performance issue when using two devices at once Marlon Smith
2020-01-29 18:42 ` Ben Greear
2020-01-29 19:22 ` Marlon Smith
2020-01-29 19:27 ` Ben Greear
2020-01-29 19:48 ` Marlon Smith
2020-01-29 20:01 ` Ben Greear
2020-01-29 20:49 ` Marlon Smith
2020-01-30 14:43 ` Marlon Smith [this message]
2020-01-30 15:32 ` Felix Fietkau
2020-01-30 16:04 ` Marlon Smith
2020-01-30 14:55 ` Jean-Pierre TOSONI
2020-01-30 15:26 ` Marlon Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1580395439.26012.75.camel@gmail.com \
--to=marlon.smith10@gmail.com \
--cc=greearb@candelatech.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).