<div dir="ltr">On Sun, Aug 14, 2016 at 4:02 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Aug 15, 2016 at 12:49 AM, Aaron Wood <<a href="mailto:woody77@gmail.com">woody77@gmail.com</a>> wrote:<br>
> On Sun, Aug 14, 2016 at 3:21 PM, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> Ideas as to why crypto chops off so much throughput in the first place<br>
>> (from 120mbit to 80), and as to what else to poke into with crypto on,<br>
>> would be nice.<br>
><br>
><br>
> Crypto as in WPA2?  If 1 client is fine, but multiple clients is not, my<br>
> guess is that changing the AES key in the crypto accelerator is<br>
> slow/difficult, and so what you're seeing is the lost time as it switches<br>
> security contexts.<br>
<br>
</span>1 client suffers degradation with more than one flow in flight, being<br>
fq'd, and crypted with wpa2.<br>
<br>
I'll have plots in the morning.<br></blockquote><div><br></div><div>So it's not, that, then.  Unless it's doing something dumb with the keys when it switches flows (since that's now an interrupt back up to the driver?)</div><div><br></div><div>-Aaron </div></div></div></div>