Re: [ath9k-devel] ath9k-issue with stop RX/TX DMA - correlation with WMM traffic classes?
On 2013-04-12 10:27 AM, Rougu wrote: Hi everyone, while I might be totally wrong with my observation, I still would like to share it, because this issue is lingering for years now and many users are waiting to a solid grip on it to fix it. I'm running several freifunk-nodes in Cologne, Germany, where the firmware contains a ath9k-watchdog that restarts the node, once the failure occurs. One of my nodes is affected in varying intervals of 200 .. 1 seconds uptime, depending on WLAN activity. (openwrt, attitude adjustment, kernel 3.3.8) Please also run a test with OpenWrt trunk and compare stability. Looking at /sys/kernel/debug/ieee80211/phy0/ath9k/xmit, it seems that MPDUs in the highest priority queue VO have a lower rate of completion (90,5%) than those in BE (99,9%). From my laymen's perspective I would expect VO to have an even better completion rate than BE. What you're missing in that perspective is the fact that not all traffic is created equal :) The VO queue carries management traffic. Probe responses frequently end up in XRetry because the number of retries is intentionally limited to 1 (some clients are often either too far away to ACK the probe response, or do not stick around long enough to receive it). Any chance to see a correlation between WMM priority queue handling and DMA access problems? No, the data is too limited for that. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k-issue with stop RX/TX DMA - correlation with WMM traffic classes?
Hallo Felix, Am 12.04.2013 um 17:41 schrieb Felix Fietkau: On 2013-04-12 10:27 AM, Rougu wrote: while I might be totally wrong with my observation, I still would like to share it, because this issue is lingering for years now and many users are waiting to a solid grip on it to fix it. I'm running several freifunk-nodes in Cologne, Germany, where the firmware contains a ath9k-watchdog that restarts the node, once the failure occurs. One of my nodes is affected in varying intervals of 200 .. 1 seconds uptime, depending on WLAN activity. (openwrt, attitude adjustment, kernel 3.3.8) Please also run a test with OpenWrt trunk and compare stability. thanks for providing feedback on this issue. Please keep in mind that using OpenWRT-trunk is not that easy for node operators of freifunk networks. I hope Rouge is able to do so - at least we will provide help in our Freifunk-Community (kbu). I'd really like to discuss this issue at the upcoming Wireless Community Weekend in Berlin - will I meet you there? At the moment we really do suffer from excessive driver-woos - causing the need to reboot nodes: ~ 1450 incidents have been reported within one month (http://register.kbu.freifunk.net/watchdog_bites). Some nodes are almost DoS'ed by certain - yet undiscovered - clients. Thanks, yanosz ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k-issue with stop RX/TX DMA - correlation with WMM traffic classes?
On 2013-04-12 6:57 PM, Jan Lühr wrote: Hallo Felix, Am 12.04.2013 um 17:41 schrieb Felix Fietkau: On 2013-04-12 10:27 AM, Rougu wrote: while I might be totally wrong with my observation, I still would like to share it, because this issue is lingering for years now and many users are waiting to a solid grip on it to fix it. I'm running several freifunk-nodes in Cologne, Germany, where the firmware contains a ath9k-watchdog that restarts the node, once the failure occurs. One of my nodes is affected in varying intervals of 200 .. 1 seconds uptime, depending on WLAN activity. (openwrt, attitude adjustment, kernel 3.3.8) Please also run a test with OpenWrt trunk and compare stability. thanks for providing feedback on this issue. Please keep in mind that using OpenWRT-trunk is not that easy for node operators of freifunk networks. I hope Rouge is able to do so - at least we will provide help in our Freifunk-Community (kbu). I'm also considering backporting mac80211 from trunk to AA after the release (meant for people that build the branch from source, not for a follow-up release). I'd really like to discuss this issue at the upcoming Wireless Community Weekend in Berlin - will I meet you there? Yes, definitely. At the moment we really do suffer from excessive driver-woos - causing the need to reboot nodes: ~ 1450 incidents have been reported within one month (http://register.kbu.freifunk.net/watchdog_bites). Some nodes are almost DoS'ed by certain - yet undiscovered - clients. I'm really interested how such a setup behaves with either trunk or a mac80211 backport to AA. Many fixes were added that could not easily be backported to AA because they were too intrusive for the release. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
