Bruno, Is there any way short of disassembly to figure out whether ath_hal_get_channel_noise does anything more than return a pre-calculated value? If we can determine this, then it makes sense to store the noise value in softc again, like it used to be. I still want the noise floor updated in the buffer, however, as noise calibration is happening concurrently while the DMA engine is running and I'd like to get the best answer we can for each packet (for DFS purposes as well as accurate reporting). It matters a lot more to some than others. See #1659 in bugzilla for a related issue.
Cheers, Mike Michael Taylor wrote: > Bruno, > > I don't doubt your findings, although I must admit that it's > disappointing. I had naively hoped was reading an undocumented > register. Calibration initially starts at every 1s, but later drops > down to every 30s. The more accurate we can make this the better. > Storing the noise per packet as we are still makes sense, and the call > to ath_hal_get_channel_noise() does exactly what you propose to do > outside the HAL so I don't see any reason to change it. If it doesn't > read any registers, it can't be much more expensive than invoking a > local pointer. If it is, then I suggest there is something else it is > doing that we need to understand before we discard it. The noise level > samples are used by several management tools and utilities for > histograms and such. I was sure I had seen better than 1s resolution in > the actual values of noise read by these things, but I believe you. > That said, I think what we have is working well enough. What advantage > would we get by changing it? > > bruno randolf wrote: > >> hello! >> >> today did some tracing with madwifi on AR5212/PHY5111/2111 and AR5414 based >> cards and i noticed that the function ath_hal_get_channel_noise() does not >> actually read any registers. that means it must return the noise value from >> some HAL internal state. >> >> that also means calling this function in ath_uapsd_processtriggers() to >> update >> the noise per rx descriptor (in IRQ context btw!) is superfluous. >> >> i'm not quite sure (yet) where the noise is actually read from, probably >> ath_hal_calibrate() - unless the HAL reads the noise from some register i >> don't know about. so it would be enough to update ic->ic_channoise after >> that >> and only read that value in ath_uapsd_processtriggers(), especially since >> ath_uapsd_processtriggers() is in IRQ context and should be as efficient as >> possible. since the noise is not updated that often anyways, we might even >> consider to move it into the rx tasklet. >> >> bruno >> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Madwifi-devel mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/madwifi-devel >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Madwifi-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
