#9048 HIGH Not Tri: Wireless scanning causes network pauses

[Zarro Boogs per Child]

#9048: Wireless scanning causes network pauses
---------------------------------+------------------------------------------
           Reporter:  johnf      |       Owner:  mbletsas        
               Type:  defect     |      Status:  new             
           Priority:  high       |   Milestone:  Not Triaged     
          Component:  wireless   |     Version:  not specified   
         Resolution:             |    Keywords:  scan packet loss
        Next_action:  never set  |    Verified:  0               
Deployment_affected:  Australia  |   Blockedby:                  
           Blocking:             |  
---------------------------------+------------------------------------------
Changes (by carrano):

 * cc: carrano (added)


Comment:

 As already noted, there is loss of egress traffic while the interface is
 scanning.

 As expected, in traffic captures the loss can be associated to the sending
 of the two null frames (type/subtype 0x24) - the one with PWR MGT flag set
 (going to sleep) and the one with the flag unset (coming back) - that
 "protect" the scanning period (but only for ingress traffic).

 The typical interval between these two frames is 0.45 seconds, hence the 4
 to 5 frames lost in ping -i .1 <...>.

 The pattern for the null frames is very consistent, two groups separated
 by 10 seconds, each of these groups formed of 4 pairs of null frames
 (going to sleep and returning), each pair separated by 0.75 seconds, and
 with sleep time of 450ms (but the last one, which lasts for 120ms). The
 pattern is:


 0.00 (450ms)

 0.75 (450ms)

 1.50 (450ms)

 2.25 (120ms)

 (repeat after 10 seconds)

 This is consistent with the scanning commands sent to the firmware. In
 each group, four scanning commands are sent to the firmware. For the first
 three commands, four channels are scanned (hence the 450ms), and one
 channel is scanned in the last command (hence the shorter period of
 120ms), accounting for 13 channels.

 After 110 seconds the process restarts, because NetworkManager demands.

 It is interesting to note that the losses does not occur at every time the
 interface scans. (if this was the case, at every 110 seconds the losses
 would be of about 29 to 30 packets, not 4 to 5.

 When there is scanning and no loss of egress traffic is noted there is
 high associated jitter in the icmp traffic, indicating that the frame was
 buffered for long enough (.5 seconds) before being sent.

 This all points to insufficient buffer capabilities to keep frames during
 this .45 seconds *under high traffic conditions*.

 It is not clear to me if (honest questions, there is probably a good
 reason):
 - we need NetworkManager to scan for the interface at every 110 seconds.
 - we need to do it twice for each request (separated by 10 seconds).
 - we need to scan 4 channels at a time (taking a long time to do so). Why
 we don't scan 4-3-3-3, channels, instead of 4-4-4-1, or maybe we should
 scan 3-3-3-2-2?

-- 
Ticket URL: <http://dev.laptop.org/ticket/9048#comment:15>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system