#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:  dsd-11.3.0?                      
        Next_action:  test in build  |    Verified:  0                                
Deployment_affected:                 |   Blockedby:                                   
           Blocking:                 |  
-------------------------------------+--------------------------------------

Comment(by jnettlet):

 Conversation about reducing the qlen with JG and Quozl.

 <dsd_> jnettlet: not keen on doing any non-upstream kernel patches, we
 could look at the NM thing, but i'd prefer to follow jg's advice. and if i
 understood it right, he said "wait"
 <jnettlet> dsd_, okay.  I thought he said for most XO deployment workloads
 we would benefit from making the change.
 <-- erikos has quit (Quit: Leaving)
 <dsd_> feel free to get clarification :)
 <jnettlet> I guess we should ping him.  I know he asked me at some point
 if we had made the change.
 --> jg (~jg at c-24-218-177-117.hsd1.ma.comcast.net) has joined #olpc-devel
 <jnettlet> jg, ping - we were just talking about you.
 <jg> jnettlet: nothing bad, I hope.
 <jnettlet> jg, not at all.  We are just starting dev for 11.3.0 and were
 trying to decide what the final consensus was for dropping the default
 txqlen on the XO's
  in your expert opinion, is it generally a good idea to do now, or should
 we wait for more robust solutions to be implemented?
 <jg>  jnettlet: you'd wait a long time.
  jnettlet: eBDP won't go upstream in its current form.
 <jnettlet> jg, so adding something to NetworkManager that reduces the qlen
 on connection, is not a bad idea?
 <jg> basically, you'll never see more than around 10Mbps on an X01; it's
 overbuffered by approaching a factor of 100.
 <jg> jnettlet: I'd not put it in network manager.
 <jnettlet> why is that?
 <jg> you'd just need to change the script that nm calls when the interface
 goes up.
 <cjb> (I've started up the google+ hangout for the eng meeting now -- feel
 free to join anytime in the next ten mins, yell if you can't see it.)
 <jnettlet> jg, yeah I have a script that runs in NetworkManagers
 dispatcher.d
 <Quozl`> i thought the ticket i raised for this had an adequate
 justification merely by reducing observed latency across a typical single
 access point wireless network.  80/20 rule.  80% of the work isn't rocket
 science, and is easy to prove as benefit.
 <jnettlet> Quozl`, I agree, just trying to get everyone's opinion, and
 time frames etc.
 <jg> jnettlet: you'll still be badly overbuffered, but it will be one hell
 of a lot less...
 <jg> an adaptive algorithm like eBDP is needed for that, though.
 <Quozl`> jnettlet: it's not the sort of change that deserves opinion and
 time frame and consensus, if just one other person can bother to reproduce
 my results.
 <jg> and ultimately AQM, but we don't yet know of an algorithm that will
 work.
 <jnettlet> Quozl`, well that is why I started poking dsd to get it into
 11.3.0.  Then if people start yelling at us about network problems we have
 plenty of time to research it.
 <Quozl`> jnettlet: and for want of a nail my kingdom falls?  ;-)
 <jnettlet> jg, okay thanks for the input.
 <jg> hey, guys; this isn't rocket science to reduce txqueuelen; it's doing
 the rest of it that's rocket science, and for which thought is required.
 <Quozl`> i've no further technical input.
 <pgf> i like Quozl` comment in #11116, regarding adding a script to help
 retrieve model, s/n, etc.
 <saadia_> cjb: found a little python program on this page
 http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval that I can
 expand upon (half way down the page)
 <pgf> how does this look:  http://dev.laptop.org/~pgf/z/pb1312921380.txt
 <cjb> saadia_: hey, I wrote one of those
 <Quozl`> pgf; +1
 <cjb> https://github.com/cjb/freerunner-rotate
 <jg> you can even calculate this from first principles: 10 megabits, with
 100ms delay to cover a continent is about 1,000,000 bits, or 83 packets
 buffering (at the outside).  so cutting it down to that level can't
 possibly hurt you....  In practice, you'd probably be better off going
 much lower yet.  While the bandwidth/delay product is basically useless,
 it does tell you the maximum upper bound for buffering you can possibly
 ever need.
 <saadia_> Well why didn't you say so :-)
 <jnettlet> Quozl`, I guess for real world testing we will need to setup
 some network simulation to see what txquelen is most desirably
  desirable
 <Cerlyn> cjb: Might be worth posting the URL being used to the list as I
 don't see the information automatically
  cjb: NM finally came through
 <Quozl`> jnettlet: i have asked the local deployment for assistance in
 testing at a school, with me in person monitoring their network, with a
 modified browse on each xo that measures page load time.  but i guess even
 after doing that there would be resistance.
 <jg> jnettlet: it isn't worth that kind of anguish.  dynamic control of
 buffering and/or AQM isn't ready for primetime.  having buffering set as
 though the interface is running at 1Gbps is insanity.

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