All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helmut Schaa <helmut.schaa@googlemail.com>
To: David Ellingsworth <david@identd.dyndns.org>
Cc: rt2x00 Users List <users@rt2x00.serialmonkey.com>,
	wireless <linux-wireless@vger.kernel.org>
Subject: Re: rt61pci AP performance issues
Date: Mon, 5 Jul 2010 08:14:07 +0200	[thread overview]
Message-ID: <201007050814.07863.helmut.schaa@googlemail.com> (raw)
In-Reply-To: <AANLkTikRH3YEoZ47ihcZyqBiwfxdBPAEgZdAzAWES8x-@mail.gmail.com>

Am Dienstag 29 Juni 2010 schrieb David Ellingsworth:
> I haven't conducted any other tests beyond what was bisected in the
> attached log. Performance across all those revisions remained somewhat
> fast, and my markings were based solely on client link failure. Each
> bad commit resulted in the link failing after about 10s while
> transferring a file. At which point, the transfer would stop, the AP
> would be unreachable via pings, but the client remained associated to
> the AP. About 30s after that point, the client would timeout and
> re-associate to the AP reactivating the link.

Could you please check if the queues get stuck in that situation? I was
able to sometimes observe queues getting stuck on rt2800.

Just do the following (on the AP mode machine):

mount -t debugfs none /sys/debug
cat /sys/debug/ieee80211/phy0/queues

That should give you something like:

00: 0x00000000/0
01: 0x00000000/0
02: 0x00000000/0
03: 0x00000000/0

And if there's somewhere a 1 instead of a 0 it means that this queue is
stopped (which can/and must actually happen in some scenarios without
causing problems). If that 1 stays there for longer that means something
didn't start the queue anymore and your connection is most likely stuck.

Helmut

      reply	other threads:[~2010-07-05  6:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-18 18:02 rt61pci AP performance issues David Ellingsworth
2010-06-29 16:55 ` David Ellingsworth
2010-07-05  6:14   ` Helmut Schaa [this message]

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=201007050814.07863.helmut.schaa@googlemail.com \
    --to=helmut.schaa@googlemail.com \
    --cc=david@identd.dyndns.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=users@rt2x00.serialmonkey.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.