All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helmut Schaa <helmut.schaa@googlemail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, Ivo van Doorn <ivdoorn@gmail.com>,
	Gertjan van Wingerde <gwingerde@gmail.com>
Subject: Re: rt2x00 & mac80211: correct usage of ieee80211_beacon_get_tim?
Date: Fri, 2 Jul 2010 19:59:45 +0200	[thread overview]
Message-ID: <201007021959.45704.helmut.schaa@googlemail.com> (raw)
In-Reply-To: <1278090770.15412.4.camel@jlt3.sipsolutions.net>

Am Freitag 02 Juli 2010 schrieb Johannes Berg:
> On Sun, 2010-06-27 at 21:00 +0200, Helmut Schaa wrote:
> 
> > rt2x00 pulls every beacon. But not directly _prior_ to transmission as the 
> > hw lacks an interrupt for that. Instead the next beacon gets pulled _after_
> > the beacondone interrupt (which is obviously triggered directly after the
> > beacon was sent). So, all TIM changes that happen during the next beacon
> > interval won't be included in the next beacon. Hence, rt2x00 also implements
> > the set_tim callback and updates the beacon through these as well.
> > 
> > This gives us a correct TIM but as I explained earlier breaks the DTIM
> > count (and thus bc/mc buffering which is done in mac80211 fot rt2x00).
> > 
> > One possible option to fix this in rt2x00 would be to delay the beacon
> > update (as it is already put on a workqueue we could simply replace it by
> > a delayed work) by beaconinterval - 10ms or something. But I'm not how
> > accurate that would be (and of course remove the set_tim callback).
> 
> Well, after a beacon is before a beacon.

Yes ;)

> I think iwlwifi also pulls the
> next beacon after the previous one was sent. That just means you get a
> potential higher delay, 

Agreed.

> but otherwise it doesn't really matter that
> much. You'll never be able to close the race fully anyway,

No, but I'd like to get as close as possible. The idea with the delayed
work was intended to reduce the latency as good as we can.

> unless your
> device itself is capable of generating the TIM IE _right before_ the
> beacon gets transmitted.

Agreed. At least on rt2800 we can use the pre tbtt interrupt to update the
beacon just before it is sent out.

> Therefore, with standard beacon intervals of 100 TU, I don't think it
> matters all that much whether it's before or after?

Yeah, maybe that's just fine. I guess I'll just drop the set_tim callback
from all rt2x00 pci variants and implement the pre tbtt interrupt on rt2800.

Thanks,
Helmut

  reply	other threads:[~2010-07-02 18:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-24 13:21 rt2x00 & mac80211: correct usage of ieee80211_beacon_get_tim? Helmut Schaa
2010-06-24 14:32 ` John W. Linville
2010-06-24 15:51 ` Johannes Berg
2010-06-24 15:53   ` Johannes Berg
2010-06-24 15:54     ` Johannes Berg
2010-06-24 16:20   ` Helmut Schaa
2010-06-25 16:01   ` Helmut Schaa
2010-06-26 15:32     ` John W. Linville
2010-06-27  8:21     ` Johannes Berg
2010-06-27 19:00       ` Helmut Schaa
2010-07-02 17:12         ` Johannes Berg
2010-07-02 17:59           ` Helmut Schaa [this message]
2010-07-02 18:06             ` Johannes Berg
2010-07-02 18:20               ` Helmut Schaa

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=201007021959.45704.helmut.schaa@googlemail.com \
    --to=helmut.schaa@googlemail.com \
    --cc=gwingerde@gmail.com \
    --cc=ivdoorn@gmail.com \
    --cc=johannes@sipsolutions.net \
    --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 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.