Jump to content

anyway to reduce hard disk's work?


Kan5478

Recommended Posts

Posted

i couldn't really find the correct term for this...

but my question is, is there any setting to reduce the hard disk's work?

i just want my HD to live for as long as possible and not get all worn out so soon cause of daily dowloading :D

i read about the diskio_write_queue_size and it's set to -1 (automatic) but i also read on other threads about people setting it up to 32MB...

any recommendations here please?

i have 3Mbit max download speed and using a 80GB WD 7200rpm hard disk (2MB cache i think :P)

does RAM size matter as well? i have 1GB (in case you need that info as well)

thank you in advance

Posted

Apart from the fact that this stuff won't really make a difference, your drive will either last less than 3 years, or more than 8 in a desktop environment REGARDLESS of what you do (server drives are different~), just bump up the cache to 32768 and you'll be fine.

Posted

I've found that either exclusively leeching or exclusively seeding eases the workload on my harddrive. It might just be a placebo, but having it just reading when seeding or writing when leeching seems to make for smoother running. For me anyway.

Audibly, I can hear my HD clicking away heavily when doing both, but when only doing one or the other, it seems to take it in it's stride.

Posted

It would make sense, since you'd place additional strain on the drive because it'd have to constantly move back and forth to read your seeding files AS WELL as reading and writing the downloading torrent. :P

Posted

I'm still very unclear on the details of this subject. For reference, see Firon's and then acd's posts here:

http://forum.utorrent.com/viewtopic.php?pid=20873#p20873

Even set to 32MB, I can't tell uTorrent is doing any caching (I also have coalesce writes to true). Even when torrents are not downloading at great speeds, the disk is still very active with multiple reads/writes per second from uTorrent (as shown in Filemon).

That's not caching in my mind. How is that using the 32MB?

