Utorrent is noisy !

[Klaus_1250]

Some Windows tweaking programs allow you to set better cachelimits. As far as I know, the default Windows Settings are way too low. Also, I think a built-in cache could actually be very usefull. What if someone wants to seed a large file (700MB) on a very fast connection (10 - 100Mbps) but still wants to be able to use his computer during seeding? Not many people have 1.5 or 2GB or RAM, but if they have, they could load the entire file in cache and seed it without hearing or noticing it.

IMHO the best thing about uTorrent is that you can run it whole day without noticing it. But this changes it people haven't tweaked their Windows Cache Settings and are uploading at high speeds. And why stress out the harddisk if you happen to have the RAM to cache the whole file? µTorrent should stay light and small, but if people want to use a cache of a few 100 MB to reduce disk-activity, why not? As long as you make it an advanced setting.

@kokoko3k: Out of interest, if your harddisk has a temperature sensor, could you perhaps post some screenshots of the temp while seeding with various applications? Kind of wondering how it plays out for high speed seeding and temp graphs would be a little more concrete than noise observations :-)

[sp1zy]

humm..ok please dont be offended guys, i was only asking and i wasnt saying my openion.

so what i learned now is that the noise is coming from the hard driver. well in that case its not

u torrent that is making rhe noise. we can simply say you allready have a noisy pc because lots and lots of s/w will have the same effect on your h/d like pc games and so on... i just upgreaded few monthes ago my system:

