µTorrent 1.5 released

[Firon]

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.

[rseiler]

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?

[Firon]

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.

[Kazuaki Shimazaki]

Not everyone has your massively fast hard drive, Firon. I'm sure I told you what happens to my computer at that speed.

[rseiler]

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.

[Firon]

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.

[skynetman]

Firon, new cache system does not seem to clear cached data when u delete a completed torrent. Is that ok?

What does it mean "hashing" line in read stats? it's # is increasing

[Firon]

Yeah, it'll get rid of that data soon enough.

Hashing means data read to hash check the piece.

[Game90]

for me, utorrent writes at about 3 times per second when downloading at 300k/s.

using 438 with default cache.

[Firon]

Set the interval to 1s and post a screenshot of the graph?

[uTorUser]

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)

[Icarus]

Same here, µTorrent writes about 1 to 5 times per second

[Snapphane]

I have to ask, how do you get that graph? I would like to have a check myself, but I can't find that in settings? Thanks!

[dAbReAkA]

Snapphape, build 458..

[Snapphane]

Ahh, better get my hands on that one then =)

I hope it's okay, not being official beta and all that...

[skynetman]

Firon, when u use F2 to rename a torrent ad then u press esc because u want to keep the original name (in case u forgot what it was or pasted the wrong name), utorrent minimizes to tray too. It should only cancel the renaming.

[Ultima]

I reported that to ludde already. He said he'll take that into consideration.

Edit: And he indeed did fix it.

[Nefarious]

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?

[mcramer]

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.

[Nefarious]

yeah just noticed taht too, it dont write until it's stopped even if there is no pieces left to get, thk god for "dont count slow dl/ul" thou

[wormhole]

is this working as it should..?

[Technarch]

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.

[Ultima]

It is enabled by default now, and cannot be disabled.

[chupakabra]

Is "number of upload slots" setting working properly in build 459? I noticed that actual number of peers with "U" flag are always less by one than number of upload slots set in options.

[apicola]

does web ui works? i see that it appers in the latest beta