Squall-Leonhart
-
Posts
33 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Events
Blogs
Store
Posts posted by Squall-Leonhart
-
-
44 minutes ago, rafi said:
Maybe, but how do you know? Hashing checks is being done during download too, definitely file reads are done during seeding/uploading...
because files currently being written are only accessed via System process for read and writes for the majority of the download task.
Also piece hashing is done in memory and invalid data discarded prior to disk access.
Utorrent is only fighting with System on Rechecks and Completed seeds, which means the bad behavior has only been introduced for the Reading tasks for active seeding and Rechecks
-
Nothing about writes can have benefited from this detrimental read change, they are handled in entirely separate code.
-
On 2/15/2022 at 7:37 PM, MrBlackhole said:
Can you state the build number? I'm currently using 46096, if the response time has been increased in new update, I would update.
it isn't inherent to 3.5.5, i went back as 3.2 and it was affected too.
You have to go back to 2.2.1 to only have the single hash thread, to install that you have to disable the ethernet connection and delete the 3.x settings.dat
-
The disks response time is doubled in 3.5.5 and the Queue Length being above 1.0 indicates that it is being read from 2 unique read threads at the same time
The file response time under disk activity is 2ms for System process and 10ms for utorrent process.
If you're doing file system tasks, you either go all in and do it all in process, or you use the System's FS api's, uTorrent in its current form is doing both leading to reduced file system performance under these particular tasks, I whole heartedly believe whoever made the changes that resulted in this had little to no idea about what they were doing at the time, which has resulted in all those little workarounds and hacks throughout 3.x to fix the disk overloads and flawed caching since.
Its also quite possible that another aspect of reading the FS was nested into recheck.
Regardless, the end result is that uTorrent 3.x is unecessarily more detrimental to disk wear and tear than 2.2.1
Quoteso I believe you are seeing Windows caching/paging "helping" out to split the READ load
I don't think so, reading two locations of the file from two threads running parallel can only be done intentionally through Programmer intent or mistake.
You either do the whole task with the System using its FS api's, or you duplicate those api's in your process and do it within your own process, never both.
Windows FS caching would still be employed either way.
BitTorrent classic has exactly the same bug.
-
The checked process is 2.2.1, notice the pid is the same,
i just forgot to uncheck it after starting 3.5.5, and Resource Monitor is weird in that it tapers off disk access within a timed period so you can see it writing out the settings after 2.2.1 closed while i've already got 3.5.5 started and doing the test
3.5.5's process has a small write underway to C: because it updated resume.dat when the recheck started.
The reason is that Utorrent is opening TWO read handles on the file at the same time during the recheck, one in the System process (standard file system handle, which just about everything uses to open files) as well as one by itself, and then proceeds to fight over access to the file.
2.2.1
3.x-current
This seems like it'd be relatively easy to fix, the client is basically reading the file twice, leading to the head flicking back and forth (maybe its reading to memory, and supposed to hash in memory, but its reading to memory, hashing from disk causing it to read into memory again.IDFK, It's not normal for a process to hit the disk twice to perform an operation once.
For reference, heres Total Commander verifying the files hash
-
On 8/23/2021 at 4:52 PM, DreadWingKnight said:
And is pretty much always limited by the speed of the storage device,
Incorrect, the issues mentioned in this thread are regressions in uTorrent and do not occur in 2.2.1, till who knows when 3.x (i can't even remember)
uTorrent has a flaw in that read-aheads are broken to some degree, this causes the disk queue length to exceed 1.0 on a disk that is otherwise 0.0 when not re-checking, this is worse for large torrents with tiny piece sizes than it is for large torrents with larger piece sizes, but regardless, current utorrent versions are 1/2 - 2/3 slower than older utorrent clients to check large piece size contiguous torrents.
Same file, no defragging in between
2.2.1
3.5.5
-
On 7/24/2019 at 12:35 PM, ex58 said:
As there's no stable thread...
3.5.5.45311 available:http://download-hr.utorrent.com/track/stable/endpoint/utorrent/os/windows
3.5.5.45311 resolves the issue i posted about torrent rechecks being horrifically slow, it'd only existed since as far back as 3.5.3(probably further, and i didn't notice)
-
'Fix' implies that it was working at one point. That's never been the case with 3.4
they were working in 3.4 b30345
though i can't say whether or not if this was the last time they worked properly or if the regression occurred on a later build.
Install 30345 - not working!
How many torrents do you have, I have around 150 and labels are definitely working.
they also work in 30409, but that version has a slow memory leak......
-
Please! Fix labels!
'Fix' implies that it was working at one point. That's never been the case with 3.4
they were working in 3.4 b30345
though i can't say whether or not if this was the last time they worked properly or if the regression occurred on a later build.
-
- Fix: Duplicate device names for android devices
not fixed
every time i plug in an android device 2 items are created.
-
Probably due to short sighted tracker operators who are blocking newer versions of uTorrent.
Indeed
IdiotBT for example.
not having any issues with upload slots being utilised with 3.3
-
X:\Downloads\Torrents\Completed\Music/Jazz\{whatever} which causes a problems when opening the folder location since it trips up on that /.
As you were able to put a backslash after Jazz' date=' use a backslash before Jazz?[/quote']
utorrent 3.0 would use / in labels and then auto correct it to \ upon finish
im not sure where i learnt to use / from though.
-
Using labels to place torrents in subfolders cause the path to have the wrong slash
You can still seed the torrent in this situation but opening the torrent location or files within the torrent will just open the root user documents folder.
Lets say you use labels to place music in a music folder, sorted by genre, you would have a label like Music/Jazz
upon torrent completion, the path in the current beta ends up X:\Downloads\Torrents\Completed\Music/Jazz\{whatever} which causes a problems when opening the folder location since it trips up on that /.
I am not sure when this specifically started occuring.
hmm, or it seems the behavior has since changed to allow \ in labels, i recall in 2.x this would cause problems with the path
nvm then, changed all my labels and corrected any affected torrents.
-
@ChichipioWilson: Thanks for an excellent report! I believe I've knocked these off today, but I'll verify it some more tomorrow. Hopefully we can do a refresh tomorrow night
ah, was wondering about that.
RC3 bug, show in "download" tab torrents that are already finished.had 2 go back ...
yeah, im seeing that too. happening for torrents that you didn't select all files in, its probably the same bug as ChichipioWilson posted so arvid might have already fixed it.
-
Forcing a recheck on a large torrent is consuming basically all memory.
Never had such an issue in 2.2.
-
- Feature: enable/disable detail tabs via a right click context menu
i was too busy searching with logger as the term.
doesn't help at all that between 1.8 and 3.0, the settings for UI have had to be reconfigured 3x.
-
having disk writes enabled at all in 3.0 alpha causes disk overload. its not high speed related (occurs at 4KB/s) and 2.2.1 works just fine.
none of the usual fixes work, none were needed in 2.2.1 in the first place
and whats with the removal of the logger tab....
How to Re-check Torrents Faster?
in General
Posted · Edited by Squall-Leonhart
This appears to be fixed for some torrents with large chunks.