[BitTorrent] Re: Poor Performance with Version 3.1?

Keith Smith keithsmith_32 at yahoo.com
Wed Jul 28 14:14:07 EDT 2004

i have one question, if an isp is using a packet shaper will it stop 
the peers and seeds from connecting to me? cause all i do is sit 
there and just constantly try to connect to peers and its usually 
during off hours for cable company. but during thre day it sometimes 
works. i know they have a packet shaper but how can it effect 
bittorrents? thnx.

--- In BitTorrent at yahoogroups.com, Bram Cohen <bram at b...> wrote:
> Jeremy Gore wrote:
> > I don't know whether there have been any such significant 
changes to  
> > the source (I kind of doubt it).  If you could switch to an 
> > release (ask bram for one I guess) and test it out that would be 
> > place to start.
> People have been commenting about relative performance between 3.1 
> 3.0.2 a lot. This is a very complicated issue, so I'll explain in
> detail. At the bottom I'll explain what I'm going to do about the 
> problems, they're all quite fixable.
> There are four things which 3.1 has over 3.0.2 which are likely to 
> performance.
> (1) Better rate estimation
> The old method of calculating transfer rates had some nasty 
artifacts and
> tended to inflate transfer rates. The new algorithm is much 
better, and
> also the default slice size was reduced from 32k to 16k, which 
doubled the
> effective sampling rate. These changes will produce subtly better 
> performance, but somewhat lower (although much more accurate!) 
> transfer rates.
> (2) rarest first
> Previously, clients downloaded pieces in random order. This caused 
> problems. For one thing, in the case of a deployment which was
> bottlenecking on the upload rate of the origin, the download would 
go much
> slower than necessary because the origin would frequently send out 
> same piece several times. For another, the likelihood of some piece
> getting lost was rather high, so the origin going down frequently 
made a
> file unavailable.
> Rarest first downloads pieces starting at the least common. These 
are the
> pieces which both are most likely to be unavailable later and are 
> likely to be useful for uploading to peers.
> After 3.1 was released, there was a sudden and dramatic 
improvement in the
> robustness and longevity of BitTorrent deployments. I think this 
is mostly
> due to rarest first (and (4) below, which rarest first enabled).
> Unfortunately rarest first exacerbates a problem which was 
> before. When a downloader first connects, especially at the very 
start of
> a very popular file, they have nothing to upload, so they sit 
there choked
> by everyone until they manage to cobble together a whole piece 
from random
> optimistic unchokes and then can start uploading, at which tit-for-
> works its magic and they start getting a decent transfer rate.
> Rarest first is arguably the worst possible strategy at the very
> beginning, because it maximizes the amount of time it will take to
> download that one piece. This is somewhat mitigated by (4) below, 
> increases the chances that a whole piece will be transferred 
during a
> single optimistic unchoke period, but it's still a serious problem,
> especially at the beginning of a very popular download.
> Of course, random sometimes happens to pick the rarest first, so 
the old
> behavior wasn't especially good at the beginning either.
> (3) anti-snubbing
> Watching transfers happen with diagnostics turned on, I noticed 
> occasionally all peers in 69 happen to choke at the same time, 
> in a very slow download rate until the optimistic unchoke finds 
> ones. To mitigate this, I added anti-snubbing, which checks to see 
if one
> of the peers it would like to reciprocate with hasn't sent 
anything in
> over a minute, and in that case dedicate that slot to an optimistic
> unchoke.
> This technique doesn't kick in unless poor download rates are being
> experienced, and in those cases it does at least twice as much 
> unchoking as it does normally. The result is much more consistent 
> rates for everyone.
> Due to the evening out effect this produces, some people may 
> reduced download rates because the idiosynchracies of their 
> happened to make them get the better of the somewhat more 
arbitrary load
> distribution which was happening before. It's hard to say when 
this might
> happen though.
> A much more serious problem this produces has to do with how I 
> it. Previously, once a downloader finished they preferred peers 
which they
> uploaded to the fastest. Now once a peer is finished it simply 
> it's snubbed by everyone, and unchokes four different peers every
> period. This results in greatly reduced upload rate because 
> have to slow start once every 30 seconds, and also because peers 
on very
> fast connections may happen to unchoke only peers on much slower
> connections in any given period, bottlenecking on the download
> side. Setting max_uploads to 20 helps with this problem but doesn't
> completely make it go away.
> I think this is the largest performance regression to happen in 
the latest
> release, since it drastically reduces upload capacity utilization.
> (4) reduced default piece size
> The default piece size was reduced in the latest release from a 
> to a quarter megabyte. This won't make any difference 
for .torrents which
> were generated with the old release, but for ones generated with 
the new
> one it will result in a much shorter slow period at the very 
beginning and
> subtly better performance at other times.
> This increases on the wire overhead somewhat, but it's still well 
> one percent. The main danger is that the risk of a piece getting 
lost is
> much greater if all the clients are 3.0.2, but with rarest first 
> implemented that isn't a concern.
> Those are the new problems, here are the planned solutions -
> (1) Rarest first will be kept, but when no pieces have been 
downloaded yet
> instead of picking pieces which only one peer has, it will try to 
> pieces which about half of all of its peers have, these should 
both be
> reasonably quick to download and useful for uploading, since a 
fair number
> of peers have them and a fair number of peers want them.
> (2) Upload behavior after completion will be changed to favor 
> upload rates again.
> (3) A new feature will be added to complete uploaders that they 
give each
> new downloader which connects at least a full piece before choking 
> This will help speed up the initial slow phase a lot. This is 
> gameable, but it's always been the case that you can get more out 
of a
> complete downloader by making lots of connections to it, and the 
way to
> deal with that is to make complete downloaders view peers with the 
same IP
> address as effectively the same connection for unchoking purposes.
> That should clean up all the new artifacts nicely. The next 
release will
> in all ways be clearly better than both 3.0.2 and 3.1.
> -Bram

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70

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 mailing list