Jump to content

Squall-Leonhart

Established Members
  • Posts

    33
  • Joined

  • Last visited

Posts posted by Squall-Leonhart

  1. 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

     

    unknown.png

  2. 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

  3. 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

     

    Quote

    so 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.

  4. 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

    unknown.png

    3.x-current

    unknown.png


    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

    unknown.png

     

  5.   

    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

    unknown.png

    3.5.5

    unknown.png

  6. '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......

  7. 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.

  8. 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.

  9. 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.

  10. @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.

×
×
  • Create New...