Hi Bruno, Thanks for your response. I checked the busy counter values and indeed they count down more slowly when the noise floor is raised. So, raising the noise floor does make the receiver more immune to environmental noise.
Regarding periodic calibration, the scheduling I'm doing happens at much smaller time intervals (usually taking about 30-50ms for all packets). Still, in almost all cases, I observe unpredictable delays in packet transmissions. Therefore, I doubt that periodic calibration is the root cause of such behavior. My guess is that it has something to do with the part of the hardware that deals with QCU/DCUs. Moreover, there a couple of queue parameters I'm not too sure about such as transmit latency, slot time, and DCU early termination. Is there anything on the web (or that you might have) describing these parameters? Perhaps playing with them might fix the scheduling problem I'm having. Thanks again for your all help. Best, Nabeel Ahmed. Bruno Randolf wrote: > On Friday 16 April 2010 03:43:30 Nabeel Ahmed wrote: > >> Hi All, >> >> I'm wondering if someone can provide me some hints to tackle a problem >> I've been hitting my head on for the last couple of days. I've been >> working with the ath5k code for the last couple of weeks and am running >> into some performance issues with the driver. >> >> My problem involves scheduling packets at precise time intervals, as a >> means to synchronizing the operation across two wireless nodes. I'm >> using high resolution timers with the 2.6.31 kernel to allow kernel >> scheduling with accuracies of up to 5-10microseconds. This works really >> well with respect to scheduling packets in the ath5k driver. However, >> once the packets are handed over to the hardware (using DMA), every so >> often, packet transmissions get delayed (adding anywhere from 100-3000us >> to the expected transmission time). I'm not sure why this might be >> happening. To isolate the impact of the wireless channel (i.e., to >> ensure that a busy medium is not the cause), I disabled carrier-sense >> and increased the noise floor to 0. However, this did not have much of >> an effect. My hunch is that some operation in the hardware is >> introducing these unpredictable delays. Has anyone experienced this >> problem with the driver? I'm using the latest version of ath5k with the >> AR5212 chipset. My kernel version is 2.6.31-14. >> >> I would greatly appreciate anyone's feedback on this issue. >> > > thinking about it more... do you happen to see some 10 seconds periodicity? > maybe the periodic calibration is the culprit, it stoppes the tx queues? > > bruno > > _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
