Hi! There's no CPU on the NIC.
The interrupt load is going down because at some point, you're not handling each RX interrupt before the next RX packet comes, so it doesn't generate a new interrupt. There was code in madwifi/freebsd/HAL that did TX interrupt mitigation by only flipping on the TXINT bit in the TX descriptor on every N'th descriptor, then also taking a TX error interrupt (TXURN I think?) when the QCU ran out of frames to feed the PCU. That way it only had to take an interrupt every 'n'th frame when under load. Just please keep in mind that whilst the NIC is receiving, the transmission is going to take quite a bit longer to occur. They don't work in parallel. Adrian On 23 March 2012 22:14, Qasim Javed <qas...@gmail.com> wrote: > 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 _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
