[ath5k-devel] [PATCH] ath5k: Remove extraneous statements from ath5k_hw_proc_4word_tx_status and ath5k_hw_proc_2word_status.
Signed-off-by: Qasim Javed qas...@gmail.com
---
drivers/net/wireless/ath/ath5k/desc.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/desc.c
b/drivers/net/wireless/ath/ath5k/desc.c
index f8bfa3a..97b92c3 100644
--- a/drivers/net/wireless/ath/ath5k/desc.c
+++ b/drivers/net/wireless/ath/ath5k/desc.c
@@ -441,10 +441,8 @@ ath5k_hw_proc_2word_tx_status(struct ath5k_hw *ah,
struct ath5k_desc *desc,
struct ath5k_tx_status *ts)
{
- struct ath5k_hw_2w_tx_ctl *tx_ctl;
struct ath5k_hw_tx_status *tx_status;
- tx_ctl = desc-ud.ds_tx5210.tx_ctl;
tx_status = desc-ud.ds_tx5210.tx_stat;
/* No frame has been send or error */
@@ -495,11 +493,9 @@ ath5k_hw_proc_4word_tx_status(struct ath5k_hw *ah,
struct ath5k_desc *desc,
struct ath5k_tx_status *ts)
{
- struct ath5k_hw_4w_tx_ctl *tx_ctl;
struct ath5k_hw_tx_status *tx_status;
u32 txstat0, txstat1;
- tx_ctl = desc-ud.ds_tx5212.tx_ctl;
tx_status = desc-ud.ds_tx5212.tx_stat;
txstat1 = ACCESS_ONCE(tx_status-tx_status_1);
--
1.7.8.2
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] Problem with XR9
Hi everyone, I have a question regarding a problem I have been facing while using an Ubiquiti XR9 Wifi card. This is basically a Wifi card which operates in the 900MHz band and is based on the Atheros 5414 (supports 802.11b/g) chipset. There is an open source driver (mainly maintained by Atheros and contributions from others) called ath5k. For a research problem, I wanted to measure the amount of time elapsed between when a packet enters the MAC layer queues (in this case mac80211 transmit queue) and when it is actually transmitted over the air. Measuring the entry into the MAC layer is easy as the stack runs on the Host CPU and can be instrumented. For the exact time when the frame is actually transmitted, the card provides support for reading that information. More specifically, whenever a frame is transmitted, a transmission status descriptor can be read. This transmission status descriptor contains the exact timestamp (in TUs) at which the last successful frame transmission attempt was made. Interestingly enough, when I take the difference of two timestamps, I get really large values on the order of 200,000 microseconds. This only happens when there is a lot of data to send such as when using iperf. On the other hand, if I just use ping and then look at the value measured above, they are fine. I measured the values when there was no contention from any other node (experiments were carried out over a testbed where nodes are connected via coaxial cables). So, basically I get large bloated values only when there are lot of transmission attempts back to back. I tried moving the point at which the first timestamp is taken as close to the hardware as possible i.e. just before the frame is DMA'ed to the card. I get the same large values which indicates that delays are not being incurred due to queues on the host. Also, instead of depending on the card for providing the second timestamp (the time at which the frame is put on air), I tried to measure it myself within an interrupt handler which is invoked whenever the host CPU is interrupted by an interrupt generated as a result of receiving a frame on the Wifi card. Also, in this case I get large values as before. This indicates that the mechanism used to take the transmit timestamp on the card is working fine. I did some further research using the mpstat tool and found that the number of interrupts per second (corresponding to the received frames) generated by the card goes down if the offered load exceeds a certain threshold. This seems to indicate that there is some problem in the code running on the cards's own processor as the number of interrupts going down as a result of more offered load is ungraceful behavior. I was wondering if you could offer some insight into this or ways to solve this problem? Thanks and regards, -Qasim ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Ath5k Hardware Timestamping of Transmitted Packets
On Mon, Mar 19, 2012 at 10:50 PM, Qasim Javed qas...@gmail.com wrote: Hi Alexander, As Adrian mentioned, indeed there is a timestamp field in the transmit status descriptor which could be used for your purpose. This timestamp is basically the last 16-bits of a snapshot of the TSF counter. Since you are using a card based on AR5213 chipset, the TX status descriptor has 4 32-bit words. The function used to process the TX status descriptor for your card is then: ath5khw_proc_4word_tx_status (in desc.c) This is ath5k_hw_proc_4word_tx_status You will notice that within this function, the TX timestamp is recorded: Just a correction, the timestamp is not recorded here, but copied from the TX status descriptor. It is recorded at the last transmission attempt when the frame is put on air. ts-ts_tstamp = AR5K_REG_MS(txstat0, AR5K_DESC_TX_STATUS0_SEND_TIMESTAMP); where ts is of type struct ath5k_tx_status. Having described this, I should mention that I have had mixed experience when using this field. Some cards such as (Ubiquiti XR9) do not fill the value properly (or there is some bug in the firmware running on the card), for others such as AR5212 based cards, it works fine. From what little I know, in case there are multiple retransmissions, the reported TX timestamp is recorded when the frame is finally transmitted, that is at the last successful transmission attempt. I hope that helps. -Qasim On Wed, Mar 14, 2012 at 6:42 PM, Adrian Chadd adr...@freebsd.org wrote: I'd ignore wireshark for now. Look through the TX and TX completion code. There's a timestamp field somewhere that should be populated for all TXed frames. Verify first that the TSF is being written into that timestamp field upon completion, and then verify that it's pushed all the way back up through radiotap. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] TX time
Hi all, I made some modifications to the ath5k driver to measure the exact time to transmit a frame including queueing in the driver, the dma transfer, waiting in a queue on the card (during backoff). My initial idea was to store the current TSF value when ath5k_tx is called. This value serves as the first timestamp. Ideally the second timestamp would be taken as soon as frame transmission ends. For this, I found out that the timestamp stored in AR5K_DESC_TX_STATUS0_SEND_TIMESTAMP could be used. This values is stored in ts_tstamp field of ath5k_tx_status struct. This happens in the function ath5k_hw_proc_4word_tx_status for the card that I am using (Ubiquiti XR-9 900Mhz Wifi card, recognized as ath5k phy0: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)). I get random values from the AR5K_DESC_TX_STATUS0_SEND_TIMESTAMP register. I am not accessing the register directly, I just use the ts_tstamp value from the ath5k_tx_status struct. Interestingly enough, this code works fine on the AR5007 card (2.4GHz). Does anybody have any idea why the value in AR5K_DESC_TX_STATUS0_SEND_TIMESTAMP would not be correct. Could it be that for XR-9 cards, this value is not being updated at the end of a transmission. Any help would be greatly appreciated. Thanks, -Qasim ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Issue with per station statistics in debugfs
Why don't you log packets using tshark/tcpdump on a monitor mode interface and then do your analysis on the log? If you don't log the packets then the only way is to modify the mac80211 source code to not count the beacons which should be pretty straightforward to do. -Qasim On Tue, Nov 22, 2011 at 5:42 AM, Mariana Gambande mlgamba...@gmail.comwrote: Hello to all, I've realized the rx_fragments and rx_bytes continually increase because of the beacons (I thought the beacons were not recorded if the iface is not in monitor mode). I would like to know how to stop registering the beacons in this situation. I've tried changing the value of AR5K_RX_FILTER_BEACON but it stops detecting other stations instead of just not registering the beacons. Thanks in advance! Mariana 2011/11/14 Mariana Gambande mlgamba...@gmail.com Hi to all! I have an issue regarding the debugfs statistics. I'm working with ad-hoc mode and monitoring statistics in /sys/kernel/debug/ieee80211/phy0/stations/. I have observed that having no activity between two stations connected in ad-hoc mode (no one is sending anything), the variables rx_fragments and rx_bytes continually increase. This can be seen with the command 'iw $iface station dump' also. I would expect that variables in /sys/kernel/debug/ieee80211/phy0/statistics could get increase because of some noise (other AP around, etc) but not in the per station statistics. This happens with both connected stations and no one shown tx_bytes/tx_packets. I'm working with compat-wireless-2.6.35-1. Are these really per station statistics? Thanks in advance! Mariana ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] How to profile this strange effect under high load?
How about using trace-cmd and kernelshark with function graph tracer to see what is getting called so often? -Qasim On Tue, Oct 12, 2010 at 5:33 AM, Bruno Randolf b...@einfach.org wrote: Hello! I am trying to debug a strange effect, I am seeing on soekris net48xx boards with two ath5k interfaces: * wlan0 [phy0] configured in ad-hoc mode, A band, and it is getting a lot of traffic routed thru it * wlan1 [phy1] also configured in ad-hoc mode, G band, but not actively sending (no IP address). I run iperf between two PCs attached by ethernet, UDP 25Mbps and I am sure all traffic is routed thru wlan0 (phy0). The load on the SENDING box gets very high: Mem: 27304K used, 99040K free, 0K shrd, 616K buff, 14128K cached CPU: 0% usr 0% sys 0% nic 0% idle 0% io 5% irq 93% sirq Load average: 1.73 1.01 2.23 2/38 3128 PID PPID USER STAT VSZ %MEM %CPU COMMAND 2772 2 root RW 0 0% 71% [phy1] 2757 2 root SW 0 0% 11% [phy0] 3128 436 root R 988 1% 8% top 3 2 root SW 0 0% 5% [ksoftirqd/0] 5 2 root SW 0 0% 3% [events/0] 56 2 root SW 0 0% 1% [bdi-default] 1383 1 root S 1824 1% 0% /usr/bin/oprofiled --session-dir=/r ...and the interesting thing is that [phy1] - the INACTIVE interface - consumes much more CPU time than [phy0] which is actually transmitting. I have disabled ANI on wlan1, to avoid getting many MIB interrupts, but it does not change much. I have dumped frames on phy1, and all it sees are a few beacon frames. I have tried wlan1 in managed mode - same effect. The effect is slightly less in AP mode, though... I tried oprofile, but it shows mostly tx related things. So my question is: How can I find out, what [phy1] is so busy doing? Any ideas how to profile this? Thanks in advance, bruno ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] Backoff persistence and threshold
Hi, I have been browsing the driver code for some backoff related stuff. Specifically, I am looking for a way to count the number of backoffs on AR5212 based cards. I have seen a backoff count register for AR5210 but cannot find any such thing for AR5212. Also, what is Backoff persistence factor and Backoff threshold? I understand what backoff is but I have no idea what persistence means here. Apparently, the driver does not make use of this register and trying to look for some more information in Sam's openhal didn't help. I would really appreciate if someone can provide me more information about these registers and whether it is possible to count the number of backoffs on AR5212 cards. #*define* AR5K_DCU_MISC_BACKOFF_PERSIST http://wifi-dev:8080/source/s?refs=AR5K_DCU_MISC_BACKOFF_PERSISTproject=/wireless-testing 0x1000 /* Persistent backoff */ #*define* AR5K_DCU_MISC_BACKOFF http://wifi-dev:8080/source/s?refs=AR5K_DCU_MISC_BACKOFFproject=/wireless-testing 0x003f /* Mask for backoff threshold */ Thanks, -Qasim ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] Ath5k Packet loss
Hi, I have a gentoo system and the latest Ath5k drivers from compat-wireless. I downloaded them about a week back. I understand that the tarball is updated daily. I have three Ubiquiti SRC cards (AR5212). I have configured one of them as an AP in 802.11a mode using channel 149. The other two are stations connected to the AP. I fixed the rate to 6Mbps. I have an iperf server running on the AP which accepts UDP traffic. One of the stations sends UDP packets at a rate of 6Mbps to the AP. Because there are no surrounding APs in 802.11a mode, the band is very quiet. However, I am surprised that I get 2.6% packet loss when I run the above mentioned experiment. The distance of both stations is no more than 10 meters from the AP. Also, the txpower for both STAs is 30dbm. One STA sends UDP packets to the AP at 6Mbps for 30 seconds and the report that iperf generates is as follows: [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 0.0-30.1 sec 18.3 MBytes 5.11 Mbits/sec 0.301 ms 352/13434 (2.6%) Considering that there is no activity on this channel except the beacons of AP and probe requests/responses from the other STA, how can 352 packets get lost? To make things worse, I tried the above experiment with minimal bandwidth. Very oddly, the results are as follows: [ ID] Interval Transfer BandwidthJitter Lost/Total Datagrams [ 3] 0.0-31.0 sec 44.5 KBytes 11.8 Kbits/sec 0.060 ms1/ 32 (3.1%) Why would even a packet get lost at this very slow data rate? I have repeated the above several times, and it always results in about the same numbers. Earlier, I had also noticed that if I ping one STA from the other STA, about every 10 seconds, the ping response time jumps from 0.8 milliseconds to 25 milliseconds. I would be really grateful if I can get some feedback fro myou guys on this so that we can fix whatever is messing things up here. Thanks, -Qasim ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
