Attached is a wireshark log. Let me explain what you see in there:
I have an ath5k AP and the powersaving n810 device as STA.
What I try to do is ping the n810. You can see that at the start of the log.
Packet #31 is a ping to the n810. #42, too. and so on...
You see that the n810 does not reply. (not even with an 802.11 ack)
I guess the n810 is in PS at that time.
Also note that the TIM sent by the AP is empty.
What I did at #135 is _simultaneously_ ping from the n810 to the ath5k.
At that point suddenly both pings running on both ends start to succeed.
This is with a vanilla 2.6.31.5 kernel, but I can also reproduce this with
compat-wireless and compat-wireless-stable.
--
Greetings, Michael.
On Thursday 29 October 2009 14:06:01 Michael Buesch wrote:
> On Thursday 29 October 2009 13:30:24 Michael Buesch wrote:
> > Attached is a wireshark log. Let me explain what you see in there:
> >
> > I have an ath5k AP and the powersaving n810 device as STA.
> > What I try to do is ping the n810. You can see that at the start of the log.
> >
> > Packet #31 is a ping to the n810. #42, too. and so on...
> > You see that the n810 does not reply. (not even with an 802.11 ack)
> > I guess the n810 is in PS at that time.
> > Also note that the TIM sent by the AP is empty.
> >
> > What I did at #135 is _simultaneously_ ping from the n810 to the ath5k.
> > At that point suddenly both pings running on both ends start to succeed.
> >
> > This is with a vanilla 2.6.31.5 kernel, but I can also reproduce this with
> > compat-wireless and compat-wireless-stable.
> >
>
> This is dmesg log with verbose PS debugging enabled.
>
> [265617.902457] phy0: Allocated STA 00:1d:6e:9b:c5:a6
> [265617.903187] phy0: Inserted STA 00:1d:6e:9b:c5:a6
> [265620.539771] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
>
> Here I start pinging the n810. No dmesg messages appear and pinging does not work.
>
> When I start pinging _from_ the n810, the following messages appear:
>
> [265660.078055] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 exits power save mode
> [265660.078066] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 sending 0 filtered/0 PS frames since STA not sleeping anymore
> [265660.289206] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
> [265660.938988] STA 00:1d:6e:9b:c5:a6 aid 1: PS buffer (entries before 0)
> [265660.985997] STA 00:1d:6e:9b:c5:a6 aid 1: PS Poll (entries after 0)
> [265660.986016] wlan0: STA 00:1d:6e:9b:c5:a6 in PS mode, but pspoll set -> send frame
> [265661.008310] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 exits power save mode
> [265661.008321] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 sending 0 filtered/0 PS frames since STA not sleeping anymore
> [265661.226915] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
>
>
Ok, to sum up some discussion from IRC:
The initial packets that fail are not pings, but ARPs. Which are broadcast frames.
The access point simply fails to notify the station via DTIM for the pending
multicast frames, so it stays in PS. Unicast and the corresponding TIM bitmap works properly,
which also explains why it works once we got a successful ARP (and it didn't expire, yet).
So there is a DTIM problem with multicast frames in ath5k.
--
Greetings, Michael.
On Thu, Oct 29, 2009 at 02:31:46PM +0100, Michael Buesch wrote:
> Ok, to sum up some discussion from IRC:
>
> The initial packets that fail are not pings, but ARPs. Which are broadcast
> frames. The access point simply fails to notify the station via DTIM for the
> pending multicast frames, so it stays in PS. Unicast and the corresponding
> TIM bitmap works properly, which also explains why it works once we got a
> successful ARP (and it didn't expire, yet).
I don't think this fixes everything (I'm still seeing some mishandled
PS-poll frames) but this seemed to help pinging the PS client from the AP
side.
[Although we agreed beacon-sent-gated without a ready time component
is the right way to go on the queue configuration, it seems badly
broken in practice unless I'm missing some enable bit somewhere. So
this is what ath9k does.]
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 1c90d6b..6c167c2 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -541,7 +541,7 @@ struct ath5k_txq_info {
u32 tqi_cbr_period; /* Constant bit rate period */
u32 tqi_cbr_overflow_limit;
u32 tqi_burst_time;
- u32 tqi_ready_time; /* Not used */
+ u32 tqi_ready_time; /* Time queue waits after an event */
};
/*
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 9c6ab53..01b6fc3 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1488,7 +1488,8 @@ ath5k_beaconq_config(struct ath5k_softc *sc)
ret = ath5k_hw_get_tx_queueprops(ah, sc->bhalq, &qi);
if (ret)
- return ret;
+ goto err;
+
if (sc->opmode == NL80211_IFTYPE_AP ||
sc->opmode == NL80211_IFTYPE_MESH_POINT) {
/*
@@ -1515,10 +1516,28 @@ ath5k_beaconq_config(struct ath5k_softc *sc)
if (ret) {
ATH5K_ERR(sc, "%s: unable to update parameters for beacon "
"hardware queue!\n", __func__);
- return ret;
+ goto err;
}
+ ret = ath5k_hw_reset_tx_queue(ah, sc->bhalq); /* push to h/w */
+ if (ret)
+ goto err;
- return ath5k_hw_reset_tx_queue(ah, sc->bhalq); /* push to h/w */;
+ /* reconfigure cabq with ready time to 80% of beacon_interval */
+ ret = ath5k_hw_get_tx_queueprops(ah, AR5K_TX_QUEUE_ID_CAB, &qi);
+ if (ret)
+ goto err;
+
+ qi.tqi_aifs = 0;
+ qi.tqi_cw_min = 0;
+ qi.tqi_cw_max = 0;
+ qi.tqi_ready_time = (sc->bintval * 80) / 100;
+ ret = ath5k_hw_set_tx_queueprops(ah, AR5K_TX_QUEUE_ID_CAB, &qi);
+ if (ret)
+ goto err;
+
+ ret = ath5k_hw_reset_tx_queue(ah, AR5K_TX_QUEUE_ID_CAB);
+err:
+ return ret;
}
static void
diff --git a/drivers/net/wireless/ath/ath5k/qcu.c b/drivers/net/wireless/ath/ath5k/qcu.c
index eeebb9a..31a4241 100644
--- a/drivers/net/wireless/ath/ath5k/qcu.c
+++ b/drivers/net/wireless/ath/ath5k/qcu.c
@@ -409,11 +409,11 @@ int ath5k_hw_reset_tx_queue(struct ath5k_hw *ah, unsigned int queue)
case AR5K_TX_QUEUE_CAB:
AR5K_REG_ENABLE_BITS(ah, AR5K_QUEUE_MISC(queue),
- AR5K_QCU_MISC_FRSHED_BCN_SENT_GT |
+ AR5K_QCU_MISC_FRSHED_DBA_GT |
AR5K_QCU_MISC_CBREXP_DIS |
AR5K_QCU_MISC_CBREXP_BCN_DIS);
- ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL -
+ ath5k_hw_reg_write(ah, ((tq->tqi_ready_time -
(AR5K_TUNE_SW_BEACON_RESP -
AR5K_TUNE_DMA_BEACON_RESP) -
AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF) * 1024) |
--
Bob Copeland %% http://www.bobcopeland.com
On Thursday 29 October 2009 13:30:24 Michael Buesch wrote:
> Attached is a wireshark log. Let me explain what you see in there:
>
> I have an ath5k AP and the powersaving n810 device as STA.
> What I try to do is ping the n810. You can see that at the start of the log.
>
> Packet #31 is a ping to the n810. #42, too. and so on...
> You see that the n810 does not reply. (not even with an 802.11 ack)
> I guess the n810 is in PS at that time.
> Also note that the TIM sent by the AP is empty.
>
> What I did at #135 is _simultaneously_ ping from the n810 to the ath5k.
> At that point suddenly both pings running on both ends start to succeed.
>
> This is with a vanilla 2.6.31.5 kernel, but I can also reproduce this with
> compat-wireless and compat-wireless-stable.
>
This is dmesg log with verbose PS debugging enabled.
[265617.902457] phy0: Allocated STA 00:1d:6e:9b:c5:a6
[265617.903187] phy0: Inserted STA 00:1d:6e:9b:c5:a6
[265620.539771] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
Here I start pinging the n810. No dmesg messages appear and pinging does not work.
When I start pinging _from_ the n810, the following messages appear:
[265660.078055] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 exits power save mode
[265660.078066] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 sending 0 filtered/0 PS frames since STA not sleeping anymore
[265660.289206] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
[265660.938988] STA 00:1d:6e:9b:c5:a6 aid 1: PS buffer (entries before 0)
[265660.985997] STA 00:1d:6e:9b:c5:a6 aid 1: PS Poll (entries after 0)
[265660.986016] wlan0: STA 00:1d:6e:9b:c5:a6 in PS mode, but pspoll set -> send frame
[265661.008310] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 exits power save mode
[265661.008321] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 sending 0 filtered/0 PS frames since STA not sleeping anymore
[265661.226915] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
--
Greetings, Michael.
On Thu, 2009-10-29 at 13:30 +0100, Michael Buesch wrote:
> Attached is a wireshark log. Let me explain what you see in there:
>
> I have an ath5k AP and the powersaving n810 device as STA.
> What I try to do is ping the n810. You can see that at the start of the log.
>
> Packet #31 is a ping to the n810. #42, too. and so on...
It's not a ping, it's an ARP. The problem is that the TIM IE never
indicates multicast traffic although multicast traffic is being sent.
But in later packets you can see that it's not buffered correctly at all
-- soemtimes it's sent after DTIM count 1 beacons.
johannes
On Sun, Nov 01, 2009 at 03:41:49PM +0200, Nick Kossifidis wrote:
> So beacon-sent gated option doesn't work ?
> Did you try also AR5K_DCU_MISC_ARBLOCK_IGNORE ?
>
> Also according to docs Beacon frames should use queue 9 and CAB should
> use queue 8 (don't know why but docs say that these are the
> appropriate DCUs), beacon-gated triggering might only work if we use
> DCU 9 for beacons (now we are using queue 7 for beacons and queue 6
> for cab).
So the results of that testing aren't so good; I still couldn't get it
to work. See the following patch if you want to play with it. Eventually
TXDESC interrupt should fire and you would see:
cabq: enqueued xxxxx
cabq: processed xxxxx
But that only happens with DBA gating, with BCN_SENT_GT I never see
'processed.' Anything else to try?
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 1c90d6b..fb80b53 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -504,10 +504,10 @@ enum ath5k_tx_queue_id {
AR5K_TX_QUEUE_ID_DATA_MIN = 0, /*IEEE80211_TX_QUEUE_DATA0*/
AR5K_TX_QUEUE_ID_DATA_MAX = 4, /*IEEE80211_TX_QUEUE_DATA4*/
AR5K_TX_QUEUE_ID_DATA_SVP = 5, /*IEEE80211_TX_QUEUE_SVP - Spectralink Voice Protocol*/
- AR5K_TX_QUEUE_ID_CAB = 6, /*IEEE80211_TX_QUEUE_AFTER_BEACON*/
- AR5K_TX_QUEUE_ID_BEACON = 7, /*IEEE80211_TX_QUEUE_BEACON*/
- AR5K_TX_QUEUE_ID_UAPSD = 8,
- AR5K_TX_QUEUE_ID_XR_DATA = 9,
+ AR5K_TX_QUEUE_ID_UAPSD = 6,
+ AR5K_TX_QUEUE_ID_XR_DATA = 7,
+ AR5K_TX_QUEUE_ID_CAB = 8, /*IEEE80211_TX_QUEUE_AFTER_BEACON*/
+ AR5K_TX_QUEUE_ID_BEACON = 9, /*IEEE80211_TX_QUEUE_BEACON*/
};
/*
@@ -541,7 +541,7 @@ struct ath5k_txq_info {
u32 tqi_cbr_period; /* Constant bit rate period */
u32 tqi_cbr_overflow_limit;
u32 tqi_burst_time;
- u32 tqi_ready_time; /* Not used */
+ u32 tqi_ready_time; /* Time queue waits after an event */
};
/*
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 9c6ab53..1287ded 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1488,7 +1488,8 @@ ath5k_beaconq_config(struct ath5k_softc *sc)
ret = ath5k_hw_get_tx_queueprops(ah, sc->bhalq, &qi);
if (ret)
- return ret;
+ goto err;
+
if (sc->opmode == NL80211_IFTYPE_AP ||
sc->opmode == NL80211_IFTYPE_MESH_POINT) {
/*
@@ -1515,10 +1516,28 @@ ath5k_beaconq_config(struct ath5k_softc *sc)
if (ret) {
ATH5K_ERR(sc, "%s: unable to update parameters for beacon "
"hardware queue!\n", __func__);
- return ret;
+ goto err;
}
+ ret = ath5k_hw_reset_tx_queue(ah, sc->bhalq); /* push to h/w */
+ if (ret)
+ goto err;
- return ath5k_hw_reset_tx_queue(ah, sc->bhalq); /* push to h/w */;
+ /* reconfigure cabq with ready time to 80% of beacon_interval */
+ ret = ath5k_hw_get_tx_queueprops(ah, AR5K_TX_QUEUE_ID_CAB, &qi);
+ if (ret)
+ goto err;
+
+ qi.tqi_aifs = 0;
+ qi.tqi_cw_min = 0;
+ qi.tqi_cw_max = 0;
+ qi.tqi_ready_time = (sc->bintval * 80) / 100;
+ ret = ath5k_hw_set_tx_queueprops(ah, AR5K_TX_QUEUE_ID_CAB, &qi);
+ if (ret)
+ goto err;
+
+ ret = ath5k_hw_reset_tx_queue(ah, AR5K_TX_QUEUE_ID_CAB);
+err:
+ return ret;
}
static void
@@ -1939,6 +1958,10 @@ ath5k_tx_processq(struct ath5k_softc *sc, struct ath5k_txq *txq)
}
skb = bf->skb;
+
+ if (txq == sc->cabq)
+ printk(KERN_DEBUG "cabq processed %p\n", skb);
+
info = IEEE80211_SKB_CB(skb);
bf->skb = NULL;
@@ -2146,6 +2169,7 @@ ath5k_beacon_send(struct ath5k_softc *sc)
skb = ieee80211_get_buffered_bc(sc->hw, sc->vif);
while (skb) {
+ printk(KERN_DEBUG "cabq enqueued %p\n", skb);
ath5k_tx_queue(sc->hw, skb, sc->cabq);
skb = ieee80211_get_buffered_bc(sc->hw, sc->vif);
}
diff --git a/drivers/net/wireless/ath/ath5k/qcu.c b/drivers/net/wireless/ath/ath5k/qcu.c
index eeebb9a..592ee45 100644
--- a/drivers/net/wireless/ath/ath5k/qcu.c
+++ b/drivers/net/wireless/ath/ath5k/qcu.c
@@ -408,21 +408,29 @@ int ath5k_hw_reset_tx_queue(struct ath5k_hw *ah, unsigned int queue)
break;
case AR5K_TX_QUEUE_CAB:
+#if 1
AR5K_REG_ENABLE_BITS(ah, AR5K_QUEUE_MISC(queue),
AR5K_QCU_MISC_FRSHED_BCN_SENT_GT |
AR5K_QCU_MISC_CBREXP_DIS |
AR5K_QCU_MISC_CBREXP_BCN_DIS);
+#else
+ AR5K_REG_ENABLE_BITS(ah, AR5K_QUEUE_MISC(queue),
+ AR5K_QCU_MISC_FRSHED_DBA_GT |
+ AR5K_QCU_MISC_CBREXP_DIS |
+ AR5K_QCU_MISC_CBREXP_BCN_DIS);
- ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL -
+ ath5k_hw_reg_write(ah, ((tq->tqi_ready_time -
(AR5K_TUNE_SW_BEACON_RESP -
AR5K_TUNE_DMA_BEACON_RESP) -
AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF) * 1024) |
AR5K_QCU_RDYTIMECFG_ENABLE,
AR5K_QUEUE_RDYTIMECFG(queue));
+#endif
AR5K_REG_ENABLE_BITS(ah, AR5K_QUEUE_DFS_MISC(queue),
(AR5K_DCU_MISC_ARBLOCK_CTL_GLOBAL <<
- AR5K_DCU_MISC_ARBLOCK_CTL_S));
+ AR5K_DCU_MISC_ARBLOCK_CTL_S) |
+ AR5K_DCU_MISC_ARBLOCK_IGNORE);
break;
case AR5K_TX_QUEUE_UAPSD:
--
Bob Copeland %% http://www.bobcopeland.com
2009/11/2 Bob Copeland <[email protected]>:
> On Sun, Nov 01, 2009 at 03:41:49PM +0200, Nick Kossifidis wrote:
>> So beacon-sent gated option doesn't work ?
>> Did you try also AR5K_DCU_MISC_ARBLOCK_IGNORE ?
>>
>> Also according to docs Beacon frames should use queue 9 and CAB should
>> use queue 8 (don't know why but docs say that these are the
>> appropriate DCUs), beacon-gated triggering might only work if we use
>> DCU 9 for beacons (now we are using queue 7 for beacons and queue 6
>> for cab).
>
> So the results of that testing aren't so good; I still couldn't get it
> to work. See the following patch if you want to play with it. Eventually
> TXDESC interrupt should fire and you would see:
>
> cabq: enqueued xxxxx
> cabq: processed xxxxx
>
> But that only happens with DBA gating, with BCN_SENT_GT I never see
> 'processed.' Anything else to try?
>
Well let's enable them both :P
I still think that ready-time thing is evil, we should use a more accurate way.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Sun, Nov 01, 2009 at 08:53:44AM +0200, Nick Kossifidis wrote:
> 2009/10/31 Bob Copeland <[email protected]>:
> notice the AR5K_QCU_RDYTIMECFG_ENABLE. So it's probable that the queue
> starts on time and we miss sync because we wait an extra ready-time
> period.
Yeah, I know -- I turned it off before running tests. I don't
think it ever ran the queue, or if it did it was very late.
--
Bob Copeland %% http://www.bobcopeland.com
2009/11/1 Bob Copeland <[email protected]>:
> On Sun, Nov 01, 2009 at 08:53:44AM +0200, Nick Kossifidis wrote:
>> 2009/10/31 Bob Copeland <[email protected]>:
>> notice the AR5K_QCU_RDYTIMECFG_ENABLE. So it's probable that the queue
>> starts on time and we miss sync because we wait an extra ready-time
>> period.
>
> Yeah, I know -- I turned it off before running tests. I don't
> think it ever ran the queue, or if it did it was very late.
>
So beacon-sent gated option doesn't work ?
Did you try also AR5K_DCU_MISC_ARBLOCK_IGNORE ?
Also according to docs Beacon frames should use queue 9 and CAB should
use queue 8 (don't know why but docs say that these are the
appropriate DCUs), beacon-gated triggering might only work if we use
DCU 9 for beacons (now we are using queue 7 for beacons and queue 6
for cab).
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Mon, Nov 02, 2009 at 11:36:22PM +0200, Nick Kossifidis wrote:
> Well let's enable them both :P
>
> I still think that ready-time thing is evil, we should use a more accurate
> way.
I don't follow, you want to try both DBA and BCN_SENT to see what happens
(with/without ready-time)?
--
Bob Copeland %% http://www.bobcopeland.com
2009/11/3 Bob Copeland <[email protected]>:
> On Mon, Nov 02, 2009 at 11:36:22PM +0200, Nick Kossifidis wrote:
>> Well let's enable them both :P
>>
>> I still think that ready-time thing is evil, we should use a more accurate
>> way.
>
> I don't follow, you want to try both DBA and BCN_SENT to see what happens
> (with/without ready-time)?
>
Yup, without ready-time.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
2009/11/1 Nick Kossifidis <[email protected]>:
> 2009/10/31 Bob Copeland <[email protected]>:
>> On Thu, Oct 29, 2009 at 02:31:46PM +0100, Michael Buesch wrote:
>>> Ok, to sum up some discussion from IRC:
>>>
>>> The initial packets that fail are not pings, but ARPs. Which are broadcast
>>> frames. The access point simply fails to notify the station via DTIM for the
>>> pending multicast frames, so it stays in PS. Unicast and the corresponding
>>> TIM bitmap works properly, which also explains why it works once we got a
>>> successful ARP (and it didn't expire, yet).
>>
>> I don't think this fixes everything (I'm still seeing some mishandled
>> PS-poll frames) but this seemed to help pinging the PS client from the AP
>> side.
>>
>> [Although we agreed beacon-sent-gated without a ready time component
>> is the right way to go on the queue configuration, it seems badly
>> broken in practice unless I'm missing some enable bit somewhere. So
>> this is what ath9k does.]
>>
>
> Well ready time is not disabled right now !
>
> 416 ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL -
> 417 (AR5K_TUNE_SW_BEACON_RESP -
> 418 AR5K_TUNE_DMA_BEACON_RESP) -
> 419 AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF) * 1024) |
> 420 AR5K_QCU_RDYTIMECFG_ENABLE,
> 421 AR5K_QUEUE_RDYTIMECFG(queue));
>
> notice the AR5K_QCU_RDYTIMECFG_ENABLE. So it's probable that the queue
> starts on time and we miss sync because we wait an extra ready-time
> period.
>
Also i think we must use AR5K_DCU_MISC_ARBLOCK_IGNORE as we do for
beacon frames so that CAB queue gets on top no matter what queues are
pending (it already has the AR5K_DCU_MISC_ARBLOCK_CTL_GLOBAL).
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
2009/10/31 Bob Copeland <[email protected]>:
> On Thu, Oct 29, 2009 at 02:31:46PM +0100, Michael Buesch wrote:
>> Ok, to sum up some discussion from IRC:
>>
>> The initial packets that fail are not pings, but ARPs. Which are broadcast
>> frames. The access point simply fails to notify the station via DTIM for the
>> pending multicast frames, so it stays in PS. Unicast and the corresponding
>> TIM bitmap works properly, which also explains why it works once we got a
>> successful ARP (and it didn't expire, yet).
>
> I don't think this fixes everything (I'm still seeing some mishandled
> PS-poll frames) but this seemed to help pinging the PS client from the AP
> side.
>
> [Although we agreed beacon-sent-gated without a ready time component
> is the right way to go on the queue configuration, it seems badly
> broken in practice unless I'm missing some enable bit somewhere. So
> this is what ath9k does.]
>
Well ready time is not disabled right now !
416 ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL -
417 (AR5K_TUNE_SW_BEACON_RESP -
418 AR5K_TUNE_DMA_BEACON_RESP) -
419 AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF) * 1024) |
420 AR5K_QCU_RDYTIMECFG_ENABLE,
421 AR5K_QUEUE_RDYTIMECFG(queue));
notice the AR5K_QCU_RDYTIMECFG_ENABLE. So it's probable that the queue
starts on time and we miss sync because we wait an extra ready-time
period.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Sun, Nov 01, 2009 at 03:41:49PM +0200, Nick Kossifidis wrote:
> So beacon-sent gated option doesn't work ?
> Did you try also AR5K_DCU_MISC_ARBLOCK_IGNORE ?
No, but I'll try that today.
> Also according to docs Beacon frames should use queue 9 and CAB should
> use queue 8 (don't know why but docs say that these are the
> appropriate DCUs), beacon-gated triggering might only work if we use
> DCU 9 for beacons (now we are using queue 7 for beacons and queue 6
> for cab).
Yeah, I read the same thing. The docs say 8 and 9 are highest priority
queues, it also says they both need to be DBA gated, but then on the
other hand it describes beacon-sent gated as precisely what we want,
and that queue 8 is "typically associated with beacon-gated frames."
I originally assumed the queue with AR5K_DCU_MISC_BCN_ENABLE is used
for triggering beacon sent but I'll try renumbering the queues and
see what happens.
Just copying ath9k list in case anyone with the inside scoop from Atheros
wants to chime in. :) The issue is queue settings for the CAB queue.
Beacon sent gating seems like a better option than using time throttled
DBA gating (with ready time for the next beacon interval). Ath9k is using
the latter, the former seems not to work at least in ath5k, or we're doing
it wrong.
--
Bob Copeland %% http://www.bobcopeland.com
On Saturday 31 October 2009 21:21:56 Bob Copeland wrote:
> On Thu, Oct 29, 2009 at 02:31:46PM +0100, Michael Buesch wrote:
> > Ok, to sum up some discussion from IRC:
> >
> > The initial packets that fail are not pings, but ARPs. Which are broadcast
> > frames. The access point simply fails to notify the station via DTIM for the
> > pending multicast frames, so it stays in PS. Unicast and the corresponding
> > TIM bitmap works properly, which also explains why it works once we got a
> > successful ARP (and it didn't expire, yet).
>
> I don't think this fixes everything (I'm still seeing some mishandled
> PS-poll frames) but this seemed to help pinging the PS client from the AP
> side.
Yeah this helps it a little bit.
It's able to get an ARP out and it's able to receive _some_ pongs now.
mb@homer:~$ ping 192.168.2.12 # ping the PS device
PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data.
64 bytes from 192.168.2.12: icmp_seq=1 ttl=64 time=86.8 ms
64 bytes from 192.168.2.12: icmp_seq=2 ttl=64 time=4090 ms
64 bytes from 192.168.2.12: icmp_seq=3 ttl=64 time=3092 ms
64 bytes from 192.168.2.12: icmp_seq=4 ttl=64 time=2094 ms
64 bytes from 192.168.2.12: icmp_seq=5 ttl=64 time=1100 ms
64 bytes from 192.168.2.12: icmp_seq=6 ttl=64 time=101 ms
^C
--- 192.168.2.12 ping statistics ---
30 packets transmitted, 6 received, 80% packet loss, time 29002ms
rtt min/avg/max/mdev = 86.898/1760.979/4090.333/1489.080 ms, pipe 5
--
Greetings, Michael.