wouldou

Established Members
  • Content Count

    38
  • Joined

  • Last visited

Community Reputation

0 Neutral

About wouldou

  • Rank
    Advanced Member
  1. That's interesting. If I may speculate some, if the problem really is Truecrypt related and this isn't just a coincidence between us two, I'd guess that the new caching system in 3.3 is bypassing some Windows routines which are essential for the truecrypt.sys driver to flush to disk. Having said that, I have tried in version 3.3 setting "Disable Windows caching of disk reads/writes" to off, of course, with no effect. The bug still occurs. Also I'm currently running 2.2.1 with this setting enabled (=windows caching disabled) without problems, btw.
  2. I downgraded to µTorrent 2.2.1 and I had no trouble downloading very big torrents. I created high disk I/O with another program so that µTorrent had a lot of "disk overloaded 100%" whenever allocating one of the big files in the torrent, but µTorrent always recovered and continued downloading. This is the part where 3.3 just stalled making any downloading impossible. Until after exiting and then killing the process and deleting or not resuming the torrent that caused it after a restart. I may upgrade to the last good 3.x version, but honestly apart from the quicker and asynchronous program startup which is quite usefull when you have a lot of torrents shared, I don't see any real benefit of 3.2 over 2.2.1. Citation needed. Sparse files will only fail to be created if the user has a quota and that is not the case by default. My user account has no quota, enabling this option should work without running µTorrent as an Administrator. Besides while enabling sparse file creation may help with my problem, I actually can't be bothered dealing with 3.3 anymore, it has stolen me enough of my time already. I assume this was because you didn't follow the guideline to adjust it per your connection rate' date=' and test it with my "gold standard" torrent: [url']http://releases.ubuntu.com/13.04/ubuntu-13.04-desktop-i386.iso.torrent You recommended me your settings.dat and never mentioned any guideline. I have tried to adjust some settings after I noticed the 1/3 download speed, but curiously none helped, not even resetting all of the network and cache related ones back to the default. And yes, I did a restarts for the changes to take effect. Also I've tested two very popular torrents, one having over 6000 seeders (150 in my swarm) with both µTorrent 3.3 and your settings.dat and with Deluge 1.3.6. In contrast to µTorrent the later gave me the maximum download rate I was used to. It may be some hidden setting eventually? Apparently your settings.dat file has some non-default settings which are not accessible without special tools. Logon with a normal user account and try deleting something in the Users folder, try changing permissions in the root of the %systemdrive% Try making an application save a file in the root of the %systemdrive% you will soon find out that YOU are WRONG!!!! All of which has nothing to do with disk I/O. Apart from the fact that none of your examples matter for µTorrent, since it doesn't rely on write accessing those folders. Only during installation are higher privileges are required to copy itself into "Program Files" or "Program Files (x86)". Woohoo, correct but non sequitur. Since my problem is most likely cache related. Thank you very much for the link! Many of the settings are self explainatory based from their short names even, but this "manual" helps clear things up a bit more. Sure, I have looked at the Advanced settings of his myself. I found some of them to be quite odd, unnecessary and even harmful to performance, for example net.low_cpu and net.max_halfopen (unless you are running an outdated version of Windows and a very slow CPU), bt.no_connect_to_services (set to false... why would I want to connect to default internet services when µTorrent offers me the default option to not connect to them?!? actually that list of ports should be augmented with many more ports) or net.utp_dynamic_packet_size (so their auto adjustment code is broken, or why disable it?). Unfortunately the link you provided has no information about these settings... I can't even find much with Google. I have a hunch this may throttle net throughput with a big swarms. Anyway, those settings aren't my problem, it was a mere distraction from my real problem. If this problem even persists in the next stable release of µTorrent I might look into µTorrent's advanced cache and file system settings a bit and see if any of them have any influence. I'm aware that this is triggered by something on my system. My temporary and finished downloads are stored on a Truecrypt encrypted HDD. While straight throughput is acceptable, I doubt with many I/O requests this drive performing adequately, although my high I/O test didn't raise the CPU load caused by the truecrypt.sys threads to exceed 1%, maybe that it isn't very high, should be cause for concern? Although random seek performance of HDDs is so bad, that Truecrypt probably is able to cope. So here's the thing I do know: until the disk I/O code rewrite of 3.3, this was never a problem for µTorrent. Having said that I also remain sceptical whether Truecrypt is one factor, I doubt it for the observations stated above but I just don't know, it could be locking up disk writes in some rare cases, but I don't know, it's all assumptions without much substance to back them up, so it's not suitable for dismissing or proving anything. What I do have seen is that µTorrent wrote incoming blocks into memory but not flushing them to disk until it either ran out of memory and crashed. Or when the torrent was was small enough, it fully downloaded not crashing µTorrent, but only to freeze up, not getting flushed, with µTorrent hogging that extra physical memory indefinitely. Very nicely observable with Process Explorer, a linear increase in physical memory allocation by the µTorrent 3.3 process right up to the moment the download finished. The overall increase being the delta of the size of the completed torrent and the size of the parts that actually have been written to disk until the cache fuckup initiated, which usually occured around the ~400-500MB mark. So I assume it's µTorrent's fault, but I cannot say that for certain. Why could it be that µTorrent 3.3 is the only application on my system that is being denied cache flushing by a supposed bug in a system driver? Or could it be the disk cache code of µTorrent itself? Which happens to undergone a major rewrite with just the version I seem to have so much trouble with... See, that's the part where a professional computer science major who's able to actually debug (for real!) such an issue should have a look. I don't see that happening unless I self train myself some serious debugging skills. But why should I do that when BitTorrent Inc. isn't paying me for doing their work? So I'll resort to the remaing options I have left: use an older, working version of their software or not use their software at all but software instead that does work for me, like Deluge for example. Goodbye for now, problem solved by workaround: µTorrent < 3.3. Thanks, Beasly for providing information!
  3. That's bullshit. Disk I/O is the same for every user. If anything then the process priority changes a thing although it's not directly related to disk access and even with process priorization there's no extra bonus for the Admin account. Now if µTorrent was a service and my Windows installation was set as a server and prioritize services then it would make a difference, but it's set as a workstation and thus applications like µTorrent should already get high CPU and I/O priorization. Which I did, of course, along with the download rate limit. Some settings - if you use them - might requires it... such as sparse_files Creating sparse files is not limited to the Administrator account!:mad: Anyway' date=' with your settings.dat I had a worse stand than before, at least no torrents froze, I assume it was because the network traffic was cut down to a third by your settings. I'm wondering anyway how a single set of rules should work wonders compared to the default settings for the whole diversity of the different internet access methods µTorrent users have. If there is any set of default settings that would work well for most users then I assume it's those default settings which the µTorrent team has built into the client. Unless you want to present some proof that their network settings are generally inferior to yours. Anyway, I'll have to just wait until the private trackers accept a µTorrent version that finally handles disk I/O as reliable as the 2.x and early 3.x versions... [b']Or wait... one last question: Did the resume.dat file format change from 2.0.4??? That's the only file I really need to downgrade back to 2.2.1 without loosing all my torrents. PS: OMG, yes. The resume.dat file of 3.3 works with 2.2.1! If I had only known this before!
  4. I did. I will try. (I hope you have all that eye cancer disabled.) edit: Something's not right with your settings.dat. I only got 1.0 MiB/s out of it, a third of my download rate limit. At first it goes to full speed and drops down immediately again, looks like a bell curve in the graph... with Deluge the same torrent stays at ~3MiB/s... Don't worry, I don't have such snakeoil running anyway. Oh, why? Do Admins get better disk access or what? BTW, now after another test with the same torrent which I delete and readded, 29625 just tells me "Disk overloaded 100 %(sic)", no disk I/O happening and no network I/O either. When I exit it, the process lingers around with no UI and ~5% CPU load, it has to be shot down. Same old story.
  5. I only use µTorrent (3.3) for one particular private tracker, that's the only reason I still use µTorrent at all, it's over 1000 torrents I'm sharing and I would have to migrate them all by hand. I did the mistake to upgrade to 3.x and thought that people who were sticking to 2.0.4 or 2.2.1 weren't quite right in their head and overracting. Now I regret this... Anyway I just tried build 29625 today with a big torrent (~42 GiB), had high hopes, but only after a few minutes or so the µTorrent process was gone. The new disk I/O is still buggy. And I still have this weird bug were any torrent >400MiB cannot be finished, blocks stay greyed out and µTorrent will stop writing out any blocks to the disk. Exiting µTorrent then leaves a ghost process running which needs to be killed with a process manager.
  6. I'm currently using version 1.3.6. But the client isn't called µTorrent, it's called Deluge. I use it for all the downloads that are >400MiB, since 3.3 can't handle those for some reason, won't write out blocks to disk after a while. When exiting it just craps its pants and freezes and needs to be shot. Latest 3.3 build 29625 even crashes with very big torrents, I did a test today. Apparently it's some memory leak and caching issue in 3.3 that has been "fixed" serval times now. Unfortunately I can't downgrade to 2.0.4 from 3.3 with over small 1000 torrents I share on a private tracker. No, way I'll re-add them all manually to µT 2.0.4 or Deluge. So unfortunately I have to run µTorrent 3.3 in parallel. Deluge misses some features that µTorrent has: "virtual" torrent names, renaming the torrent in the client's list which does not affect the actual name in the bencode data structure and thus does not unregister that torrent with the server. At least it allows me to determine the name of the folders for each torrent just like µTorrent, which is more important. Deluge is also quite ugly on Windows since it's a GTK+ application. But I'm very very happy with it. It hasn't crashed once during the 4 months I've been using it.
  7. Is this a comedy forum now? If don't know anything of value to say, tell a lame joke? What kind of argumentation is that?!?What security holes are there in 2.2.1? The changelogs don't mention any, but that might also be due to a policy security by obscurity policy.
  8. FYI: You'll open yourself up to security issues if you downgrade. Like what?
  9. Build 24369: High CPU-usage (100% / # of cores) when selecting items in the torrent list, for example when selecting individual torrents while pressing CTRL. PS: How can I change the dates in the Added and Completed columns back to the normal format? Like "2010-05-14 13:45:01" for example? Something like "a week ago" doesn't really tell me anything other than it was a week ago or something like that... it kind of feels like talking to a retard. No offense towards retards.