[BitTorrent] Re: Poor Performance with Version 3.1?
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
--- 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
> > 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
> (1) Better rate estimation
> The old method of calculating transfer rates had some nasty
> tended to inflate transfer rates. The new algorithm is much
> also the default slice size was reduced from 32k to 16k, which
> 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
> 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
> file unavailable.
> Rarest first downloads pieces starting at the least common. These
> 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
> 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
> a very popular file, they have nothing to upload, so they sit
> by everyone until they manage to cobble together a whole piece
> 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
> 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
> 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
> of the peers it would like to reciprocate with hasn't sent
> over a minute, and in that case dedicate that slot to an optimistic
> 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
> distribution which was happening before. It's hard to say when
> happen though.
> A much more serious problem this produces has to do with how I
> it. Previously, once a downloader finished they preferred peers
> 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
> 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
> 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
> one it will result in a much shorter slow period at the very
> 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
> 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
> 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
> reasonably quick to download and useful for uploading, since a
> 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
> 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
> complete downloader by making lots of connections to it, and the
> deal with that is to make complete downloaders view peers with the
> address as effectively the same connection for unchoking purposes.
> That should clean up all the new artifacts nicely. The next
> in all ways be clearly better than both 3.0.2 and 3.1.
------------------------ 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