[PATCH] P2P: Reduce the idle time of Wait in Wait peer connect state or increase the listen time

[Jouni Malinen]

On Mon, Dec 12, 2011 at 02:09:26AM -0800, Neeraj Kumar Garg wrote:
> When waiting for go_neg frame from the peer in WAIT_PEER_CONNECT state, I have observed that sometimes it takes 20 to 30 secs for successful go negotiation. I also found out that it is because of 1 second idle time, in WAIT_PEER_CONNECT state. While it is good to have 1 second idle time [for doing power-save or doing some other legacy STA Scan or some other useful stuff], this makes go-neg process slow.

Thanks for bringing this up! For some reason, I don't see this in that
significant way in my tests and while the question itself had come up
previously as shown by the TODO comment there, this didn't look like
critical issue in practice. However, if you are indeed hitting times
like 20 to 30 seconds, this does indeed need some fine tuning.

> We wait for 1 second idle and then listen for a random time between 200(min)-300(max)ms. Assume P1 is in WAIT_PEER_CONNECT state and P2 is the one which is now to send go_neg frame. If P2 sends Go-neg frame just at the boundary of 300ms of P1 and assume that P2 takes close to 600-800ms for one iteration of sending go_neg request (one iteration is go_neg_request frame time + dwell time + listen_time), P2 needs to transmit at least 16-18 action frames for hitting the listen time of P1.

I see quite a bit more frequent retries on my test station that 600-800
ms interval which can obviously speed up the GO Negotiation process
quite a bit. I'd guess this can depend quite a bit on the driver and how
much extra latency there is in channel changes and Action frame TX
operations.

> Following patch reduces the idle time to 500ms. Alternatively we can increase the listen time interval to 500ms just for WAIT_PEER_CONNECT state. Please let me know which approach we should take

I applied this because it is a very simple change and sounds very much
justifiable. Ignoring the extra latencies, this moves from 9..23% in
listen to 16..37% which should make it quite a bit more likely for the
other peer to be able to get an Action frame through.

Anyway, the TODO comment in p2p_timeout_wait_peer_connect() is still
relevant and I think we should really take a look at implementing it.
The idle time here could be adjusted automatically based on what else
could be happening with the radio. If there is no other connection
(e.g., legacy STA associated with an AP) in progress, the idle wait
should really be reduced quite a bit more. This can come at a cost of
more battery use, but for most cases, this should be acceptable since
the device is actually trying to connect with the peer in this
particular case.

-- 
Jouni Malinen                                            PGP id EFC895FA