[bittorrent] Open letter to the BBC
ehem at m5p.com
Sat Jun 25 16:42:42 EDT 2005
>From: Olaf van der Spek <olafvdspek at gmail.com>
> On 6/25/05, Elliott Mitchell <ehem at m5p.com> wrote:
> > >From: Joseph Ashwood <ashwood at msn.com>
> > > the overhead because the protocol messages are smaller. As for a running
> > > system performing a variety of uploads on a variety of torrents (a recipe
> > > for high protocol overhead), I am currently connected to 135 peers
> > Why are you using such a ludicrusly large number of peers?
> 135 / a variety of torrents isn't that much.
Oh, this is total number of peers while downloading multiple torrents?
Peers per torrent is a much more useful statistic. I'd thought you ment
that was 135 peers on one torrent (which is ludicrusly large).
> > 50 peers is the conventional number to cite for statistics because it
> > presents a worst case scenario. I'm in favor of BT clients burying the
> > option to change number of peers deep in some menu where this can be
> > mentioned. By contrast queue depth is an important tuning parameter that
> > should be easily available.
> I'm not sure, but wasn't that option introduced/decreased to deal with
> bad TCP/IP stacks/firewalls/routers?
No idea, though I fail to see how it could help such a case.
What it can do is completely decouple the BT protocol from network
latency and make it purely bandwidth bound. For downloads this is a Good
Thing(tm). Network links up to about 2mbps the baseline clients's default
of 5 requests is usable, with higher speed links I doubt that is
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | EHeM at gremlin.m5p.com PGP 8881EF59 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
\___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/
More information about the BitTorrent