[tahoe-dev] let's do Tahoe-LAFS v1.8 this weekend

[Zooko O'Whielacronx]

Folks:

Anyone who can help, let's get together this weekend and finish up
Tahoe-LAFS v1.8.0! You can see what needs to be done by examining the
tickets on the Roadmap [1].

For people who want to do performance measurement, I packaged up a
version named "v1.8.0c3" last night which you can download from here:
[2]. It isn't *really* the final release candidate because bug #1191
still lives, but it is very close.

Anyway, if you can compare the performance of v1.8.0c3 to any previous
versions of Tahoe-LAFS that you have measured, that would be helpful.
v1.8.0c3 is expected to be better-performing than both v1.7.1 and
v1.8.0c2 for almost all server/share layouts, and much
better-performing for certain layouts.

That's because:

 * v1.8.0c3 fixes the bug which caused greater CPU usage for larger
files, so v1.8.0c3 is dramatically more efficient for downloading
large files than v1.8.0c2.

 * v1.8.0c3 chooses to use shares from several different servers if
possible, unlike v1.8.0c2 which would use multiple shares from the
same server sometimes.

 * v1.8.0c3 chooses to use shares from the fastest servers as measured
by their round-trip-time in response to Do-You-Have-Blocks (unlike
v1.7.1 which would use the lowest-numbered shares from among the first
few servers that responded to DYHB, and unlike v1.8.0c2, which would
use as many shares as it could from the first server that responded)

Regards,

Zooko

[1] http://tahoe-lafs.org/trac/tahoe-lafs/roadmap
[2] http://tahoe-lafs.org/source/tahoe-lafs/releases/allmydata-tahoe-1.8.0c3.tar.bz2

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1191# unit test failure:
failed to download file with 2 shares on one server and one share on
another