[tahoe-dev] [tahoe-lafs] #1180: put more DYHBs into flight at once when K is larger
tahoe-lafs
trac at tahoe-lafs.org
Fri Oct 22 14:57:32 UTC 2010
#1180: put more DYHBs into flight at once when K is larger
------------------------------+---------------------------------------------
Reporter: zooko | Owner:
Type: defect | Status: new
Priority: major | Milestone: soon
Component: code-network | Version: 1.8β
Resolution: | Keywords: easy immutable download performance regression
Launchpad Bug: |
------------------------------+---------------------------------------------
Comment (by swillden):
Replying to [comment:1 zooko]:
> Because that case is increasingly interesting to me nowadays since (as
mentioned in [http://tahoe-lafs.org/pipermail/tahoe-
dev/2010-September/005247.html this mail to tahoe-dev]), I think people
should probably start setting {{{K}}} at least as large as the number of
servers on their grid.
Set {{{K}}} to the number of servers in the grid? The e-mail you
reference (and the analysis that I've done) recommends setting {{{M}}} to
the number of servers in the grid and scaling {{{K}}} to achieve the
desired level of redundancy.
Intuition says that setting {{{K=N}}} and {{{M=K*3.33}}} should achieve
roughly the same level of reliability for an expansion factor of 3.33 as
setting {{{M=N}}} and {{{K=M/3.33}}}, but I haven't done the math to
verify it.
In any case, I think larger values of {{{K}}} and {{{M}}} are definitely a
good idea, and getting good performance with larger values is important if
we want to encourage people to use them. I'd certainly use them if I had
access to a large-enough grid to make it worthwhile.
--
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1180#comment:2>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-dev
mailing list