Hello,
One of my test cases is to create lots of virtual station devices, and run bi-directional
TCP traffic between them an an Ethernet port, through an AP. My automation is doing
around 7 tcp flows per station vdev.
This test is reliably falling apart at around 30 stations on an i7 2-core processor
system. Interesting to me is the perf top in this state. The stop_queue reliably
dominates.
1 22.20% [kernel] [k] __ieee80211_stop_queue
2 7.66% [kernel] [k] __lock_acquire_lockdep.isra.36
3 4.46% [kernel] [k] queued_spin_lock_slowpath
4 4.40% [kernel] [k] lock_release
5 4.18% [kernel] [k] lock_acquire
6 1.47% btserver [.] bitfield::get
7 1.45% [kernel] [k] sock_poll
8 1.32% [kernel] [k] tcp_poll
9 1.30% libc-2.23.so [.] __memset_sse2
10 1.26% [kernel] [k] do_raw_spin_lock
11 1.06% btserver [.] Cell<BaseEndpoint*>::next
12 0.85% btserver [.] Endpoint::doTrafficRound
13
At 180 to 190 stations, the situation significantly improves. At this point, there are only
two flows per station.
If I limit to one TCP flow per station for all numbers of vdevs, then it does not have total failures like it does with more
streams, but the stop_queue still dominates the perf top at higher numbers of stations (like 60-70).
I need to do some more testing with other kernels and such, but curious if anyone
has any suggestions as to why stop_queue is taking so much time?
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com