Hi I was just wondering is some patches for this performance fixes were made available. Any inputs would help regards Ajay
On Tue, Dec 11, 2012 at 12:43 AM, Thomas Pedersen <[email protected]>wrote: > On Mon, Dec 10, 2012 at 7:48 AM, Chaoxing Lin > <[email protected]> wrote: > > TP> > > TP>Are you talking about a different bug? > > > > GY> Hm, may bee, but according to Chaoxing Lin emails there is several > bugs which cause performance degradation in 802.11s mode, and symptoms in > my case indentical, i get same results as Chaoxing Lin, and seems same > throbles, i will make tests what you want anyway and report results. > > > > For easy reference, I summarize the 4 problems I uncovered so far that > contribute to in-stability of 7-node 802.11s network. > > > > 1. ath9k "Tx DMA error". Ping packet loss is seen each time "Fail to > stop Tx DMA" log is seen. It's NOT the main cause. > > > > 2. authsae or 802.11s kernel problem: The two ends of a peer link get > out of sync for whatever reason. One end says, the peer link is "ESTAB" and > all 3 keys are in place. While the other end says this peer link is not > "ESTAB", no keys installed for the peer. > > We recently applied > > https://github.com/cozybit/authsae/commit/0e5c65c3f773db820d6cee7b365cd4a70181c72d > which may fix your issue. > > > 3. AES-CCM pairwise key sometimes complains packet replay so ping > packets are dropped. A kernel key dump in this error case is below. (I > overwrote key_key_read() function in debugfs_key.c to dump all info) > > > > Key 362: > > 0xcf393800 AES-CCM Key: 49305a736a8b6d5fcb34057ee6983d44 > Pairwise > > Peer MAC: 00:0e:8e:38:36:03 > > tx_pn: 000000000000009f > > > > > > rx_pn[ 0]: 0000000d788b rx_pn[ 1]: 000000000000 rx_pn[ 2]: > 000000000000 > > rx_pn[ 3]: 000000000000 > > rx_pn[ 4]: 000000000000 rx_pn[ 5]: 000000000000 rx_pn[ 6]: > 000000000000 > > rx_pn[ 7]: 000000000000 > > rx_pn[ 8]: 000000000000 rx_pn[ 9]: 000000000000 rx_pn[10]: > 000000000000 > > rx_pn[11]: 000000000000 > > rx_pn[12]: 000000000000 rx_pn[13]: 000000000000 rx_pn[14]: > 000000000000 > > rx_pn[15]: 000000000000 > > rx_pn[16]: 000000003580 > > > > replays: 11970 icverror: <=======================problem > here=========== > > > > The worse thing for problem 2 and 3 above is, when it gets into this > state, the mpath still stays active. So all packets are still routed to the > bad peer link/mpath and will be dropped by peer. > > ok. Patches are welcome. > > > 4. 802.11n packet aggregation. I believe this is the main problem by the > fact that, disabling 802.11n packet aggregation in ath9k driver will make > the network stable and problem 2 and 3 are not seen. In other words, > problem 2 and 3 may be caused by aggregation (my imagination, aggregation > caused certain error condition that is not handled properly, which triggers > problem 2 and 3) > > And to reproduce you run a simultaneous ping from one node to ~6 > others? It will take me a few days to find time to reproduce this, so > any interesting observations you can offer in the mean time would be > helpful. > > Thanks, > Thomas > _______________________________________________ > Devel mailing list > [email protected] > http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel >
_______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
