[tahoe-dev] [tahoe-lafs] #791: Optimize FEC parameters to increase download performance

tahoe-lafs trac at allmydata.org
Fri Jan 15 05:50:58 UTC 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