Changes between Initial Version and Version 1 of Ticket #1456, comment 2
- Timestamp:
- 2011-08-01T01:03:07Z (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1456, comment 2
initial v1 2 2 > 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? 3 3 4 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 20 ms 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.4 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 20s delay in the VPN setup as well as the 10s 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. 5 5 6 6 Replying to [comment:1 zooko]: … … 14 14 15 15 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. 16 17 [edited to correct ms -> s]
