"tahoe-lafs" <[email protected]> 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.
pgpxgd9PTEDKT.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
