uT crash cause Disk Cache setting (Reduce memory usage when cache is not needed)

[livemusic]

Hi!
 
Here is uT = uTorrent torrent-client software. Let's go!
uT crashed if to set "Options - Preferences - Advanced - Disk Cache" setting as on picture attached.
 



 
 
If to set "Reduce memory usage when cache is not needed" setting to "false" than cache increases until limit listed in "Override automatic cache size..." is 1800, 1500 MB. But here uT comes to crash in minutes or tens of minutes.
 
1) Why so small cache size (max. 1800 MB)? 32-bit? Why still no 64-bit version of uT?
 
2) If to set "Reduce memory usage when cache is not needed" setting to true, than there is no chance of using more than 50-70 MB of cache (saw it practically). So using HDD constantly read/write actitivities instead of cache in RAM will made damage to HDD device much more quckly. How to use uT 32-bit with no big cache about 1.8 GB and if it even can not use that cache? uT crashed everytime after some tens of minutes or hours of work with "Reduce memory usage when cache is not needed" disabled to get lower disk activity to save HDD health longer and to seed - main activity in torrent-net. How can we seed? We do not want to get HDD health worse in 1.5-2 years.
 
Best solution in my opinion: create 64 uTorrent client software and no limit to cache, at least max. cache must be 32 GB according to nowadays RAM controllers of home CPU PCs. What about servers maximum?
Main goal of seed in whole torrent-net will be very comfortable to achieve if to use "best solution" written in that message.
 
What do uT team and others think about it? What workload of that?
 
 
Thanks for attention!
Best Regards,
Livemusic

 

---

uTorrent 3.4.2 (build 32354) [32-bit]

Win 8.1 x64 with Update with current updates, 8 GB RAM (2*4 GB, dual channel)

[DreadWingKnight]

1) Why so small cache size (max. 1800 MB)? 32-bit? Why still no 64-bit version of uT?

Because the ONLY time that uTorrent is actually using the full disk cache size is when something else on the system is slowing down hard drive activity.

There is no performance or stability benefit to 64-bit uTorrent.

So using HDD constantly read/write actitivities instead of cache in RAM will made damage to HDD device much more quckly.

And letting the hard drive spin up and down repeatedly causes worse damage faster. A drive working constantly, even with random seeks, is going to take less damage than one spinning up and down repeatedly.

[livemusic]

DreadWingKnight, It will be some kind of emotional answer. Sorry for may be so impressive talk, but I can not to understand what uTorrent "administration" and developers want from their software product - to stay "as is" or to upgrade to solution.

 

Because the ONLY time that uTorrent is actually using the full disk cache size is when something else on the system is slowing down hard drive activity.

 

But for my PC in many cases (I think 80-85%) was NO ANY ACTIVITY BESIDES uTorrent: no AV installed and defragmentation is going automatically and only weekly. And I have 2 HDD: system (Program files + Windows) is on WDC WD5000AAKS-00A7B0 (465 GB) about 300-350 MBs free on it and to torrent downloads ST1000NC001-1DY162 (931 GB) 800-200 GB free in different periods. So I have isolated from any of the system files separate physical drive. But uTorrent crashes every some hours if leave it with specified settings.

8 crashed per week is it always some activity in background while PC leave idle? Or is the great activity to surf a webpages 1-5 pages per minute? And uTorrent crached in some tens of minutes. Activity is not the cause of the problem if developers want to understood why it is going on.

 

 

And letting the hard drive spin up and down repeatedly causes worse damage faster. A drive working constantly, even with random seeks, is going to take less damage than one spinning up and down repeatedly.

 

Sorry but I have no examples to let my HDD to spin down then PC is on (it is my setting in Power plan of Windows). May be uTorrent can be upgraded to look into look into that setting in Power plan of Windows and can make corrections to work better? Again bad idea? uTorrent developers won't uTorrent software to be better?

 

I can not to understand uTorrent "administration": what's the problem to understand and make solution; to compile 64-bit version?

If uTorrent "administration" did not want to make uTorrent better so please tell me about it. I will stop wasting my and Your time.

 

My point of view: uTorrent have crash problem than user optimize disk usage via Settings of uTorrent client. It is good optimization and problem is with uTorrent client. User says about it. Developers must thank user for his report in terms of uTorrent will be improved in further, developers must to understand what is the problem and work on it instead of saying about mystic HDD activity that have no happen in user PCs (if opening of a 1-5 pages per minute is Your understanding of the HDD activity - I am giving up fully, please tell me if so). I just want to make uTorrent better and can share information Your want with You and developers.

[livemusic]

Because the ONLY time that uTorrent is actually using the full disk cache size is when something else on the system is slowing down hard drive activity.

 

Can developers confirm it? My experience tells me that it is not true or may be some kind of Your understanding of "HDD activity". My understanding "HDD activity" is that HDD constantly got write|read requests. For example, if HDD use is 3 seconds per minute I can say that it is near idle of HDD and very far from activity. What Yours "HDD activity"?

[DreadWingKnight]

I can not to understand uTorrent "administration": what's the problem to understand and make solution; to compile 64-bit version?

It's more than just running the code through a compiler set to 64-bit, and the problems related to the code changed required made it unstable.

We tried 64-bit already, it helped nothing.

Run fewer torrents at once, with lower disk cache limits, and make sure to realize that uTorrent's disk activity is NOT sequential.

[livemusic]

It's more than just running the code through a compiler set to 64-bit, and the problems related to the code changed required made it unstable.

 

All new usually unstable and need to be tested. So not to update?

Besides updates... are nowadays crashes means stable?

 

 

We tried 64-bit already, it helped nothing.

 

DreadWingKnight, slightly off-topic, but if You can say or link it, please: what was an ideas to switch to 64-bit version? What was the core ideas which having problems running in 32-bit mode?

 

 

Run fewer torrents at once, with lower disk cache limits, and make sure to realize that uTorrent's disk activity is NOT sequential.

 

Ok, I switch uT to work with 1 torrent 23 GB with 1000 MB cache. Working several hours. Looks like stable.

About 3 hours I switch uT to work with my all 44 seeding torrents (about 100+ GB) with 1000 MB cache. Still working. Looks like stable.

Now I switch to 1300 MB to find "crash border".

 

This advice is good if to work with uT "as is". Like user to user advice. But it is not solve main problem of topic.

I am here to report about crash if to work with 1800 MB and near it cache size and to advice to make limit size more wider (actual size for home users PCs today - to 32 GB).

 

Forum is for developers and users to contribute to developers helping them to improve application and to help users find answers on their questions, is not it?

May be some advanced users can help other users, but looks like my problem is not in case of it.

[DreadWingKnight]

I've been over this time and time again.

High disk cache settings do NOT help in normal operation. If the hard drive is keeping up with the writes, the disk cache doesn't (and shouldn't) get used.

Crashes at high disk cache settings are expected behavior because of 32-bit per-process ram limits imposed by windows.

A 64-bit version only allows a user to have more pieces get thrown away completely when their machine does crash and does not offer any performance or stability improvements over the 32-bit version.

The discussion was open before and while the 64-bit version was available originally. It's now closed until we have the resources to re-examine things.