[BitTorrent] An alternative "super-seed" mode
jcea at argo.es
Sun Jan 30 20:39:55 EST 2005
Mike Ravkine wrote:
>>2. What if a peer transfer a piece to another peer, but that peer goes
>>offline?. The seeder never saw the transfer and penalize the first peer
>>not sending it more "have" messages ever. So that peer will be
> This isn't a problem, as the piece will still eventually show up on
> another peer.
No if the peer has died. While, the original peer keeps being "ignored".
>>With this environment i'm confused. The original Super-seed algorithm
>>works fine if the swarm is big, but my original proposal seems to do a
>>better work if the swarm is very small (let say, 5 peers).
> What you're trying to do is maximize download speed for every member of
> the swarm. This is NOT THE SAME GOAL as superseed.
I understand. In fact doing some calculations, the stationary state for
my algorithm is that each peer, if launched simultaneously, reach full
download state at the very same time, if they download speed is high
enough to match the seeder. That is the case for my environment.
I must insists in that my network is a bit particular. It is a -very-
small swarm. We are trying to get maximum efficiencies in a private and
very assimetric network. Something like this:
- Seeder: 512Kbps.
- Peers: 512/128Kbps (about a dozen, 1-4 active for each torrent)
- Superpeer: Unlimited BW. This node is interested in very few torrents.
The swarms are so small that the choke algorithm is not activated, I
> What are you efficiency measurements with and without superseed, and
> with your modified superseed? I'd like to see some numbers..
I'm having now about 150-200% BW usage. I've not using superseed
(standard BT client doesn't support it) and my proposal is only a
proposal; no code yet. In fact this mesages were trying clarify the
situation before touching any code :).
But we can do some math:
For a torrent with two 512/128Kbps peers (and the seeder):
1. For the standard algorithm, seeder sends 256Kbps to each peer. Each
peer sends 128Kbps to the other. So, each peer gets 384kbps. The BW
usage for the seeder will be 133'3%, if the seeder feeds the swarm all
the time. If it stops feeding it when te entire file is out (100% BW
usage), the peers will feeds each other at 128kbps. That instant will be
when each peer has 66'6% of the file. So median speed for peers will be
2. For standard "Super-Seed", supposing pipelining to keep the pipe
full, you only send a new piece to peer A when peer B confirms transfer
A->B for the previous one. So, the seeder only sends as fast as upload
speed of peers. In this case, 128Kbps for each one. The peer crossfeed,
so each get 256Kbps, in total. 100% BW usage.
3. My approach sends the new piece to peer that receive less lately,
from other peers. In this case, both are equal so, they get the same
share, or 256Kbps from seeder and 128 from the other peer. 384Kbps in
total. We are in case 1.
In this calculation, with two peers, superseed is the worst algorithm,
in download speed terms.
For a swarm with a 512/128Kbps peer and the unlimited peer.
1. Standard: seeder sends 256 to each. The peer A sends 128 to peer B,
but peer B send 256 to fully use download speed of A. So A gets 512Kps,
and peer B gets 384. The slower peer gets the full file earlier!. If the
seeder stops feeding then (100% BW usage), the peer B will get only
128Kbps, when his file is 75%. So the median speed for it is 320Kbps. If
the seeder keeps feeding, peer B will get 640Kbps for the last 25% of
the file. The median speed for B will be 448Kbps. BW: 125%.
2. Super-Seed: A gets 128Kbps from seed, B gets 384Kbps from seed, since
it sends 384 to A before saturating its line. So in total both gets
512Kbps. BW: 100%.
3. My Approach: In the stationary state (the process is iterative), peer
A gets 128Kbps from the seeder and B gets 384 from seeder. Both download
512Kbps in total. BW: 100%
The situation can be complicated, for example, if the peers don't start
the download at the same time. But doing some calculations, the
conclusion seems to be:
1. Super-seed tries to reach a BW usage of 100%. Each peer gets a
different piece to trade. If the trading is going slow, the seeder slows
tranfer in order to avoit piece duplication. So the swarm must be big in
order to use the full seeder capacity.
2. My approach, instead, tries to optimize download speed. If the
(summed) upload capacity of peers is below seeder speed, the seeder will
duplicate blocks, unless it stops feeding. Each peer will get pieces
from seeder proportionally to its upload capacity.
My approach is fairly simple, but has a serious flaw: if a peer is being
choked because it's sharing poorly, my algorithm will give it
priority!!!. That could disturb the tit-for-tat BitTorrent algorithm. In
my environment, nevertheless, I'm not sure if the choke would get in
action, since the swarm size is very small. The algoritm, in fact, is
acting appropiatelly for its purpuse: optimice the download speed of the
swarm, in this case feeding the slower (and more "leech") node };-).
Food for the mind.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
_/_/ _/_/ _/_/_/_/_/
PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> To unsubscribe from this group, send an email to:
BitTorrent-unsubscribe at yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
More information about the BitTorrent