[tahoe-dev] [tahoe-lafs] #791: Optimize FEC parameters to increase download performance
tahoe-lafs
trac at allmydata.org
Thu Jan 14 21:50:58 PST 2010
#791: Optimize FEC parameters to increase download performance
---------------------------+------------------------------------------------
Reporter: swillden | Type: enhancement
Status: new | Priority: minor
Milestone: undecided | Component: code-encoding
Version: 1.5.0 | Keywords:
Launchpad_bug: |
---------------------------+------------------------------------------------
Comment(by warner):
incidentally, if we allowed the downloader to use a bit more RAM, we could
achieve maximum parallelism without raising {{{k}}}, by having it pull
shares for two segments at the same time (pull from servers(1..k) for
seg0, and from servers(k+1..2k) for seg1). If we were really clever, we
could time the requests such that the data for the second segment didn't
arrive at our downstream congestion point until most of the data for the
first segment had showed up, which might let us keep the downstream pipe
filled more.
Increasing {{{k}}} has the negative property that it leads to an increase
in {{{N}}}, and if {{{N}}} is capped by the total number of servers, then
the entropy of share placement (as explored in #872) drops to zero, so all
files get placed on the an identical set of servers, causing them all to
share the same fate. I don't yet know how overall reliability of
{{{k-of-N}}} vs {{{2k-of-2N}}} when the total number of servers is not
much larger than {{{2N}}}.. I'll have to think about that. I believe that
reliability roughly grows with {{{N-k-1}}}, so it's possible that {{{2k-
of-2N}}} is so much better than {{{k-of-N}}} that the peer-selection-
entropy is irrelevant.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/791#comment:3>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list