Jump to content

My Flank Downloading Experience


Kazuaki Shimazaki

Recommended Posts

Tonight, I began a download on a torrent with about a 95:5 BC/Azureus connection. After an HOUR of them ignoring me, all of a sudden, they (about 100 connected out of 1000 detected peers) suddenly decided to be ridiculously generous, and my download pipe was swamped to its flank speed - which turned out to be about 620KB/s for me, which sounds about right for a 6Mbps down connection. Since this does not happen often (a 600KB/s class is a first for me, in fat), I think I'd mention some things that I do not see most of the time at average speeds, in hopes it'd be useful to somebody.

I'm using uTorrent BETA 1.4.1 build 413.

1) Drag: I just noticed that uTorrent IS "human". When it runs at this speed, the program actually DOES bloat, fluctuating to taking up over 20MB real RAM. It also produces a significant drag on the system - it is about as much drag as Azureus when it is idling, which is significant but survivable. It is more drag than BC when idling. It was enough drag that I gave up my web-surfing and decide to take advantage of this valuable opportunity.

This means I'd have to consider setting a cap at say 200KB if I start doing something important (like a game), just so this drag doesn't get to me...

2) Disk Queue: The Auto Disk Queue management kind of falls flat at DL speeds of over 200-300KB/s. The problem is how to set it manually. I decided to use this rare occasion to do some experiments.

diskio.write_queue_size defaults to -1, which is automatic cache management. µTorrent will automatically adjust the cache size based on your download speed (max measure download speed * 7). If you would like to adjust this value manually, set it 2 to 4 times your maximum download speed in kilobytes, but try to avoid going below 1000, or above 32768 in most situations.

This advice plain doesn't work. To avoid an immediate disk overload alert, I had to set it to about 20 megabytes. Even then, a Overload came within a few minutes. I tried expanding it to 25MB and it still had occasional Overloads. Eventually I decided to leave it at 32768.

3) Upload: At flank speed, I notice my upload was crimped to somewhere between 10-50% of its normal value. But that's OK, I'd be seeding for a long while for that torrent, because that torrent has a availability of only 0.770, and a thousand peers are waiting with me for the day when somebody would be nice enough to do a seed...

If anybody got more of this kind of observations, maybe you can contribute too. Thank you.

Link to comment
Share on other sites

1) Drag: I just noticed that uTorrent IS "human". When it runs at this speed, the program actually DOES bloat, fluctuating to taking up over 20MB real RAM. It also produces a significant drag on the system - it is about as much drag as Azureus when it is idling, which is significant but survivable. It is more drag than BC when idling.

I think you're misinterpreting the meaning of "bloat", and maybe you should be looking at the CPU usage rather than the RAM usage. Typically RAM doesn't have much of an effect on noticeable "drag" on your PC, it's more about CPU and HDD usage. Also, you said it's "about as much drag as Azureus when idling" - do you mean when not even downloading..?!

Link to comment
Share on other sites

I think you're misinterpreting the meaning of "bloat",

Yes, yes, I know uTorrent is a very efficient program, but it did expand, you know.

and maybe you should be looking at the CPU usage rather than the RAM usage.

I looked at both in Task Manager. There was obviously some CPU load, but never over 10% - the HDD load was obviously significant, but 600KB/s isn't that much as far as HDD goes - its the speed of a 4x CD-ROM.

Typically RAM doesn't have much of an effect on noticeable "drag" on your PC, it's more about CPU and HDD usage.

My experiences do not match yours. I came to the sad conclusion long ago that for some reason, nothing but your subjective perception matters when it comes to perceived drag. Azureus' official consumptions when running is broadly comparable to say Acrobat Reader and it is not downloading at any great speed (say 50-80KB/s). Meanwhile, my computer basically freezes.

Also, you said it's "about as much drag as Azureus when idling" - do you mean when not even downloading..?!

Yes. In my experience, Azureus can be a most measurable drag on my system even if everything is STOPPED. If Azureus is actually running, even at a upload rate of 5KB/s (with a correspondingly poor DL rate), the drag massively escalates. At normal UL (around 50-55KB/s for me) and thus normal DL flow, I might as well stop working because it is a futile effort.

Link to comment
Share on other sites

"only" 600 KB/s, that's being written randomly across the entire disk.

Sparse files increase fragmentation significantly. Even light fragmentation can seriously hurt performance. Try it without sparse files. And make sure the disk is relatively unfragmented.

UDMA6 is short for Ultra DMA 6, you can check that in the Device Manager. Check your IDE controller's properties to see.

Link to comment
Share on other sites

Sparse files increase fragmentation significantly. Even light fragmentation can seriously hurt performance. Try it without sparse files. And make sure the disk is relatively unfragmented.

I'm keeping it clean with Diskeeper on Smart Scheduling. As for sparse files, how would I know BEFORE I even start a torrent (seeing I can't change it halfway) whether I'd be getting one of these 600KB/s (or even a 200KB/s+) days or not?

UDMA6 is short for Ultra DMA 6, you can check that in the Device Manager. Check your IDE controller's properties to see.

I see something, but I only have UDMA5.

Link to comment
Share on other sites

Also, you said it's "about as much drag as Azureus when idling" - do you mean when not even downloading..?!

Yes. In my experience, Azureus can be a most measurable drag on my system even if everything is STOPPED.

Oh, I see. You're saying µT while active has the same effect as Az while idle. Sorry, I'd thought you were comparing them doing the same activity.

Link to comment
Share on other sites

Actually, I think he was saying µT under a reasonably heavy load has the same effect on the rest of the computer as Az with everything stopped.

The problem with 600 KB/sec download speeds causing the heavy load is I/O requests per second, not raw KB/sec speeds. Random access writing across the hard drive is really slow compared to brute force end-to-end reads. Couple that too with whatever other files are being accessed on the hard drive or that uploading means the hard drive is having to read random pieces of the torrent to upload to people as well... and even a UDMA5 hard drive might run into disk overloaded conditions from time to time if there is no read+write cache to buffer against its slow access.

Downloading torrents onto an otherwise "idle" hard drive is capable of going a lot faster than to the primary C: drive which is accessing Win OS files often too.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...