[tahoe-dev] [tahoe-lafs] #1170: does new-downloader perform badly for certain situations (such as today's Test Grid)?

[Greg Troxel]

"tahoe-lafs" <trac at tahoe-lafs.org> writes:

>  Okay this does appear to be happening in at least one of the slow v1.8.0c2
>  downloads attached to this ticket. I looked at
>  attachment:1.8.0c2-r4698-run-106-down-0.html and every request-block in it
>  (for three different shares) went to the same server -- nszizgf5 -- which
>  was the first server to respond to the DYHB (barely) and which happened to
>  be the only server that had three shares. So at least for that run,
>  Brian's idea that fetching blocks of different shares from the same server
>  is a significant slowdown seems to be true.

nszizgf5 is mine.  For reasons not clear to me, it has 2.3G of shares on
it now, whereas three other systems I've been running for about the same
time have 500-800 MB; none have hit the storage limit.  It's pretty well
connected; I get 15 Mb/s to MIT and only 9 Mb/s to a machine on FiOS.
nszizgf5 is running netbsd-5 on xen and sharing a dom0 with quite a few
other systems, but none are really loaded.  The server process
doesn't seem to be using lots of resources:

tahoes   9261  0.0 16.0 135204 41908 ttyp0 - Sl   26Jul10 34:52.78 /usr/pkg/bin/python2.6 /usr/pkg/bin/tahoe run 

(135M total size, 42M RSS, 35m cpu time in 20 days.)


As an aside, at some point I'm likely to take my machines out of the
testgrid.  Given how small the testgrid is, that's likely to cause
trouble, but I'm taking it at face value that it's a *test*grid, and
assuming the ensuing recovery problems that cause unusual code paths to
be exercised will be viewed as a positive testing feature.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100814/a36c1ffa/attachment.pgp>