In https://bugzilla.novell.com/show_bug.cgi?id=718736, a user reports that his
network using an RTL8188CE becomes very slow under "heavy" load. This condition
started when he updated from openSUSE 11.4 to 12.1. The kernels involved are
2.6.37 and 3.1. I am unable to duplicate the problem.
Packet capture with Wireshark shows that the slow down is due to retransmissions
due to TCP checksum errors. I found nothing to explain the situation with a
Google search, thus I am asking here.
I put heavy in quotes because the traffic is from a web browser to yahoo.com,
thus the potential throughput is not very high.
As far as I know, this checksum is generated in a higher layer of the network
stack, and that data is just passed through the 802.11 layer, and the wireless
driver. Is this correct? Anyone have any ideas on where to look for the problem?
Thanks,
Larry
> > Hi everybody!
> >
> > My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag
before
> > send a packet, but found it no use. It still wait for an ACK. Then I
read
> > the code,
> > in ath9k_htc_tx_data(htc_drv_txrx.c) , it seems there is only two flags:
> >
> > #define ATH9K_HTC_TX_CTSONLY 0x1
> > #define ATH9K_HTC_TX_RTSCTS 0x2
> >
> > None is about ack.
> >
> > Does anyone know how to make this flag work properly?
> >
>
> NOACK usage is not handled by ath9k_htc.
> See: http://linuxwireless.org/en/users/Drivers/ath9k_htc#TODO
>
Thanks??
So , is there any way to set the re-transmit times when ACK not received?
Now , it will send 10 times.
> Sujith
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi!
On 12/19/2011 6:38 AM, ???? wrote:
> Hi everybody!
>
> My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag before
> send a packet, but found it no use. It still wait for an ACK. Then I read
> the code,
> in ath9k_htc_tx_data(htc_drv_txrx.c) , it seems there is only two flags:
>
> #define ATH9K_HTC_TX_CTSONLY 0x1
> #define ATH9K_HTC_TX_RTSCTS 0x2
>
> None is about ack.
>
> Does anyone know how to make this flag work properly?
>
As an FYI if your card is a AR9280, then you should be looking in xmit.c
and not at the HTC related code.
I am also working on this issue to enable per-frame no-ack and have
already tracked it down to the following snippet in the function
ieee80211_tx_prepare (mac80211/tx.c).
if (is_multicast_ether_addr(hdr->addr1)) {
tx->flags &= ~IEEE80211_TX_UNICAST;
info->flags |= IEEE80211_TX_CTL_NO_ACK;
} else {
tx->flags |= IEEE80211_TX_UNICAST;
if (unlikely(local->wifi_wme_noack_test))
info->flags |= IEEE80211_TX_CTL_NO_ACK;
else
info->flags &= ~IEEE80211_TX_CTL_NO_ACK;
}
So if you send a unicast frame without this wifi_wme_noack_test flag set
then mac80211 will force the frame to require an ACK. To set the flag,
# sudo -s "echo 1> /sys/kernel/debug/ieee80211/phy0/noack"
Assuming phy0 is the wireless card with which you are wanting to do the
frame injection. The downside to this is that now every frame is passed
to ath9k with the no ack flag set.
Daniel
李刚 wrote:
> So , is there any way to set the re-transmit times when ACK not received?
> Now , it will send 10 times.
Unfortunately no, it cannot be done. The firmware has to be modified
to allow such changes and the firmware is currently available only in binary form.
Sujith
2011/12/30 ???? <[email protected]>:
> Hi sirs,
>
> Today, I noticed that when an data frame is sent by
> ieee80211_subif_start_xmit, then ieee80211_rx will be called twice , first
> is an Acknowledgement frame and second is the response data frame. Is this
> the normal case? It seems the RA frame is nonsense and just be freed in
> ieee80211_rx_monitor.
>
> Is there anyway to tell the hardware not report RA frame to
> mac80211?
.. its receiving ACKs? I thought it only did that when either promisc
or control was enabled. Try fiddling around with the RX filter bitmask
and see if you can determine (for your NIC :) which filter bit is
doing it.
Maybe the interface is in promisc mode in hostap mode and this is why
you're seeing ACKs.
Adrian
李刚 wrote:
> Hi everybody!
>
> My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag before
> send a packet, but found it no use. It still wait for an ACK. Then I read
> the code,
> in ath9k_htc_tx_data(htc_drv_txrx.c) , it seems there is only two flags:
>
> #define ATH9K_HTC_TX_CTSONLY 0x1
> #define ATH9K_HTC_TX_RTSCTS 0x2
>
> None is about ack.
>
> Does anyone know how to make this flag work properly?
>
NOACK usage is not handled by ath9k_htc.
See: http://linuxwireless.org/en/users/Drivers/ath9k_htc#TODO
Sujith
>
> Hi!
>
> On 12/19/2011 6:38 AM, ???? wrote:
> > Hi everybody!
> >
> > My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag
before
> > send a packet, but found it no use. It still wait for an ACK. Then I
read
> > the code,
> > in ath9k_htc_tx_data(htc_drv_txrx.c) , it seems there is only two flags:
> >
> > #define ATH9K_HTC_TX_CTSONLY 0x1
> > #define ATH9K_HTC_TX_RTSCTS 0x2
> >
> > None is about ack.
> >
> > Does anyone know how to make this flag work properly?
> >
>
> As an FYI if your card is a AR9280, then you should be looking in xmit.c
> and not at the HTC related code.
Hi, Daniel, Thanks you !
Sorry, I didn't make it clear! My 9280 is an USB card, so the related code
is htc_drv_*.c.
>
> I am also working on this issue to enable per-frame no-ack and have
> already tracked it down to the following snippet in the function
> ieee80211_tx_prepare (mac80211/tx.c).
>
> if (is_multicast_ether_addr(hdr->addr1)) {
> tx->flags &= ~IEEE80211_TX_UNICAST;
> info->flags |= IEEE80211_TX_CTL_NO_ACK;
> } else {
> tx->flags |= IEEE80211_TX_UNICAST;
> if (unlikely(local->wifi_wme_noack_test))
> info->flags |= IEEE80211_TX_CTL_NO_ACK;
> else
> info->flags &= ~IEEE80211_TX_CTL_NO_ACK;
> }
I have seen these codes in tx.c, and at first I thought it should work, but
does not.
>
> So if you send a unicast frame without this wifi_wme_noack_test flag set
> then mac80211 will force the frame to require an ACK. To set the flag,
>
> # sudo -s "echo 1> /sys/kernel/debug/ieee80211/phy0/noack"
>
> Assuming phy0 is the wireless card with which you are wanting to do the
> frame injection. The downside to this is that now every frame is passed
> to ath9k with the no ack flag set.
>
> Daniel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Hi everybody!
> >
> > My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag
before
> > send a packet, but found it no use. It still wait for an ACK. Then I
read
> > the code,
>
> may be any of the following hacks may work ?
Sorry, I didn't make it clear! My 9280 is an USB card, and the send
function is ath9k_htc_tx_data, there is no corresponding flag.
>
> @@ -1039,6 +1039,9 @@ static void ath_tx_fill_desc(struct ath_softc
> *sc, struct ath_buf *bf,
> info.qcu = txq->axq_qnum;
>
> info.flags = ATH9K_TXDESC_INTREQ;
> +
> + info.flags |= ATH9K_TXDESC_NOACK;
> +
> if (tx_info->flags & IEEE80211_TX_CTL_NO_ACK)
> info.flags |= ATH9K_TXDESC_NOACK;
> if (tx_info->flags & IEEE80211_TX_CTL_LDPC)
>
> (or)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index edcd1c7..0454dee 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -1185,6 +1185,8 @@ ieee80211_tx_prepare(struct ieee80211_sub_if_data
> *sdata,
> } else
> tx->flags |= IEEE80211_TX_UNICAST;
>
> + info->flags |= IEEE80211_TX_CTL_NO_ACK;
> +
> if (!(info->flags & IEEE80211_TX_CTL_DONTFRAG)) {
> if (!(tx->flags & IEEE80211_TX_UNICAST) ||
> skb->len + FCS_LEN <= local->hw.wiphy->frag_threshold
||
>
>
>
> --
> shafi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
2011/12/19 ???? <[email protected]>:
>
> Hi, Daniel, Thanks you !
>
> Sorry, I didn't make it clear! My 9280 is an USB card, so the related code
> is htc_drv_*.c.
No worries, I just was not aware of any USB devices with the 9280 in
it and the ath9k_htc "supported chips" are the 9271 and 7010.
> I have seen these codes in tx.c, and at first I thought it should work, but
> does not.
So will assume you dealt with this then.
I have not done a lot of delving into the ath9k_htc code myself and I
am not familiar with interfacing with the chips via USB. Normally with
a 9280 where the tx ctrl descriptors are DMA'ed in I just need to make
sure that bit 24 of the third tx ctrl descriptor is set to 1. I did a
cursory look at how a frame is handed from kernel down to hardware and
the hardware control is done through flags set on a struct
tx_frame_hdr. I looked at the flags defined for ath9k_htc and I see no
sign of a flag to control ACK's. So I think this has to be punted to
one of the Atheros guys or someone with the spec sheets that can say
if there is a bit in the flags field to turn off ACK.
Sorry I couldn't be much more help.
Daniel
Le samedi 17 décembre 2011 à 17:18 -0600, Larry Finger a écrit :
> In https://bugzilla.novell.com/show_bug.cgi?id=718736, a user reports that his
> network using an RTL8188CE becomes very slow under "heavy" load. This condition
> started when he updated from openSUSE 11.4 to 12.1. The kernels involved are
> 2.6.37 and 3.1. I am unable to duplicate the problem.
>
> Packet capture with Wireshark shows that the slow down is due to retransmissions
> due to TCP checksum errors. I found nothing to explain the situation with a
> Google search, thus I am asking here.
>
> I put heavy in quotes because the traffic is from a web browser to yahoo.com,
> thus the potential throughput is not very high.
>
> As far as I know, this checksum is generated in a higher layer of the network
> stack, and that data is just passed through the 802.11 layer, and the wireless
> driver. Is this correct? Anyone have any ideas on where to look for the problem?
>
I see nothing special in the packet capture from this bug report.
(Only suboptimal application opening many concurrent flows in //)
Keep in mind most modern NICS compute checksums themselve.
Linux offloads this to NIC
This can be controled eventually by "ethtool -k ethX" (-K to change
settings)
# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off
# ethtool -K eth0 tx off
# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off
2011/12/19 ???? <[email protected]>:
> My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag before
> send a packet, but found it no use. It still wait for an ACK.
How did you verify that? For unicast frames with IEEE80211_TX_CTL_NO_ACK
set you will still see an ACK on the air (since the peer has to
generate it according
to the 802.11 spec). The only thing this flag does is to advise the hardware to
ignore a missing ACK and hence to not retry the frame in this case ...
Helmut
Hi everybody!
My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag before
send a packet, but found it no use. It still wait for an ACK. Then I read
the code,
in ath9k_htc_tx_data(htc_drv_txrx.c) , it seems there is only two flags:
#define ATH9K_HTC_TX_CTSONLY 0x1
#define ATH9K_HTC_TX_RTSCTS 0x2
None is about ack.
Does anyone know how to make this flag work properly?
Thanks a lot!
gang.li
2011/12/19 ???? <[email protected]>:
> Hi everybody!
>
> My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag before
> send a packet, but found it no use. It still wait for an ACK. Then I read
> the code,
may be any of the following hacks may work ?
@@ -1039,6 +1039,9 @@ static void ath_tx_fill_desc(struct ath_softc
*sc, struct ath_buf *bf,
info.qcu = txq->axq_qnum;
info.flags = ATH9K_TXDESC_INTREQ;
+
+ info.flags |= ATH9K_TXDESC_NOACK;
+
if (tx_info->flags & IEEE80211_TX_CTL_NO_ACK)
info.flags |= ATH9K_TXDESC_NOACK;
if (tx_info->flags & IEEE80211_TX_CTL_LDPC)
(or)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index edcd1c7..0454dee 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1185,6 +1185,8 @@ ieee80211_tx_prepare(struct ieee80211_sub_if_data *sdata,
} else
tx->flags |= IEEE80211_TX_UNICAST;
+ info->flags |= IEEE80211_TX_CTL_NO_ACK;
+
if (!(info->flags & IEEE80211_TX_CTL_DONTFRAG)) {
if (!(tx->flags & IEEE80211_TX_UNICAST) ||
skb->len + FCS_LEN <= local->hw.wiphy->frag_threshold ||
--
shafi
Hi sirs,
Today, I noticed that when an data frame is sent by
ieee80211_subif_start_xmit, then ieee80211_rx will be called twice , first
is an Acknowledgement frame and second is the response data frame. Is this
the normal case? It seems the RA frame is nonsense and just be freed in
ieee80211_rx_monitor.
Is there anyway to tell the hardware not report RA frame to
mac80211?
Thanks very much!
Li gang
李刚 wrote:
> From wireshark, I noticed that when send an data frame , the
> duration of frame control is fixed at 60 , no matter the frame length is 100
> bytes or 1000 bytes.
>
> It seems this value is calculated in firmware and should be correct.
> But I don't know why. And this value can be set in mac80211?
Duration calculation is broken for ath9k_htc.
See: http://linuxwireless.org/en/users/Drivers/ath9k_htc#TODO
Sujith
Hi Sirs,
From wireshark, I noticed that when send an data frame , the
duration of frame control is fixed at 60 , no matter the frame length is 100
bytes or 1000 bytes.
It seems this value is calculated in firmware and should be correct.
But I don't know why. And this value can be set in mac80211?
Thanks in advance!
Li gang