Hi, Javier
I have tried to setup one AP and one STA and do the throughput measurements
and compare with Mesh setup.
Based on the results, I observed that AP/STA mode using PSK2 has suffered
the same problem by loading the ath9k kernel module with nohwcrypt=1. It
registered the throughtput of ~14Mbps (HT20) if the nohwcrypt=1. For
nohwcrypt=0, it can achieve up to 50Mbps. There is additional process for
tx and rx, such as:
.....
pos += CCMP_HDR_LEN;
ccmp_special_blocks(skb, pn, scratch, 0);
ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, scratch, pos, len,
pos, skb_put(skb, CCMP_MIC_LEN));
.....
So software ccmp encryption and decryption is perhaps the bottleneck.
Regards,
Chun-Yeow
AP/STA Mode: (nohwcrypt=1)
# iperf -c 10.44.29.1 -i 1 -t 10
[ 3] 0.0-10.1 sec 17.9 MBytes 14.8 Mbits/sec
AP/STA Mode: (nohwcrypt=0)
# iperf -c 10.44.29.1 -i 1 -t 10
[ 3] 0.0-10.0 sec 50.5 MBytes 42.2 Mbits/sec
None-Secured Mesh:
# iperf -c 10.44.29.1 -i 1 -t 10
[ 3] 0.0-10.1 sec 34.6 MBytes 28.9 Mbits/sec
Secured Mesh: (nohwcrypt=1)
# iperf -c 10.44.29.1 -i 1 -t 10
[ 3] 0.0-10.1 sec 17.3 MBytes 14.3 Mbits/sec
On Tue, Nov 15, 2011 at 5:40 AM, Javier Cardona <[email protected]> wrote:
> 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