Even after running all night with heavy use, I can look at Taskman and see that the "peak" memory for Utorrent is never indicative that it used 32MB of memory for cache (sometimes the peak is in the lower 20's). I would always expect to see 32MB plus whatever the program itself takes, but I never once have. This apparently means that uTorrent never needed the extra memory for caching so it didn't take it, but that goes back to my initial observation that the caching doesn't seem to be working.

As acd mentions, a scaling dynamic cache that would be able to take advantage of the gobs of free memory a lot of people have sitting around, staging the reads and writes in batches, would be the ideal.

Failing that, the ability to specify a high amount of memory and *have uTorrent use it agressively* would be fine as well.

I'm not exactly sure what we have now.

Posted

If uTorrent is using its 'cache' at all, it may only be using it for incomplete writes...like when it doesn't have a complete chunk, it may be holding the incomplete chunk entirely in ram and write it to hdd only when it completes.

This might explain the massive clicking, as every read requires a separate hdd access.

Posted

It caches, but only for writes. (read caching is generally useless, and don't forget that windows has its own HUGE system cache with prefetching) It has to flush the data every once in a while though, since it doesn't check pieces in the cache. It only checks pieces after they've been written to disk (to make sure they write properly I guess). If your download speed is really low, it may not get a chance to ever fill the cache, since like I said, it has to flush it every once in a while.

It also writes the .dat files every 30 seconds.

Posted
I'm still very unclear on the details of this subject. For reference, see Firon's and then acd's posts here:

http://forum.utorrent.com/viewtopic.php?pid=20873#p20873

Even set to 32MB, I can't tell uTorrent is doing any caching (I also have coalesce writes to true). Even when torrents are not downloading at great speeds, the disk is still very active with multiple reads/writes per second from uTorrent (as shown in Filemon).

That's not caching in my mind. How is that using the 32MB?

Even after running all night with heavy use, I can look at Taskman and see that the "peak" memory for Utorrent is never indicative that it used 32MB of memory for cache (sometimes the peak is in the lower 20's). I would always expect to see 32MB plus whatever the program itself takes, but I never once have. This apparently means that uTorrent never needed the extra memory for caching so it didn't take it, but that goes back to my initial observation that the caching doesn't seem to be working.

As acd mentions, a scaling dynamic cache that would be able to take advantage of the gobs of free memory a lot of people have sitting around, staging the reads and writes in batches, would be the ideal.

Failing that, the ability to specify a high amount of memory and *have uTorrent use it agressively* would be fine as well.

I'm not exactly sure what we have now.

have to agree on tat but in BC thou, e cache i can visibly is being used as i can see e mem space it takes keeps on increasin until ofcourse e limit I've specified, one things thou is tat, once it reaches e limit in BC, it then starts to use e HD aggresively!

Posted
I've found that either exclusively leeching or exclusively seeding eases the workload on my harddrive.

This is one of the reasons why the Mainline client was designed for running one torrent at a time. The recent versions have reluctantly added the ability to have several simultaneous torrents, but it is off by default.

Posted
Even set to 32MB, I can't tell uTorrent is doing any caching (I also have coalesce writes to true). Even when torrents are not downloading at great speeds, the disk is still very active with multiple reads/writes per second from uTorrent (as shown in Filemon).

As acd mentions, a scaling dynamic cache that would be able to take advantage of the gobs of free memory a lot of people have sitting around, staging the reads and writes in batches, would be the ideal.

The current (and recent past) stable versions of Azureus do exactly what you are asking for. It fills the entire cache, then performs a large batch of reads/writes to partially empty the cache. This behavior has always caused issues for me with occasional stuttering of sound/video due to the relatively high amount of disk simultaneous reads/writes. I posted a question about Azureus' cache behavior on their forum and one of the devs added an option for per-piece flushing (flushes each piece out of the cache as it is completed) within a day. Talk about customer service. :) I tested out the new beta and it had fixed the issue.

The point of my story is that the current method that µTorrent uses is theoretically not the most ideal, but it appears to be the best method in practice and benefits overall system performance.

Posted

Yep. Me constantly downloading stuff, unRARing it, deleting the RARs and moving the completed files to an external HDD fragments my hard disk badly, and after running defragmenter, I get a nice speed boost :)

Posted
[...]The point of my story is that the current method that µTorrent uses is theoretically not the most ideal, but it appears to be the best method in practice and benefits overall system performance.

Could you please advise how to configure µTorrent for minimum hard disk drive wear and tear?

Thank you.

Dc

Posted
The current (and recent past) stable versions of Azureus do exactly what you are asking for. It fills the entire cache, then performs a large batch of reads/writes to partially empty the cache.

The point of my story is that the current method that µTorrent uses is theoretically not the most ideal, but it appears to be the best method in practice and benefits overall system performance.

How does it fill the entire cache without using the memory? Like I said, the total peak memory usage I typically see uTorrent (set for 32MB) using is in the lower 20's. That's program code AND cache.

So it's filling the entire cache in less memory than the size of the cache?

My speeds can be low but just as often get up to 100KB/s to 500KB/s, which you'd think would be fast enough to utilize the full 32MB cache size before it must be flushed.

What dictates when the cache needs to be flushed? Is it time? Bytes? Could it be made variable so the writing isn't so constant? If the time could be increased, the size of the cache could be too. Seems like a win-win.

Posted

I am a regular re-seeder of multiple simultaneous torrents using Azureus and with a 48 MB cache, it is very clear that the great majority of savings is with hard drive writes. The drive only makes an occasional burp as it does a giant write. In comparison, I get anywhere from 45% to 85% reduction in hard drive writes and from 3% to 22% savings on reads. The 22% is like the all-time best that I can remember; it typically is more like 5% to 8% on reads. So, there is scant savings on hard drive reads if you have several seeding torrents mixed with a downloading torrent.

Since the azureus cache reads ahead, I run defrag on my seeding drive and that improved the reads a tiny bit. If you run seeding 12 hrs per day, that tiny bit actually is a reasonable savings.

As for how I decided on 48 MB..... I typically run a few seeding torrents and a few downloading torrents. I progressively increased my cache until I didn't notice a big change in the savings on hard drive writes. I started with 8MB, 16MB, 24MB, 32MB, 36MB, 42MB, and then 48MB. Around there seemed to be the point for my typical torrents.

If you use this "inching up" method to find a good cache, rememeber to do it with a set of torrents that you "typically" access (size, number of peers, etc). Ha, ha, if 90% of your peers are bitcomet users, you will probably have a zillion unfinished Pieces so you will need a larger cache. <-- jibe made at bitcomet 0.60 expense.

So, for uTorrent, I suppose I would use a somewhat smaller cache since azureus puts more reads into it. I haven't set my uTorrent one from that default -1 because I don't do re-seeding with uTorrent (waiting for a persistent superseed feature).

  • 6 months later...
Posted

I hate to bump an old thread, but I thought it'd be better than making a new one on the exact same subject. ;)

I'm a recent convert from Azureus and I'm still attempting to configure µTorrent to work the best on my system. It's on 24/7 and almost always seeding. I have a slow connection (1.5mbit/896k), but I usually have a couple hundred torrents active in my client in an attempt to find someone to upload to and make use of my upload speed (I'm on a private torrent site where the seed to peer ratio is usually quite high).

I have 2 gigs of RAM, so RAM usage is not a concern to me whatsoever. So, this is what I've come up with after reading the FAQ:

utorrentcacheik9.png

Is this best? Or can anyone offer any suggestions to reduce the hard drive read / writes any further?

Posted

Yes it is better to bump an old thead than start a new :)

I guess you might want to check the last one as well (increase cache size). Everything else should probably be fine. If you want, you can always increase the cache size some more, though it probably wouldn't affect the frequency of disk accessing as much as it used to with the old cache system.

Posted

I think you misunderstood. Raising the cache won't affect reads and writes as much compared to the old system because the defaults ALREADY reduced it by several orders of magnitude.

Archived

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

×
×
  • Create New...