Skip to content

Two Interfaces Power Save

Jump to bottom
doru91 edited this page Feb 14, 2017 · 19 revisions

Power Save support for two virtual interfaces

ath9k_htc does not have PS support for multiple interfaces. Once the second virtual interface is created, PS is automatically disabled and the card is always in the 'AWAKE' state:

The MultiWiFi PS algorithm that I implement is split in two sections:

  • a mac80211 generic section which is responsible for sending the NULL frames
  • a ath9k_htc specific section that is responsible for waking up the WiFi card for RX traffic

mac80211 algorithm

mac80211: Add PS support for multiple interfaces With this commit, PS support is limited to a maximum of 2 interfaces.

Behaviour:

  • when the STA receives a directed TIM for one of the interfaces it will send 2 NULL functions (PS = 1), one on each interface (see ieee80211_rx_mgmt_beacon)
  • we keep a single timer (dynamic_ps_timer) that schedules the tasklet for enabling PS. Timeout for this timer expires when no data is sent on both interfaces
  • when the tasklet for enabling PS mode is scheduled (dynamic_ps_enable_work) it will first send 2 NULL functions (PS = 0), one on each interfaces. Afer both NULL functions are ACK'ed, mac80211 requests the driver to put the wifi card in sleep mode. This is the first version, we need a lot of improvements regarding the locking scheme.

ath9k_htc algorithm

ath9k_htc: add PS support

Power Save support for ath9k_htc is centered around waking up the card for RX traffic. This is achieved using hardware timers that are armed each time we receive a beacon from one of the APs.

Limitations:

  • 2 vifs;
  • same channel;
  • DTIM count = 2 for both APs.

Bugs:

  1. there are cases when the NULL function is not ACK'ed for the second vif and this prevents the wifi card from entering PS mode. After PS is enabled (iw dev wlanX set power save on), make sure that /var/log/dmesg contains 'sdata2' string (or check ieee80211_tx_status in case the corresponding printk for 'sdata2' changes).

  2. The WiFi card should wake up at each 200ms for AP1 and each 200ms for AP2 (for catching beacons with the DTIM bit set). DTIM, TIM and nextbtt hardware timers are armed with these values but there are cases when we miss some beacons. That's because we don't have a good estimation for the TSF of the last received beacon. Maybe we could use a register from AR9271 that holds the TSF of the last received becon?

  3. After a time, the Power Monitor device shows that the card exists PS Mode but the dmesg logs shows that the card still captures traffic according to the hardware timers (e.g.: there are quiet periods when no data is received, still the power consumption of the card is high, as if PS mode would be disabled).

Test bed

Scenario

  • disable wpa_supplicant on the host (e.g.: sudo mv /sbin/wpa_supplicant /sbin/wpa_supplicant_temp + kill the existing wpa_supplicant process)
  • create two virtual interfaces in managed mode: wlan4 and rename8
  • connect wlan4 at AP1 (using wpa_supplicant from command line)
  • connect rename8 at AP2 (using wpa_supplicant from command line)
  • enable PS mode (iw wlan4 set power save on -> this command will enable PS for both interfaces)
  • log dmesg output in a file (while true; do sudo dmesg -c >> file; done)
  • monitor WiFi card Power Consumption
  • capture 802.11 packets from air using Wireshark

Results

Result interpretation

  • Bug #3: According to the dmesg log, around second 625, the Power Monitor devices shows that the WiFi card exits PS mode and stays in the AWAKE state all the time. However, after second 625 the dmesg log shows that the hardware timers are correctly armed and there are quiet periods when there is no RX traffic.

Power Monitor capture before second 625:

Unexpected exit from PS mode after second 625:

Clone this wiki locally