Jump to content

µTorrent 1.5 released


Recommended Posts

You can't estimate it based off the # of reads, since read-aheads increase the amount of data read significantly, and if the cache is too small, you're reading a lot of data unnecessarily, because a lot of that data gets thrown out before it's used. Get what I mean? And in the end, it has to read a large chunk AGAIN, whenever it reaches that amount.

And in all honesty, at slow speeds, it's not gonna make jack difference on the life of your drive. What really does is spinup and spindown, so never turn off your PC. :P

Link to comment
Share on other sites

  • Replies 427
  • Created
  • Last Reply

Top Posters In This Topic

After reading the last few messages, the caching situation is back to being clear as mud for me.

Firon has always pop-poo'd caching. He's not a fan. His recommendation, unless you have a "multi-megaBYTE/s" connection (something almost no one here is going to have) is to not even bother configuring the cache, leave it at defaults.

Only problem is at defaults, uTorrent is still a busy little beaver when it comes to disk activity on a multi-megaBIT connection. Whether that matters or not is beside the point. I believe it does. Others don't.

So what can be done about this activity? The mind, naturally, turns to the DISK CACHE.

But we're told, somewhat dismissively, to keep our uneducated mitts off it, lest we make things worse.

On systems which sometimes have multi-gigaBYTES of memory, does this make sense? Surely it can be put to use. There's no way uTorrent needs to access the disk constantly on a typical home broadband connection. I'll never believe it has to be that way.

I remember about 15 years ago running a clever staged-writes disk cache called HyperCache. Before implementing the cache, the disk was tsk-tsk-tsk downloading at 14.4 with Zmodem; after implementing the cache, there were only bursts of activity when necessary (or when you configured Hypercache for, I don't recall). I realize that was a one-way transfer at tremendously slower speeds, but relatively speaking it's analogous. I mention it to illustrate that disk caches have been making a difference for a long time.

Until now, anyway.

Shouldn't we pool our meager brains to see if indeed there's something better than defaults?

Link to comment
Share on other sites

Funny, it's barely active at all at 520KiB/s. Doesn't even make one write per second. Definitely busy as a beaver.

Oh, and there's a lot of 50mbit+ users out there. A lot.

A "lot"? Relative to the tens of millions of normal broadband users out there? Really? No way. I wouldn't think even more than 1%. But let's say there are millions upon billions of them. They need better caching even MORE.

And on how much activity uTorrent is not causing, try looking at Filemon sometime, if the red light every second isn't enough for you.

My point above, which was of course missed, is that we have tons of memory sitting around unused. uTorrent does not need to be hitting the disk like it does.

Link to comment
Share on other sites

rseiler: like I said, at 520KB/s, it makes LESS THAN ONE WRITE PER SECOND. As in, about one write every 3-10 seconds (sometimes it goes even 30 seconds without a single write!)

How is that a lot of activity?


These are with the default cache settings in the new beta, by the way.

Link to comment
Share on other sites

Strange. uTorrent handles the writing better then the reading.. When uploading at 4megabytes/s there is ~50 reads/sec and my harddrive goes nuts (the default cache is at ~30mb)

When writing at speeds ~3-4mb/s I can still use my computer as normal.

(100/100 connection)

Link to comment
Share on other sites

ahhh, i've been seeing some piece that dont get written when they get completed

they just stay there and even after the 2minute timing to write it still stays there, also i see those pieces get "over completed" or somethen, i mean piece is 128blocks long, and then it says it has completed 134, on another i saw it had completed 140 or so, and the pieces are complete anyway since if i stop the torrent then it gets written (my english stinks)


piece 503: completed 135/128

piece 520: completed 134/128

and they have been like that for over 10minutes after it was finished, is it supposed to be like that? or did i move a setting or somethen?

Link to comment
Share on other sites

I saw the same thing yesterday with 458. The torrent stopped downloading with 99.9% completed and most of the pieces showing 140+ out of 128 downloaded. I stopped the torrent and it jumped straight to 100%, it had sat in this unfinished state for half an hour.

Link to comment
Share on other sites

Does anyone know why the option 'prioritize rare piece' was taken out of the advanced settings in the 1.5.1 betas? I was using that option and I felt it was working because on slower torrents especially it helped me be #1 in % complete.

Link to comment
Share on other sites


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

This topic is now closed to further replies.

  • Create New...