#10904 NORM Future : reduce txqueuelen

[Zarro Boogs per Child]

#10904: reduce txqueuelen
-------------------------------------+--------------------------------------
           Reporter:  Quozl          |       Owner:                                   
               Type:  defect         |      Status:  new                              
           Priority:  normal         |   Milestone:  Future Release                   
          Component:  not assigned   |     Version:  Development build as of this date
         Resolution:                 |    Keywords:                                   
        Next_action:  test in build  |    Verified:  0                                
Deployment_affected:                 |   Blockedby:                                   
           Blocking:                 |  
-------------------------------------+--------------------------------------

Comment(by jg):

 Not too far from reality but....  Unfortunately this is complicated (which
 is why things got into this mess in the first place)

 a) you can't set (nor should you set) the txqueuelen to zero; the OLPC has
 very little buffering in the driver and module (at least for the XO-1).
 Some buffering is necessary. This is quite different than most current
 hardware, which often has hundreds of packets of buffering in the
 wireless/ethernet drivers.  That's why I was doing that in my experiments;
 if you do it in yours, you'll get into

 It has (having talked to both dwmw2 and Javier) 1 packet of buffering in
 the driver itself and 4 in the wireless module.

 b) the long term solution is proper queue management: but we don't have
 things we know work yet; so the best you can do is to mitigate (reduce)
 the problem until we do.  We're playing with eBDP and other algorithms,
 but it's a way off before we have anything I can recommend you (or anyone)
 deploy.  We've just started testing these algorithms.  Check in with me in
 some months.

 c) given the classic (and fundamentally flawed; in practice you never know
 either the bandwidth, or the delay, nor the amount of contention on the
 wireless) bandwidth delay product rule, you'd end up needing a worst case
 buffering (at 10Mbps actual data transferred, which is about what I
 remember the Marvell module could/would do) of 200 packets (presuming
 300ms delay, which is more than planetary: continental US is 100ms, which
 is presuming you have an unshared medium going over a very, very, very
 slow back haul network; with ConUS delays, you'd only need 66 packets).
 See (b) above.

 So given how slow the XO-1's wireless is, you can safely set the transmit
 queue to 200 and *never* need more buffering; but I expect in practice,
 something significantly lower would be better (since you seldom get full
 bandwidth in the high delay back haul, and you want local collaboration to
 work much better).  Even just moving it to 200 reduces the problem under
 load by a factor of five (at least).

 However, at, say 1Mbps on a shared ethernet under load, 200 packets works
 out to 3 second latency, enough to cause serious trouble and failures.  I
 personally would try something in the 50 packet range.  This would
 sacrifice theoretical bandwidth that in practice in a school no one would
 never see, but bound the latency on a somewhat loaded school network to
 something reasonable.

 Note this won't hurt your local performance: your delays are way shorter
 (just a few milliseconds).

 If you do the basic arithmetic of how short the queues *should* be managed
 to, for example, to enable VOIP latencies under load, you'll find the
 queues should be radically shorter yet (the moving average minimum queue
 length) and we'll need classification too.  The real answer, of course, is
 that we all need real AQM, at which point how much buffering is present is
 no longer an issue, though we'll still need some classification to get
 best results.

 Catch me on IRC with any questions.

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