[tahoe-lafs-trac-stream] [tahoe-lafs] #1456: High latency for 'tahoe get' if 'tahoe put' in parallel

[tahoe-lafs]

#1456: High latency for 'tahoe get' if 'tahoe put' in parallel
-------------------------+-------------------------------------------------
     Reporter:  T_X      |      Owner:  T_X
         Type:  defect   |     Status:  new
     Priority:           |  Milestone:  undecided
  critical               |    Version:  1.8.2
    Component:  code     |   Keywords:  download upload latency performance
   Resolution:           |  gateway vm kvm vpn trickle
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by T_X):

 Replying to [comment:1 zooko]:
 > However, I'm still confused and need more help from you to understand
 what's going on. Could you summarize in one paragraph of English -- like
 not more than 3 or 4 sentences what is wrong and how you know it is
 happening?

 The issue is that when doing a 'tahoe put' in the background (which is not
 limited in throughput itself) that a parallel 'tahoe get' seems to be
 delayed unreasonably long (and I'm considering the 20ms delay in the VPN
 setup as well as the 10ms in the VM setup as unreasonable, badly
 influencing the end user experience). It seems like a tahoe gateway is
 prefering the 'tahoe put' to the 'tahoe get' - or at least not serving the
 'tahoe get' as timely as it should - the 'tahoe get' should always get a
 response at about the same time as it gets without the parallel 'tahoe
 put'. I know that this is happening due to the long time the 'tahoe get'
 needs as seen in test 2 and test 3 as well as in the the vpn setup stated
 on the mailing list and even when 'tahoe put' saturates the available
 capacity, it shouldn't take that long for the 19 Bytes to finish
 downloading.

 Replying to [comment:1 zooko]:
 > The fact that it took 560 seconds to do a {{{tahoe get}}} (after which
 it completed successfully instead of erroring out?) is definitely an
 indication of something very wrong. I'm still hoping it turns out to be
 something wrong in your test rig or scripts rather than in Tahoe-LAFS, but
 we'll see. :-)

 Actually, the >500s delay I'm having in test 2 was something I didn't
 expect when setting up this VM configuration as I didn't see that in the
 VPN test before. I don't know if this issue is related or having a
 different cause than the 10 or 20s delays. However this delay is very
 reproducible and always happens during the beginning of test 2, so I think
 it is an issue within tahoe-lafs.

 Replying to [comment:1 zooko]:
 > As far as I can tell from a quick scan of your script Download, it isn't
 checking the return value or inspecting the resulting downloaded file to
 be sure it worked.


 Hmm, true, but at least 'tahoe get' didn't complain and gave me ten times
 "tahoe:tahoe-file2download retrieved and written to /tmp/tahoe-
 file2download" (still have the log in gnu screen session here and just
 checked). Otherwise it'd be another issue with tahoe not giving an error
 message - but, sure, I can add a 'rm' and then a check after the 'tahoe
 get' and run the tests again.

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