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 <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com
