Johannes Stezenbach <js@xxxxxxxxx> writes: > On Wed, Feb 02, 2011 at 07:42:51PM +0200, Kalle Valo wrote: >> So the firmware/hardware doesn't have support for tracking and waking >> up for beacons? I didn't even know that such hardware exists :) Waking >> up for beacons from host sounds very inefficient and unrealiable. All >> the devices I have seen either do this in firmware or hardware due to >> time constraints. Even at76c50x-usb, which is ancient, does all this >> in firmware. > > IMHO this is a bit exaggerated. Ok, you have a point that maybe I was exaggerating a bit too much. > Given that the beacon interval is typically ~100 msecs, and typical > worst cast irq latencies on Linux 2.6 are a few 100 usecs, we can > sleep e.g. 90msecs and wake up in time to catch the beacon with high > probability, thus saving 90% on PHY power. Not perfect, but good > enough, isn't it? But it's not only about irq latency. If we would implement this in mac80211 at least one context switch is involved before the beacon is processed. Also driver might create more latency. And then there's waking up chip from the sleep mode, that usually takes time. And what happens when the host is under severe load? I just think that there is just too much ucertainty here and I don't trust this to be reliable. So I have my concerns if it really makes sense to implement this in mac80211. Extra complexity (and extra maintenance) for two sub-optimal (from power save point of view) hardware. (dropping rt2x00 list because it spams me about not being subscribed) -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
