#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):

 Aug 09 12:54:39 -->     jg (~jg at c-24-218-177-117.hsd1.ma.comcast.net) has
 joined #olpc-devel
 ||Aug 09 13:15:02||jnettlet||jg, ping - we were just talking about you.||
 ||Aug 09 13:15:24||jg||jnettlet: nothing bad, I hope.||
 ||Aug 09 13:16:17||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||
 ||Aug 09 13:17:07||jnettlet||in your expert opinion, is it generally a
 good idea to do now, or should we wait for more robust solutions to be
 implemented?||
 ||Aug 09 13:17:26||jg|| jnettlet: you'd wait a long time.||
 ||Aug 09 13:17:43||jg||jnettlet: eBDP won't go upstream in its current
 form.||
 ||Aug 09 13:18:12||jnettlet||jg, so adding something to NetworkManager
 that reduces the qlen on connection, is not a bad idea?||
 ||Aug 09 13:18:13||jg||basically, you'll never see more than around 10Mbps
 on an X01; it's overbuffered by approaching a factor of 100.||
 ||Aug 09 13:18:32||jg||jnettlet: I'd not put it in network manager.||
 ||Aug 09 13:19:20||jnettlet||why is that?||
 ||Aug 09 13:19:36||jg||you'd just need to change the script that nm calls
 when the interface goes up.||
 ||Aug 09 13:20:40||jnettlet||jg, yeah I have a script that runs in
 NetworkManagers dispatcher.d||
 ||Aug 09 13:20:47||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.||
 ||Aug 09 13:21:54||jnettlet||Quozl`, I agree, just trying to get
 everyone's opinion, and time frames etc.||
 ||Aug 09 13:22:02||jg||jnettlet: you'll still be badly overbuffered, but
 it will be one hell of a lot less...||
 ||Aug 09 13:22:26||jg||an adaptive algorithm like eBDP is needed for that,
 though.||
 ||Aug 09 13:22:47||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.||
 ||Aug 09 13:22:49||jg||and ultimately AQM, but we don't yet know of an
 algorithm that will work.||
 ||Aug 09 13:23:31||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.||
 ||Aug 09 13:24:07||Quozl`||jnettlet: and for want of a nail my kingdom
 falls?  ;-)||
 ||Aug 09 13:24:31||jnettlet||jg, okay thanks for the input.||
 ||Aug 09 13:24:49||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.||
 ||Aug 09 13:24:50||Quozl`||i've no further technical input.||
 ||Aug 09 13:27:50||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.||
 ||Aug 09 13:27:59||jnettlet||Quozl`, I guess for real world testing we
 will need to setup some network simulation to see what txquelen is most
 desirably||
 ||Aug 09 13:28:02||jnettlet||desirable||
 ||Aug 09 13:29:58||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.||
 ||Aug 09 13:30:56||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.||
 ||Aug 09 13:31:07||jg||so just cut it down to something sane.||
 ||Aug 09 13:31:33||jnettlet||Quozl`, jg, sounds good.  okay if I grab this
 IRC chat and add it to the bug?||
 ||Aug 09 13:32:14||jg||If you care only about performance in a school,
 (and don't mind having an upper bound of 1Mbps on how fast you can get
 things across the continent), then even 10 packets of buffering would
 suffice.  And there are 4 buried inside the wireless module (at least on
 X01).||
 ||Aug 09 13:32:26||jg||and a 5th inside the driver itself.||
 ||Aug 09 13:32:47||jg||but continuing at 1000 packets, now that is
 insanity.||
 ||Aug 09 13:33:22||jg||jnettlet: heh. IRC is as good as public.||
 ||Aug 09 13:33:37||jnettlet||jg, yes but I like to be polite||
 ||Aug 09 13:37:55||jg||if you like, I can give you a quick lecture on
 network buffering (since I just finished the first draft of a paper on
 bufferbloat today).||

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