Jump to content

Disk overload when DL torrents at 17 MB/s


Slangaren

Recommended Posts

lelik11a..

Very interesting.

My friewnd with the "raid0" experienced exactly the same thing with the "stop and resume" yesterday.. He tried it on two mashines with the same result as you.

He has one with a two HDD and Raid0 and one with a single HDD.. On my mashine I unfortunately couldn't get it to run smooth after "resume"..

Sounds like a bug..

Link to comment
Share on other sites

  • Replies 62
  • Created
  • Last Reply

Hellu "lelik11a",

It seems (post #23) like you have discovered the same peculiar disk cache behaviour as I have: To achieve a write-to-disk throughput anywhere near a regular HD's normal capacity, one seems to need to "initialise" the allocated cache memory first, before uTorrent starts to work properly.

To get a good throughput I do like this:

- Start the torrent and let it fill up the cache a little bit. (Exactly how much doesn't seem to matter?)

- Stop the torrent and let the cache empty COMPLETELY to 0%

- Start the torrent again and it'll download with max speed, whatever is your system's bottleneck (internet connection, CPU capacity, …)

Doing the above start-stop-empty-restart thing, I achieve a sustained throughput that's only limited by my internet connection (100/100 Mbit/s), ie about 11-12 Mbytes/s.

The "initialisation" of the cache memory seems to be effective even to other torrents if I do it first for one torrent and then, when things are up to speed, also start other torrents to work in parallel. That might explain the apparent "difference" between trackers that "lelik11a" mentions in post #27

I will try to set up a test between two computers in my internal Gbit LAN to see where it maxes out. A regular HD has a continuous read/write capacity of about 25-40 Mbytes/s (200-320 Mbit/s) so I hope to see speeds approaching those HD limits. (Ah, yes: Since I'm the RAID-0 guy "Slangaren" talks about in post #21, we might see even higher speeds.. ;o)

Link to comment
Share on other sites

Yes,

But here the bottelneck is the interface/way between the cache and the disk.. IDE/SATA.. To fill up the cache via ethernet is quick.. I will try tonight to use a different disk in a shared folder on a different (newer) computer on the Gbit-LAN. To see if the start/stop technique works for me as well.

Link to comment
Share on other sites

Thanks Lord Alderaan for reporting the bug.

No difference when using a shared drive on another computer..

But there is a difference when using different torrents / trackers as mentioned above by lelik11a.. Can it be different blocksizes in different torrents?

Link to comment
Share on other sites

The best speed I could get was 10.3 (constant 9MB on 100 mbit NIC) was with WRITE CACHE DISABLED. You must have enough virtual memory (auto settings will do). uTorrent fills the RAM, then the page file with maximum write speed. I got NO Disk Overload. The best configuration probably is virtual memory on different physical drive or lots of RAM.

The transfer rate between my harddrives is 35 MB/sec so it would not get bottlenecked.

I firstly defragmented the drives (O&O defrag->Complete/Access) so I could get the most juice out from my drive.

Link to comment
Share on other sites

Re post #33

I hardly know how to begin to respond you, I can only say that you don't seem to understand what a cache is good for.

And why on earth would it be a good idea to fill up the computer's virtual memory (VM) with download data? That would mean that the downloaded data first needs to be written into the VM/swap-file on the HD, then a moment later be read from the VM/HD just to be re-written again to the HD, but this time into the proper files defined by the torrent.

The reason it is a good idea to let the torrent program manage a cache of its own rather than to rely on the OS's is of course that the torrent application has more knowledge about what's going on and can make better decisions as to when to flush which parts of the cache down on disk.

The reason that you don't see the "Disk overload" warning is obviously because you have shut of uTorrent's disk cache. The warning only appears when the cache is active and has become filled to 100%.

Link to comment
Share on other sites

Well, I said I wanted greater download speed. With cache enabled, I get 5-6 MB/sec average, without the cache I get 10 MB/sec. So, it's obvious that the freaking hard drive can write at this speed, but the cache mechanism in uTorrent doesen't handle fast enough the data.

I do understand what a cache is good for but I don't understand why it is so slow, knowing that it's primary goal is to speed the writings to the disk by moving larger amounts of data in a burst.

I thought this could help the others having the same problem.

You should know (if you ever downloaded with high speeds) that when "Disk overload" shows up, uT stops downloading until the cache emties a little so that's where slow speeds.

I don't really like the idea of having the VM full with gigs of data but I do want greater speeds.

Link to comment
Share on other sites

I'm happy to hear about your achievements with download speeds, but as you can see in post #28 the issue here isn't that uTorrent should be incapable of high DL speeds.

By doning the little workaround as described in post #28, you will achieve max/highest DL speed possible while still reaping the benefits of a cache ( i.e. reducing the stress on the HD which otherwise ultimately will lessen the HD's lifetime). I have reached continuous DL speeds of ~20 MBytes/sec and peaks even higher than so.

The issue here is a suspected (and now reported) bug in uTorrent: How it somehow fails to properly initialise, handle and flush its cache and/or if this has to do with which tracker the torrent runs under, and that this bug apparently was first noticed by people like us who has really fast internet connections (100+ Mbps).

Bug report page:

http://forum.utorrent.com/viewtopic.php?pid=242171

Link to comment
Share on other sites

I have seen the "start/stop workaround" work, but what is the reason for uT NOT to start writing to disk as soon as bytes are downloaded to memory?

Is uT trying to write the "pieces/blocks" to disk in a smart/consecutive manner and theirfore waiting to get as many as possible before starting to write?

Link to comment
Share on other sites

Ultima:

Would you know why uT is not writing to disk at full speed?

If I have 700 MB of Disk Cache (memory) assigned. uT doesn't start to write until the cache is completely filled.. And then it writes at 3 MB/s to a disk that can write at 30 MB/s when copying files..

Link to comment
Share on other sites

Strange,

This is what I get with the same settings (except 700 MB of cache).

writingtodisk3zh4.th.jpg

Yours looks exactly how you would expect is to work..

Are you using Raid? Do you get the same performance with different torrents? Use strt/stop?

As I said many times, when copying I write at 30 MB/s.

Link to comment
Share on other sites

  • 6 months later...

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...