_80 gb hard drive (which i never hear any sound coming from it like u guys said no matter what process i do!! so after all its the hd type who have the final word on this.

_p4 3 ghze priscot with ht

_512mb ram

_5200 geforce fx

and i am sorry for my bad writting but english is not my first language. and dont worry i wont post a lot because i dont have any informations because i am newbie. but this topic just got me worried

because i am new to downloading torrents, as i just got dsl and i was going like: ohh why u torrent

will make my pc sound like an old truck?? when nothing eals dose if u know what i mean .

but i was not by any mean trying to advise in my previous post.. so accept my respects and i am sorry again...

[Wurlitzer]

Dear µTorrent developers.

I would just like to confirm the original post, about the fact that my HD becomes very noisy when downloading at >400kB/s with µTorrent (Compared to BitComet for example).

I can't get very technical about this, so my main argument is that I have a very fragile sleep.

As my computer is in the same room, I find it more difficult to fall asleep now, than with BitComet.

[Firon]

So raise the write queue size to 32768 or whatever.

[1c3d0g]

...and maybe set diskio.flush_files to *false. µTorrent will use more memory this way, but it may help you with your problems. :|

[splintax]

I think using more memory was precisely what he wanted it to do.

Noisy? My computer has been running seven fans (from 80-120mm rated at 12V but running at 20V) for so long that it freaks me out when I work on someone's computer and can't hear it running.

My friend has a PC like that, and it comes in one of those massive Kandalf cases. It's a beast. Me, I'm used to my laptop, which makes almost no sound whatsover. Though it pisses me off in our Australian summer, because the temperature often gets up to 40 degrees C, computers suddenly become much louder.

@kokoko3k: Out of interest, if your harddisk has a temperature sensor, could you perhaps post some screenshots of the temp while seeding with various applications?

That would be interesting to look at. I'd say the best way to do it would be to leave the computer off for half an hour (so the HD has time to cool), then open it up and get straight to seeding. As for changes in seeding speeds, I don't know how much of an impact that would have on the results.. hmm.

so what i learned now is that the noise is coming from the hard driver. well in that case its not u torrent that is making rhe noise. we can simply say you allready have a noisy pc because lots and lots of s/w will have the same effect on your h/d like pc games and so on...

Not really. Apparently µTorrent is not very good at seeding at very high speeds, and reads off the disc a lot more than say, BitComet. Very few processes do as much reading/writing as a BitTorrent download. For example, playing a game just loads textures/maps etc. into memory, but considering the speed at which it is loaded and the amount which is loaded, the disk read sound is nowhere near as prolonged as a BT download.. The OP claims that it is a problem with µTorrent's caching, I'm not going to take a stand on it because I really don't have any solid information one way or another..

[Firon]

Well, µT can seed just fine at high speeds, lots of seeders on ScT getting 8MB/s or so. I haven't heard any of 'em complain about this though.

[Switeck]

Very few processes do as much reading/writing as a BitTorrent download. For example, playing a game just loads textures/maps etc. into memory, but considering the speed at which it is loaded and the amount which is loaded, the disk read sound is nowhere near as prolonged as a BT download.

Games tend to do continuous reads, often 1 file at a time. With a defragged drive, the read/write heads only slowly move across the disk's surface.

But with µTorrent, there is no rhyme or reason to where it gets the next chunk of the file. It jumps around almost randomly because that's the best sharing pattern known as of now. So the seek noises are a LOT louder than straight read noises. Little surprise there.

Even SCANDISK's surface scan is naturally quieter than something like µTorrent. But that's for the same reasons.

[rseiler]

It appears that 1.41 (405) has a 'diskio.read_cache_size,' though it's set to 0. Not sure if -1 would apply or if it should be set to something specifically higher. I'd like to be able to set it to quite a large number.

Likewise, with the pre-existing 'diskio.write_queue_size,' it's recommended that it be set to -1, and not to exceed 32768. I'm still unclear if it will abide anything higher. I'd like to set it to a very high number -- AND I'd like uTorrent not to ignore the higher number.

Like some of the posters mentioned above, BitComet-like caching would be most welcome. According to TaskMan, I can't even manage to get uTorrent to use more than about 20MB -- and that's peak!

Most of us have a LOT of free memory at any given moment. A busy, disk-intensive program like any torrent app should be able to use a lot of it for full read/write caching/staging.

[Firon]

Well, going above 32768 is just not recommended most of the time. But if you can actually get 10-100mbit speeds or something, then going much higher can help and it can get close to that value. µTorrent writes at least every 30 seconds so if you're downloading slowly, it won't get close.

The read cache is disabled by default (0), just pick a high value like a few hundred MB (though you have to use KB).

And the reason BC works like it does is because it bypasses the system cache completely (which isn't possible at the moment with µT)

[rseiler]

Alright, I've gone high on the read cache and we'll see how that goes. In light of this setting, does 'diskio.flush_files' ("makes µTorrent close file handles every minute. This helps reduce the effect of Windows managing the system cache badly") need reconsideration at all? I noticed someone above recommending it be set false in an effort to get uTorrent to use more memory, but that's unclear.

As for write, doesn't uTorrent write about every second, sometimes multiple times a second (given a couple torrents going at moderate speeds, let's say 100-200KB/s)? I've never seen it wait 30 seconds between writes at any speed (I know you said "at least," but really nothing ever close). Filemon is handy to observe this.

Correct me if I'm wrong, but setting write high shouldn't be a problem in any case since uTorrent will never allocate that memory unless, as you say, you have an Ethernet-speed Internet connection or the like, in which case you're actually making good use of it. If uTorrent allocated off the top of memory upon startup, that would certainly mean you should be careful about the setting, but it doesn't.

[Firon]

If you have a very large write cache, it'll write every 30 seconds, otherwise not.

And I meant at least because while it can write more often, it'll never spend more than 30 seconds without a write.

[ettpok]

I've also noticed this noise when uploading a torrent at rate more than 200kbps...here it's like the HD reads something about 2 times per second. Changing diskio.flush_files to *false had no effect...the noise is still there. Pretty annoying to listen to it all day...

I'd really suggest the developers to add some caching features to utorrent. With BitComet my HD became noisy only after 800kbps.

No matter if memory consumption increases a bit but caching would spare my HD.

[DonGato]

From the FAQ:

- diskio.read_cache_size This sets the size of the read cache (0 = disabled). The value is in KiB.

So, it's already in.

[ettpok]

Yeah...I downloaded the latest beta just after posting my previout message. Can't hear noises even at 400kbps now. Great job!

[Mikademus]

Noise, in context, is caused by hard disk head seeks. The noise is produced when the heads need to move across the platters to access requested data. In this µTorrent is much more noisy than the aforementioned clients because its data read design, in the non-beta versions at least, forces continuing reads.

This cause wear and tear as well as heat build-up in the hard disks, all of which directly translates to decreased disk longevity.

Of course µTorrent has a worse caching model as it relies on Windows' read caching, a system that is intentionally generic and thus isn't symmetric with the anatomy or requirements of torrent anatomy,

That many of you haven't experienced this problem is because you do not live under the contingencies provoking it, i.e. a high bandwidth/high upload situation. However, this remains a problem even under more modest situations. I currently have throttled total upload speed to 150 kb/sec because the disks seek too much, but µTorrent still trashes way more than is acceptable. As a comparison I'm only seeding 6 torrents atm @ 150 kb/sec under µTorrent and experience significant HD seeks and constant access, while I habitually seeded ~20 torrents @ 300-600 kb/sec earlier using BitComet without hardly any HD activity (with a read cache at ~25 MB). I'm going to test the betas to see if they make a difference.

However, it should be obvious that this in fact is a problem, but also perhaps the only remaining major problem for µTorrent. And please, no "but it works for me!" replies, kay? That'd just add more noise interfering with the real discussion.

[1c3d0g]

Mikademus: so, have you already tried the diskio.read_cache_size parameter? You can set it pretty high, you know? Like 32768 (32 MB) or even higher, depending on your situation. :/

[Mikademus]

I'm currently running build 418. I'd say that the seek noise and hard disk access has decreased by perhaps 25%, but not more than that. My cache is set at 50000 KB, the HD is still working at much greater intensity than under BC. I don't want to go back to that client for ethical reasons, but I fear care more about my hardware than about making a insignificant stand.

I really hope µTorrent will implement a heavy duty read caching and piece prioritising system...

[1c3d0g]

Hmm...OK. So yuo've set the Read Cache pretty high, what about the Write Queue? Did you set that at a high value as well? :|

[Mikademus]

Its on the default -1 value, but I'm not running any download tasks, only seeding.

[The Mighty Buzzard]

Fifty megs (or 48.828125 megs if you're in the mood to nit-pick) isn't really that large of a read cache if you're sharing several cd-sized or larger files. If you weren't hearing noise off your drives with a 25 meg read cache in BitComet then there's some monkey business going on with which requests were getting filled.

Me, I'd build in a user selectable feature that'd highly prioritize requests for pieces that were already cached. Then make it only function if your total upload rate were 150+kB/s and your cache was a respectible size, say 256M or so. User selectable because if you're using a sweet raid setup the problems it'd cause in the swarm wouldn't be remotely justified. Limited to fast upstream pipes with a large cache because chuckleheads with a 512kb upstream connection or a tiny little cache would end up turning it on and screwing things up for the swarm without a valid reason.

[1c3d0g]

Mikademus, well then set the Write Queue to 32768 at least. :/

[Mikademus]

I think that's the way BC and some other clients do it; prioritising pieces already loaded in the cache, and replacing unrequested pieces at an interval. Sounds like a very sound setup to me.

[The Mighty Buzzard]

Very easy on your drive but not at all healthy for a small swarm. A 64M cache on a 640M iso, for instance, would primarily be putting out the same 10% repeatedly. More or less the flip side to super-seeding; not that bad in large swarms but worthless and even harmful in small ones.

[Firon]

µT doesn't prioritize pieces in the cache AFAIK