kimputer Posted March 22, 2012 Report Share Posted March 22, 2012 Ai, I wish I could. But I think you cleaned up legacy code, and hence I get an iphlpapi.dll error (on win2000, it's old I know). Too bad, because high CPU load is acting up again (after a few torrents with "normal" cpu load after clean install). Link to comment Share on other sites More sharing options...
Firon Posted March 22, 2012 Report Share Posted March 22, 2012 We don't support anything older than XP. We actually use stuff that is XP-only. Link to comment Share on other sites More sharing options...
rafi Posted March 22, 2012 Report Share Posted March 22, 2012 We don't support anything older than XP. We actually use stuff that is XP-only.Do we support Win8? Link to comment Share on other sites More sharing options...
magnum_2007 Posted April 7, 2012 Report Share Posted April 7, 2012 Hi, I myself came across this problem. Searched a lot but found nothing. SO I finally came up with the solution. I went to the folder "%userprofile%AppDate\Roaming" (for Win7 users), and deleted the folder uTorrent. Then I deleted the exe from Program Files and reinstalled the stable version. Thats it. Remember, this will delete any ongoing downloads record. But they can be resumed by opening the .torrent file again of the same download. Thanks and enjoy!!! Link to comment Share on other sites More sharing options...
Cysiek Posted April 7, 2012 Report Share Posted April 7, 2012 Thx magnum_2007!I couldn't install uTorrent after uninstall. That was only huge process on task manager and no answer from uTorrent though. Link to comment Share on other sites More sharing options...
magnum_2007 Posted April 7, 2012 Report Share Posted April 7, 2012 Thx magnum_2007!I couldn't install uTorrent after uninstall. That was only huge process on task manager and no answer from uTorrent though.So, were you able to install after my procedure? Or do you still need help? Link to comment Share on other sites More sharing options...
AwesomeSRB Posted April 7, 2012 Report Share Posted April 7, 2012 You just need to go to -> C:\Users\i5\AppData\Roaming\uTorrent , and delete settings.dat and settings.dat.old or something like that and that's it..reinstall utorrent and it will work perfectly Link to comment Share on other sites More sharing options...
millerralf Posted April 30, 2012 Report Share Posted April 30, 2012 This might be easier for some folks: In the advanced settings as above, mine was set as true, changed it to false (reset) then went back to true (reset,again) ant it lowered CPU load significantly. Win 7 ultimate, 32bit, uTorrent 3.1, Comodo internet Security. Windows may change things arbitrarily, if you use System restore, etc.:cool: Link to comment Share on other sites More sharing options...
rafi Posted April 30, 2012 Report Share Posted April 30, 2012 In the advanced settings as above, mine was set as trueWhat is set to true? Link to comment Share on other sites More sharing options...
MidnightSun Posted July 24, 2012 Report Share Posted July 24, 2012 Hello, I have the same problem.. when I open the utorrent my cpu go so high i cant even watch a video at the same time... I tried the net.high_cpu option but still nothing happend. Can somebody help me please? it drives me crazy!!! Link to comment Share on other sites More sharing options...
eecolor Posted August 23, 2012 Report Share Posted August 23, 2012 I am on 3.1.3 and the high CPU and unresponsiveness seemed to be caused by a torrent that was displaying an error in the status column. After removing the torrent from the uTorrent list the CPU usage went back to normal.I am sorry I can not offer anything to reproduce this problem. When I loaded the torrent into uTorrent (after removing), it started checking, downloaded a bit and seems to give no problems anymore. Link to comment Share on other sites More sharing options...
DreadWingKnight Posted August 23, 2012 Report Share Posted August 23, 2012 Did you try 3.2 yet? Link to comment Share on other sites More sharing options...
eecolor Posted August 24, 2012 Report Share Posted August 24, 2012 I will install it, strange that the 'check for updates' did not find it. Thanks for the notification Link to comment Share on other sites More sharing options...
rafi Posted August 24, 2012 Report Share Posted August 24, 2012 I will install it, strange that the 'check for updates' did not find it. Thanks for the notificationI guess it's not on the auto-update server yet Link to comment Share on other sites More sharing options...
filmmusic Posted September 12, 2012 Report Share Posted September 12, 2012 (hope this is the right place to post this again)Have the same problem with high cpu!I go to applicationdata/roaming/utorrent but i don't see any setting.dat file.I see 4 folders (apps, Cache, dlimagecache, ie) from which Cache and ie are empty, and all the torrents i've ever added to utorrent.(the size of them are 71MBs in total)I paused all utorrent activity, but still it can go from 15-30%!I'm running utorrent 3.2 on Windows 7 x64, and I have Panda Internet Securityif i uninstall utorrent and delete the folder in application data, i guess every activity in utorrent (uploads and downloads) will be deleted too, right?It's just that i have so many torrents uploading (around 60) from a a dozen sites, and can't put again each one.. Link to comment Share on other sites More sharing options...
DreadWingKnight Posted September 12, 2012 Report Share Posted September 12, 2012 Did you try with panda uninstalled? Link to comment Share on other sites More sharing options...
filmmusic Posted September 13, 2012 Report Share Posted September 13, 2012 But i have Panda for years and use utorrent too.This problem is in the last few weeks..So, it couldn't be Pandahmmm..Now i have only one torrent downloading at low speed.the cpu usage is 36-40% when I put utorrent in fullscreen, and drops to 1-3% whenever I minimize it and have it in the tray.So, i guess that's normal?I don't remember if the high cpu usage when i downloaded 4-5 torrents at max speed was only when i had it in full screen, or minimised in the tray too. I will have to look at it.. Link to comment Share on other sites More sharing options...
Kitsoran Posted September 13, 2012 Report Share Posted September 13, 2012 It can still be a Panda issue. Link to comment Share on other sites More sharing options...
net-j Posted November 4, 2012 Report Share Posted November 4, 2012 HelloI've investigated the problem in subj and found 1 100% reproducible factor (of how many?) which leads to high CPU usage and freezing UI.Conditions:OS: Windows 2003 Server SP2uTorrent 3.2.1 which I get on "standard way" from http://www.utorrent.com/intl/ru/downloads/complete/os/winScreenshots with CPU usage history for 12 minutes were acquired for uTorrent minimized to system tray to exclude UI overhead.A time period between setting up uTorrent process to required state and acquiring screenshot with CPU usage history is 20 minutes.But the found factor is for uTorrent v3 (not only 3.1.2 or 3.2.1) and does not depend from OS (see my previous post with observations on uT v3.1.2 and Win2k SP4, which were acquired on the same torrents set, but the factor left unknown).[h]First, let's look at the PE Performance Graph tab with CPU usage by uTorrent 3.2.1 process.[/h]uT process in high CPU usage state:Full size imageOne can see the highest green peaks with average height 60% CPU usage (5.5 cells, under red pillars) with average period 19 grid cells (6*19=114 seconds) between themandthe more frequent red pillars with repetitive lengths of 2-3 cells and heights of about 3 cells.Then I change something in this uTorrent process, wait for 20 minutes and get the following CPU usage history.uT process in normal CPU usage state:Full size imageThere are no more red pillars which show high CPU usage in kernel mode.All what I did I stop torrents with huge file list. Also this torrents does not produce any valuable upload traffic (checked by number of peers and upload columns).I repeated this experiment 3 times for 3 independent uTorrent processes (one process at one time) on the same machine, OS and winlogon session to check reproducibility.[h]Second, let's look at the some characteristics of those "huge file list" torrents and compare them with some others to check the hypothesis.[/h]# Number Size Link1 4625 31 GB http://rutracker.org/forum/viewtopic.php?t=4693052 10644 17.4 GB http://rutracker.org/forum/viewtopic.php?t=14075133 8908 8.28 GB http://rutracker.org/forum/viewtopic.php?t=14390824 9680 10.0 GB http://rutracker.org/forum/viewtopic.php?t=14534425 11495 15.2 GB http://rutracker.org/forum/viewtopic.php?t=30144146 342 4.01 GB http://rutracker.org/forum/viewtopic.php?t=18184397 607 3.38 GB http://rutracker.org/forum/viewtopic.php?t=2690353# - the local id of the torrent.Number - the number of files in torrent.Size - the total size of files in torrent.Link - the source of torrent file.This 7 torrents contains music and topographic maps in GIF format.Let's compare with other torrent with big total file size and small number of files:# Number Size Link8 34 41.2 GB http://rutracker.org/forum/viewtopic.php?t=2566619This total size of files in this torrent is 41.2 GB, but it was run when the second picture with CPU usage history have been acquired. Also the survey was used other 90 running torrents at the same time with average file size 500 MB and 2 file per torrent in average.Hence this 1 found factor which leads to high CPU usageis the huge number of files in some torrentsand does not depend on OS ortotal size of files in all torrents ortraffic.[h]Third, let's investigate the freezing UI considering to huge file list torrents.[/h]After acquiring the second picture 7 listed huge file list torrents left stopped and uTorrent minimized to tray.The following actions show the correlation between this torrents and freezing UI:1. Open uTorrent window2. Select 7 listed torrents in UI3. Start them and wait ))))I waited for 1 minute 34 second while UI become responding to mouse actions.After this delay all 7 torrents were running.[h]Conclusion[/h]The 1 found factor which leads to high CPU usage and freezes UI is the huge number of files in some torrents. Minor version, OS, total size of files in torrent or traffic did not have a strong influence in selected conditions.And now, devs, you can use the conditions, test data and reproducible effect described in this survey to find and burn pieces of code where algorithm sucks on huge number of files in torrent. Good luck :-)Thanks for your attention!Any questions? Link to comment Share on other sites More sharing options...
arvid Posted November 5, 2012 Report Share Posted November 5, 2012 Thank you for this very detailed report. I will take a close look at this. Hopefully we can have it fixed soon! Link to comment Share on other sites More sharing options...
rafi Posted November 6, 2012 Report Share Posted November 6, 2012 ConclusionThe 1 found factor which leads to high CPU usage and freezes UI is the huge number of files in some torrents+1 !I believe the root cause is internal files not being aligned to 16KB boundaries, thus huge # of read-modify-write operations. My belief is that a special cache for those 16K edge piece - can solve the issue! Link to comment Share on other sites More sharing options...
arvid Posted November 15, 2012 Report Share Posted November 15, 2012 So, my initial thought was that this could be caused by the problem in 3.3 where we end up flushing a lot of 16 kiB blocks to disk. If the assumption is that torrents with many files means most of the pieces are not aligned to file blocks on the filesystem, this would make sense (but that relies on the inverse being true as well; that the torrents with few files have the main file as the first file, so that most pieces are aligned).This would also explain why the majority of the CPU usage is red (which I assume means kernel CPU time). Since it's the kernel that needs to deal with the unaligned, small, writes.However, it doesn't explain why this would manifest itself in 3.1, where we still use the old disk cache algorithm in a single thread. The fact that the torrents that don't trigger this problem still don't appear to have the majority of pieces aligned, also suggests that this is unrelated to aligned v.s. unaligned reads/writes.I ran the following test on Windows 7:1. I generated a test torrent with 1000 files, each about 5 MB each (the sizes were deliberately made so that the pieces would not be aligned with the files). The test torrent ends up being 5 GB in total.2. Download this test torrent from 50 test peers over loopback, with default settings except bumping the cache size to 128 MB.3. The download rate hovered around 10 MB/s (it's a fairly weak machine, especially its harddrive). The CPU usage was steady at below 10% for the duration of the test.4. The average size of writes to disk was about 100kB (with 1 MB piece size), so write coalescing did happen.I also ran the same test but uploading to 50 peers instead of downloading. The upload rate hovered around 15 MB/s, and CPU usage very low at around 1 - 2% (since there's no hashing when uploading, there's less pressure on the CPU).Now, the fact that I can't reproduce this could be explained by any of these reasons:1. windows 7 doesn't exhibit this problem2. 1000 files is not enough to trigger it3. you have some specific configuration option set that triggers this issue4. some driver of yours doesn't like certain kind of load (say, unaligned disk writes)My guess would be that it's either 1 or 3. Given that the CPU that's being used is in the kernel, it's probably some specific system calls with some specific options that trigger it.Would you mind sharing your settings file?Also, do you see this load even if you're not downloading anything? (say, if you start all these torrents but set a download rate limit to something low). If not, does the CPU usage seem to be proportional to the download rate?I guess my next test should be with 100 test torrents. Also, the spikes of green CPU usage you see (in both cases) coupled with spikes in I/O, that's when we save the resume.dat file. This is not done very efficiently, and I'm hoping to be able to fix this at some point.I'll keep trying different configurations to trigger this. Please let me know if you have any thoughts of what other properties that may be correlated to this mis-behavior. Link to comment Share on other sites More sharing options...
rafi Posted November 16, 2012 Report Share Posted November 16, 2012 I also didn't notice any special CPU % load with my Win7. This is also not a good measure when you try to compare. You need to consider only the overall (over the whole download, or per gigabyte of file) of CPU consumption, so to take the CPU type partly out of the equation. Sadly, I also reached the same *poor speed* result you did.My concern is this poor speed you/I am seeing here, not even close to the disk write speed capability. In my opinion - doing the test over a loopback is not good. You mix up seeds & peers activity of reads/writes, usually to the same HD.You should be using a 1G LAN (as I do), and ideally, should reach a speed close to your HD capability (~40-50MB/sec). This is what you can get when you copy a file in Windows... If you don't (even for a single file), than uTorrent is capping it. And you don't! BTW, older releases of uT with a single (aligned!) file - did reach a speed very close to this! Using multiple-files torrents, resulted in ~50% speed drop (over LAN), which clearly proves you do have an issue with reaching the top possible speed when handling those! I might try using Windows performance monitor, try see if it can shed some more light. Oh, and you forget a 5th option - a uT bug/poor-design... Maybe stopping to write the resume.dat file ? ... We can try to just increase the advanced option for the resume write rate to 99999...The only question here is - why uT is doing that, and how to improve on it. Can you please try to cache edge 16Ks, and not use 16K sized writes when a piece size is >512K... Link to comment Share on other sites More sharing options...
AdamK Posted November 16, 2012 Report Share Posted November 16, 2012 Hey, Rafi,Please run diskmon, and send us the report for a good run, and a bad run.http://technet.microsoft.com/en-us/sysinternals/bb896646.aspxThanks,Adam Link to comment Share on other sites More sharing options...
arvid Posted November 17, 2012 Report Share Posted November 17, 2012 Rafi, I'm using a benchmark tool that deliberately does not read any data from disk. The test torrent consists of predictable data that the benchmark tool can generate on the fly, so there should not be any contention over the disk. Also, the machine I'm testing on does have a pretty slow drive, I don't think it can do much better (at random access writes). This is a version of 3.3 with the cache flushing issue fixed as well (we'll release it next week). Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.