New BT 3.3!

VLSmooth · Post by **VLSmooth** » Fri Sep 26, 2003 6:09 am

Home Page (Download)

Interesting protocol read (if you haven't already read it).

Even more interesting academic-styled paper (pdf).

Lastly, I'm really surprised this hasn't been slashdotted yet...

VLSmooth · Post by **VLSmooth** » Fri Sep 26, 2003 6:12 am

On second thought, the first improvement sounds like a disadvantage...

New in 3.3:

Files now only get allocated as they're downloaded and don't fragment the hard drive
Large torrents no longer hose the CPU
Better network utilization and more consistent download rates
Poorly seeded torrents get out faster
Several important bug fixes

I believe preallocating a as-much-as-possible contiguous block as-early-as-possible mitigates fragmentation. It's actually a "feature" I really liked about the old BitTorrent. Now downloading via XDCC and BT at the same time will likely induce MASSIVE fragmentation since they both write on-the-fly.

Actually, even if a person is only grabbing a BT, it's almost guaranteed to generate more internal fragmentation than the old method since BT grabs random parts of the file. Unless he's spacing the downloads appropriately and preventing other applications from writing to the calculated positions... oh wait, that's preallocation -_- </sarcasm>

Hmm, perhaps this should be moved to the articles forum based on content?

VLSmooth · Post by **VLSmooth** » Fri Sep 26, 2003 6:21 am

Interesting. Bram still doesn't implement capping via the GUI like the experimental one I used did.

I'm guessing that was a conscious decision since he describes the command-line upload limiting option. Perhaps he's afraid too many people will set it to something really low (like zero).

quantus · Post by **quantus** » Fri Sep 26, 2003 8:11 pm

VLSmooth wrote:I'm guessing that was a conscious decision since he describes the command-line upload limiting option. Perhaps he's afraid too many people will set it to something really low (like zero).

I like 0 upload rates...

VLSmooth · Post by **VLSmooth** » Fri Sep 26, 2003 8:23 pm

But then distribution as a whole suffers -_-. He's likely trying to minimize the possibility of "OMG BT SUX TEH C0C|< WIHT CRAPPIE DL SPEEDZ" due to people being unreasonable.

quantus · Post by **quantus** » Fri Sep 26, 2003 10:05 pm

Setting a dl speed of 0 is completely reasonable, especially for people who have no upload or very limited upload like me

Post by **Jonathan** » Sat Sep 27, 2003 12:11 am

The BT client prioritizes incoming requests for data based on how much data the client making the request is providing. If you have a upload of 0, your download will suffer.

Clearly, you won't be squeezed out altogether, because at the beginning of every download you have nothing to offer. I have been doing a fair amount of BT downloads over the summer. Experience shows that the download speed ramps up with time on popular files and takes a slight dive at the end as you close out active requests and wait for the outliers to finish. I believe that with a upload of 0 you'd be hard-pressed to break 10 kB/s and find it nearly impossible to break 100 kB/s.

However, you can do just fine with rate-limiting to non-zero values. I only get 19 kB/s or so effective upload, but I can exceed that in download through BT by an order of magnitude. By rate-limiting to 10 kB/s or so, you ought to be able to sustain decent transfers without having to maintain parity.

I would submit that you are in a heavily minority situation and that it is far better to optimize the BT client for the common case.

Incidently, I've been using Shareaza for BT downloads the past couple weeks. The running average graph is mesmerizing.

VLSmooth · Post by **VLSmooth** » Sun Sep 28, 2003 7:16 am

I agree rate-limiting clients, such as the experimental one that I still use are good. It allows me to comfortably vnc and BT at the same time (bonus!). However, it requires use of the old experimental client which supposedly lacks nifty network enhancements implemented in 3.3. Guess I'll have to wait for an experimental 3.3 before I upgrade.

Note, just to make it clear, my previous post simply stated the fact the new 3.3 does not have rate-limiting via the GUI (has always been a command-line option) and attempted to put reasoning behind that (most likely conscious) decision.