[tahoe-dev] using the volunteer grid (dogfood tasting report, continued)

[zooko]

So now that I have connected to the volunteer grid and uploaded  
some .flac files, I decided to try playing them by streaming them  
directly from the grid.

The playout would stutter and die after a few seconds.  Using "wget"  
to download the same file from my localhost tahoe web gateway, I see  
that the file is coming in at between 74 and 96 KB/sec.  It looks  
like the flac encoding of this file (Metallica "Master of Puppets"  
track 1, "Battery") is at about 120 KB/sec, so the download is too  
slow to play my file!  By pointing my web browser at http:// 
speedtest.allmydata.com I can tell that my 'Net connection is around  
1500 KB/sec (1.5 MB/sec), so the limiting factor is probably that the  
volunteer grid storage servers can't deliver the shares over their  
upstream fast enough.  Remember, I'm using K=4, M=6 encoding, so it  
is pulling 4 shares at once from storage servers.  It always chooses  
the 0, 1, 2, and 3 -numbered shares if they are available, rather  
than choosing shares from the fastest servers or anything like that.   
Let's see which servers I was using, by clicking on the "check file"  
button:

Good Shares (sorted in share order):
0       xlnzwmko5inqjs4krxk35yj2sqjtb6ma (francois1 at tahoe.ctrlaltdel.ch)
1       y652ecs6ebjrx7xhzjoxjuv7x55te4gi (ndurner)
2       bfospckkw6pjyfqcwzktmlbqmmvsu7es (SECORP_DOT_NET_02)
3       hfhjhv7sop73qzjisoq5ksmhsf4fj47w (trid0)
4       ya2ecozyb2f4jw76aytgi7nrtbr3kavy (SECORP_DOT_NET_01)
5       gmrchxk774vogacbygkbuva3lt54e6vd (draco (Zooko's Mac/PPC 867  
MHz laptop))

Okay, so the combination of francois, ndurner, secorp, and trid put  
together gave me 74 KB/sec.  Perhaps one of those four can upload at  
most 18.5 KB/sec (one fourth of 74 KB/sec), and that one's upstream  
bandwidth is the limiting factor in this.

Then I had an idea.  There are currently 13 servers registered with  
the volunteer grid introducer.  (Okay, so only 10 are currently  
connected to the introducer, and that includes my own localhost.)   
Why not upload the same file with K=13 and see if it downloads  
faster?  I set shares.needed to 13 and shares.total to 16 in my  
tahoe.cfg, restarted the node, and re-uploaded the file.  Now when I  
wget it, it comes down at around 150 KB/sec!  Whoo!  Now I can stream  
it!

Okay, but here is a question: is this faster because it is pulling  
down 13 shares in parallel instead of 4 shares in parallel, or is it  
faster because the servers that it randomly selected exclude the  
slowest ones?

Good Shares (sorted in share order):
0       rwr3sxefpgoqwj54xuwbrx4qp6bxcfis (SECORP_DOT_NET_03)
1       ya2ecozyb2f4jw76aytgi7nrtbr3kavy (SECORP_DOT_NET_01)
2       hfhjhv7sop73qzjisoq5ksmhsf4fj47w (trid0)
3       qf2xzeetsr5wkk2hx7bvdx74hohnfpqt (SECORP_DOT_NET_04)
4       bfospckkw6pjyfqcwzktmlbqmmvsu7es (SECORP_DOT_NET_02)
5       5ouv6kibslfodqbmifie3kfru2v5jnd7 (trelbox)
6       y652ecs6ebjrx7xhzjoxjuv7x55te4gi (ndurner)
7       xjy2clbqg3pdtk72tbwfi6v45wsa6nd5 (yukyuk (Zooko's Athlon64  
Linux workstation))
8       xlnzwmko5inqjs4krxk35yj2sqjtb6ma (francois1 at tahoe.ctrlaltdel.ch)
9       gmrchxk774vogacbygkbuva3lt54e6vd (draco (Zooko's Mac/PPC 867  
MHz laptop))
10      rwr3sxefpgoqwj54xuwbrx4qp6bxcfis (SECORP_DOT_NET_03)
11      ya2ecozyb2f4jw76aytgi7nrtbr3kavy (SECORP_DOT_NET_01)
12      hfhjhv7sop73qzjisoq5ksmhsf4fj47w (trid0)
13      qf2xzeetsr5wkk2hx7bvdx74hohnfpqt (SECORP_DOT_NET_04)
14      bfospckkw6pjyfqcwzktmlbqmmvsu7es (SECORP_DOT_NET_02)
15      5ouv6kibslfodqbmifie3kfru2v5jnd7 (trelbox)

Okay, so of the top 13 servers in this list, we know that each one  
can at least provide 150 KB/sec divided by 13 == 11.5 KB/sec.  Also  
note that it get multiple shares from SECORP_DOT_NET_03,  
SECORP_DOT_NET_01, trid0, and SECORP_DOT_NET_04.

Then I thought: Hm, wait a second, I have 13-of-16 encoding here,  
which means the file can survive the loss of any 3 shares.  But,  
several of those servers are holding more than one share.  The loss  
of both trid0 and SECORP_DOT_NET_01, for example, would take away 4  
shares and leave only 12 -- not enough to recover my file.  (This is  
quite apart from the issue that I mentioned in my previous dogfood  
tasting report -- that I would like to store an equal amount of  
shares with each *operator* rather than with each *machine*.)

So now I've set my shares.total to 26 (leaving shares.needed at 13),  
and am re-re-uploading the file.  I'll report again on this once that  
is done.  :-)

Regards,

Zooko