[tahoe-dev] [tahoe-lafs] #1170: new-downloader performs badly when downloading a lot of data from a file

[tahoe-lafs]

#1170: new-downloader performs badly when downloading a lot of data from a file
------------------------------+---------------------------------------------
     Reporter:  zooko         |       Owner:                                           
         Type:  defect        |      Status:  new                                      
     Priority:  critical      |   Milestone:  1.8.0                                    
    Component:  code-network  |     Version:  1.8β                                     
   Resolution:                |    Keywords:  immutable download performance regression
Launchpad Bug:                |  
------------------------------+---------------------------------------------

Comment (by zooko):

 [attachment:run-zooko1000-curl-stdout.txt run-zooko1000] was from my local
 coffeeshop—Caffe Sole in South Boulder—and the [attachment:run-
 zooko1000-status.html status.html] shows this interesting pattern that the
 downloader immediately issued 10 DYHB queries (as expected), and then it
 took 9.6 seconds for the first DYHB response to arrive. Then the
 ''really'' weird, part, it took 8.4s more for the next seven DYHB
 responses to arrive (totalling 18s from request to response)! Then, still
 weird, it took a total request-to-response time of 6 minutes for the ninth
 response and a total of 8 minutes for the tenth. Also, as soon as the
 first response arrived the downloader issued a new DYHB request, and
 ''that'' one, the eleventh one, took 8.92s for the response to arrive.

 So, I suppose there is something very messed up about the network at my
 local coffeeshop. Perhaps it blocks a flow that starts on an idle TCP
 connection while it is trying to figure out how to insert ads into any
 HTTP responses, or something. Note that these TCP connections were all
 already established long before the download began.

 Take-aways?

 I guess it is that we should not make assumptions about "reasonable" for
 IP traffic. That is: ''if'' we want to support people who use Tahoe-LAFS
 from coffeeshops, over tethered cell phones, at Burning Man, on satellite
 uplinks, on the International Space Station, etc. (which I do).

 Another take-away is that 1.8.0c2+combo.diff did pretty well in this
 situation! (I think 1.7.1 probably would have done well too but I didn't
 get a chance to try it.)

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1170#comment:79>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage