Hi Yeoh, The authentication daemon is not in the data path: its role ends once a new candidate has been authenticated, keys derived and peering established. These are the things we investigated, without much success:
Q1: Are HT data rates used for secured mesh traffic? A1: Yes, we confirmed that. Q2: Are there more retries/corrupted frames on secured traffic vs. open mesh traffic? A2: No. In our environment we observed roughly 10% retransmission rates. Q3. Is encryption/decryption bound by CPU? A3: We did observe a 10% higher CPU usage when running mesh in secure mode. But our host CPU had ample available cycles to handle that. Q4: Is software encryption/decryption adding latency to the datapath and hence decreasing throughput? A4: We did not observe any additional inter-frame latency. Q5. Is this HT-related? A4: No, we have also observed decreased throughput in non-HT modes. To summarize: We have also observed the decreased throughput in secured mode (in our setup, ~50% throughput reduction) and so far we have not found where the bottleneck is yet. Cheers, Javier On Sun, Nov 13, 2011 at 6:05 PM, Yeoh Chun-Yeow <[email protected]> wrote: > Hi, Thomas > > Managed to get the secured mesh up after applying the linked patch. I have > managed to test the HT20 mode for secured mesh and non-secured mesh due to > my embedded platform only supports Fast Ethernet. Here are the results: > > Non Secured Mesh (HT20) > # iperf -s -i 1 > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 85.3 KByte (default) > ------------------------------------------------------------ > [ ID] Interval Transfer Bandwidth > [SUM] 0.0-10.0 sec 72.0 MBytes 60.1 Mbits/sec > > Secured Mesh (HT20) > # iperf -s -i 1 > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 85.3 KByte (default) > ------------------------------------------------------------ > [ ID] Interval Transfer Bandwidth > [SUM] 0.0-10.1 sec 15.6 MBytes 13.0 Mbits/sec > > A bit disappointed that the throughput is drop quite significantly. Confirm > that the aggregation is working: > > Rx A-MPDU request on tid 0 result 0 > Open BA session requested for 0a:0b:6b:7d:e3:b9 tid 0 > activated addBA response timer on tid 0 > switched off addBA timer for tid 0 > Aggregation is on for tid 0 > > Regards, > Chun-Yeow > > On Wed, Nov 9, 2011 at 5:13 AM, Thomas Pedersen <[email protected]> wrote: >> >> Hi Chun-Yeow, >> >> Have you had any success? >> >> I did not have time to properly to properly test throughput in a >> secure mesh laste time, but now with our ft-ht-mesh + ft-mesh-fixes >> branches, I'm seeing 55.5Mb/s TCP throughput with a 243Mb/s datarate. >> Throughput in the non-secure case is more like at least 100Mb/s, so it >> seems we have quite a bit of overhead. >> >> Thomas >> >> On Thu, Nov 3, 2011 at 6:28 PM, Yeoh Chun-Yeow <[email protected]> >> wrote: >> > Hi, all >> > Ok. I need to reconfigure authsae in htmode to HT20 and transmission >> > rate >> > increased up to 104Mbps with TCP throughput about 7Mbps. >> > But as Thomas pointed out, aggregation is not working. >> > Regards, >> > Chun-Yeow >> > >> > On Fri, Nov 4, 2011 at 9:04 AM, Yeoh Chun-Yeow <[email protected]> >> > wrote: >> >> >> >> Hi, all >> >> I have captured the packet via Wireshark. It shows that the bit rate >> >> used >> >> by the two mesh nodes is 6Mbps. That's why the throughput is low. >> >> Regards, >> >> Chun-Yeow >> >> On Fri, Nov 4, 2011 at 1:50 AM, Thomas Pedersen <[email protected]> >> >> wrote: >> >>> >> >>> It seems ADDBA requests are dropped by a peer when security is >> >>> enabled, thanks for reporting this! >> >>> >> >>> Thomas >> >>> >> >>> On Thu, Nov 3, 2011 at 9:41 AM, Thomas Pedersen <[email protected]> >> >>> wrote: >> >>> > Hi Chun-Yeow, >> >>> > >> >>> >> Using authsae, I only managed to get 4Mbps. However, without SAE, I >> >>> >> managed >> >>> >> to obtain 60Mbps using iperf 10 parallel TCP streams. >> >>> >> Others are getting the same results? It seems that performance drop >> >>> >> is >> >>> >> too >> >>> >> significant. >> >>> > >> >>> > Did you set the correct channel type with iw before bringing up >> >>> > authsae? >> >>> > >> >>> > Thomas >> >>> > >> >> >> > >> > > > -- Javier Cardona cozybit Inc. http://www.cozybit.com _______________________________________________ Devel mailing list [email protected] http://open80211s.com/mailman/listinfo/devel
