uTorrent questions

ManBearPig

Diamond Member
Sep 5, 2000
9,173
6
81
Should i enable scraping?
Should i pre allocate disk space? (probably not right)
Should i enable DHT?
Should i enable DHT for new torrents?
Should i enable uPnP port mapping?

Sorry...i dont know what any of these are.
 

BW86

Lifer
Jul 20, 2004
13,114
30
91
This is what I have checked.

Enable scraping
Enable DHT
Enable DHT for new torrents

uncheck Pre-allocate all files
 

duragezic

Lifer
Oct 11, 1999
11,234
4
81
You'll definitely want DHT (tho it seems support is dependent on your .torrent) and uPnP (if supported, likely is if you have modern hardware).


Well here, this took like one minute. uTorrent FAQ:

"How do I make µTorrent allocate all the files when I start the torrent?

Turn on "Pre-allocate disk space" in Torrents. Turning on this option will prevent compact storage and sparse files from working, however. Pre-allocate no longer allocates all files when skipping files, only the ones you choose.

There is little use to pre-allocate except for making sure you have enough space when starting a torrent. It does NOT reduce fragmentation as compared to not using it, since µTorrent ALWAYS allocates the full file when writing to prevent fragmentation, regardless of if pre-allocate is on (unless you use compact storage or sparse files). "

I don't know what scraping is but its enabled by default. Check the rest of the uTorrent FAQ for all your answers

 

itachi

Senior member
Aug 17, 2004
390
0
0
and here're some things wrong with the utorrent faq.
Originally posted by: duragezic
Turn on "Pre-allocate disk space" in Torrents. Turning on this option will prevent compact storage and sparse files from working, however. Pre-allocate no longer allocates all files when skipping files, only the ones you choose.
but it does allow you to use memory mapped files. not pre-allocating makes it extremely difficult to map a file to virtual memory (if you wanted to increase the size you'd have to unmap the whole file, increase it's size, and remap it).
There is little use to pre-allocate except for making sure you have enough space when starting a torrent. It does NOT reduce fragmentation as compared to not using it, since µTorrent ALWAYS allocates the full file when writing to prevent fragmentation, regardless of if pre-allocate is on (unless you use compact storage or sparse files). "
it doesn't matter whether you allocate the full file or not.. if windows always allocated files in contiguous space, there'd be no such thing as fragmentation. when you're dealing with files, the kernel abstracts where you're writing on the disk. the only way to ensure that the file is fully allocated is by writing to every part of it. and the only way to ensure that it's not fragmented is by doing a sector search for a sequence of clusters long enough to fit your file.. and i highly doubt utorrent does that.
I don't know what scraping is but its enabled by default. Check the rest of the uTorrent FAQ for all your answers
scraping is a way for clients to check the status of a torrent.. it operates using it's own messaging scheme.
 

Velk

Senior member
Jul 29, 2004
734
0
0
Originally posted by: itachi
the only way to ensure that the file is fully allocated is by writing to every part of it.

I'm pretty sure that is not correct.
 

itachi

Senior member
Aug 17, 2004
390
0
0
Originally posted by: Velk
Originally posted by: itachi
the only way to ensure that the file is fully allocated is by writing to every part of it.

I'm pretty sure that is not correct.
why do you think it takes so long to allocate a 5 gb file? whether the application is writing to the disk itself, or it's asking the os to.. somebody is writing to the disk.
look at the ansi c stds.. when you create a file, you can't specify size.. it's not until you start writing to it that the file size starts increasing.
 

Velk

Senior member
Jul 29, 2004
734
0
0
Originally posted by: itachi
Originally posted by: Velk
Originally posted by: itachi
the only way to ensure that the file is fully allocated is by writing to every part of it.

I'm pretty sure that is not correct.
why do you think it takes so long to allocate a 5 gb file? whether the application is writing to the disk itself, or it's asking the os to.. somebody is writing to the disk.
look at the ansi c stds.. when you create a file, you can't specify size.. it's not until you start writing to it that the file size starts increasing.

As I had never actually tested my understanding of how that works I went for an experiment -
If you allocate space for a file by using the kernel32.dll calls CreateFile, SetFilePointer and SetEndOfFile you can create a 6GB file in less than a second. Analysing the disk afterwards shows that file as being a single contiguous file, i.e. all the clusters that will be used by that file have already been allocated to it, even though no data has been written to them.

This is on NTFS, perhaps FAT works differently, although that would be counterintuitive.
 
Sep 29, 2004
18,656
67
91
I used all default settings.

The only thing I change regularly is the upload/download caps. Setting the numbers to about 30% to 50% of my maximum transfer rates lets me use the internet as though uTorrent isn't even on. And prevents complaints from my wife who doesn't even realize I am using uTorrent ;)

Then when I'm done, I raise the limits so the bandwidth is getting used to it's maximum extent.
 

itachi

Senior member
Aug 17, 2004
390
0
0
Originally posted by: Velk
As I had never actually tested my understanding of how that works I went for an experiment -
If you allocate space for a file by using the kernel32.dll calls CreateFile, SetFilePointer and SetEndOfFile you can create a 6GB file in less than a second. Analysing the disk afterwards shows that file as being a single contiguous file, i.e. all the clusters that will be used by that file have already been allocated to it, even though no data has been written to them.

This is on NTFS, perhaps FAT works differently, although that would be counterintuitive.
write a byte at the end, and see what happens. while it may have taken you less than a second to specify where the EOF is, it won't be so quick to write at the byte before it. you could still write to the end by using the SetFileValidData function, but u need privilege to use it - it won't work if the user isn't an administrator or has the right tokens.

and it won't always create a contiguous file. if that were true, defragmenting wouldn't be considered so important by many. do a search on ntfs, it's allocation algorithm, and fragmentation.. what u'll find is that ntfs will fragment files, even if you have more than enough space.