georgex1

From my experience, the solution for this is to upgrade to v3.2.3 (never above), some settings may help: coalesce writes (disable write each piece at finish), sequential download to favor sequential disk write (shift F2 hidden menu), read cache is a must if you seed a lot. I also use PrimoCache (free beta) - you can define some write delays (helpful to smooth the I/O spikes if not coalescing). You may even allocate some level 2 cache (fast hdd / ssd). Or maybe Dataram RAMDisk (4gb limited free) - but this solution doesn't help when large or multiple torrent downloads exceed allocated ramdrive.

Windows caching problems are related to the number of jobs that are active and holding file 'handles' open that "Superfetch" is 'anticipating' as being required to be instantly available. You can test different settings for a fixed size "swapfile" rather than allowing Windows to manage it automatically (which it rarely gets right), start with it set to 1.5 x RAM as a minimum size and 2 x RAM for the max size (so 4GB RAM would mean 6166MB to 8192MB swap file size (System Properties -> Avanced -> Performance) ArsTechnica have a article that explains the Windows NT variants memory handling in a not too geeky way. The thing is ... The 'other options' also add to the overhead. I Have 1000 Mb cache set for utorrent. If i go for 1800 it will freez even faster. i have 32 Gb of ram, i still need to set the swapfile to 40min -60max GB ? Have you tried to disable write piece immediately? And also activate sequential download, coalesce writes, maybe even increase coalesce size? I have default 50Mbps connection (top uT speed 8.1MB/s), with limit for uT upload and the disk is works fine with 3.2.3. Anything above doesn't obbey to these rules and writes random small blocks causing a lot of mechanical head movement. If you have some RAM you may activate a disk cache (free betas are available), which should balance writes and maybe coalesce neighbor index pieces, causing fewers file system accesses (I hope you have NTFS:o).

Tried the new version, a mistake of course:o. It tries to write blocks of unfinished pieces even if cache is free, and eventually will overload the disk on high bandwidth connections. <Really? You're really going to break the rules in one of the most watched by moderators part of the forums?>

Stable still has strange cache behavior. "Write out finished pieces immediately" doesn't really work, since my cache rises up 190 mb with lots of completed pieces, and I'm not limited by hdd. When the new algorithm decides to write to disk, it writes everything including blocks from partially finished pieces (that are still downloading, not interrupted by peer).

Stable still has strange cache behavior. "Write out finished pieces immediately" doesn't really work, since my cache rises up 190 mb with lots of completed pieces, and I'm not limited by hdd. When the new algorithm decides to write to disk, it writes everything including blocks from partially finished pieces (that are still downloading, not interrupted by peer).

A related issue on caching: "Write finished pieces immediatelly" switch doesn't work any more... rolling-back

Hi, Not sure if it is the way it should be, or just a glitch. Using 28854 on ADSL, I noticed the cache flushes entirely (up to 0 used). Not sure if it is just a display glitch, but I don't see a point in flushing whole cache to disk if the pieces progress nicely (I even saw uncontiguous block pieces getting flushed). Other than this it sounds better with the new flush threads. Regards,

Hi guys, Since 3.0 I've been noticing some higher temperatures on my CPU, and no it's not the summer. I have an Athlon II X2, and it seems that uT tends to get better afinity with core 1, so this gets more load preventing the Cool N' Quiet to throttle down the CPU. In Win 7 I forced the afinity on CPU 0 and now it's fine, unfortunately I have to do this each time uT starts.

10x 4 ur quick replies. @DreadWingKnight: Sry if I didn't make my self understood. I kind of know what availability is, but I don't really need to pinpoint all the decimals all the time, so this was a GUI improvement idea. Everything above a threshold should be shown w/o the decimals. @Switeck: I'll try ur sugestions. Indeed the teoretical speed should be double on upload.

Hi guys, i had an issue with the availability number even before (strange number lots of 9 after decimal). But build 16667 disapointed me ... it made it worse, now it shows only the done field without the % format. So guys, FmPoV the availability should be more accurate when there are fewer peers. 5.997 it's ok, but 16.997 it's useless (16+ will do). And if there are 5 seeders and 20 peers with (random) pieces, the availability should be shown as 10+, or smth, not (seeders+max peer availabilty). One more thing ... I have a ADSL connection (6 Mbps down / 512 kbps up), I have to limit the upload to about 20 kB/s in order to download ok, is this normal.