ut 3.3 slow disk read while checking files

[fusk]

So, i can't figure this one out. But if i stop everything, nothing else on my computer is working besides ut and only on that 1 process. Through ut/speed/disk statistic and disk utility in windows, i am told that ut is reading at about 15/22 mb/s which i find quite slow.

Drive: st3750528as (not system disk)

Controller: ahci

Used Crystaldiskmark

UT: 3.3 28993

Anyone got any ideas as to why, during check, ut does not utilising the full potential of the disk it's reading from ?

[fusk]

Guess i should move this into bug reports instead as this seems to be unknown.

[ciaobaby]

That is in Mega BYTES per second.

[fusk]

So?

I didn't find it relevant converting into kb/s, kbps or something higher. Or is there some rule specifying the measurement?

[DreadWingKnight]

You're getting over half of your random read speed, it's not doing as bad as you think it is.

[ciaobaby]

There are eight bits in a byte, 1B = 8b so you need to multiply the results by 8 to get bps (bits per second)

[fusk]

You're getting over half of your random read speed, it's not doing as bad as you think it is.

Compared to the random read, yes it's about half, but that's still only half, which is pretty bad.

I have two of those disks, and can copy a file between them with about 60/70 mb/s, and UT can't check the same file with more than 17 mb/s on average, doesn't makes sense as it's the same reading.

There are eight bits in a byte, 1B = 8b so you need to multiply the results by 8 to get bps (bits per second)

Correct, more on that here. http://en.wikipedia.org/wiki/Byte

[DreadWingKnight]

I have two of those disks, and can copy a file between them with about 60/70 mb/s, and UT can't check the same file with more than 17 mb/s on average, doesn't makes sense as it's the same reading.

It's not the same reading actually, since there's a hash calculation being thrown in on top of that.

[fusk]

What does that mean performance wise ?

[ciaobaby]

It means that you are overly concerned with minutiae, and failing to take into account that between 'reads' there is a chunk of processing to be done before the next piece is read from disc which will reduce the 'average disc read rate by ~20 - 25 percent if not more.

Plus there are other processes involved in any disc to memory activity.

[fusk]

It means that you are overly concerned with minutiae, and failing to take into account that between 'reads' there is a chunk of processing to be done before the next piece is read from disc which will reduce the 'average disc read rate by ~20 - 25 percent if not more.

Plus there are other processes involved in any disc to memory activity.

I wouldn't call it minor, i think it's a huge impact.

And i didn't really fail to take anything into account as i didn't know, if i knew all the details i wouldn't be asking the question in the first place.

But i'm amazed that, that process decreases the disk read by 50+%

Makes you wonder why UT doesn't read it into ram instead, and then onto UT, then the disk could read at full speed as the hash checking and other stuff wouldn't happen before UT reads from ram, which is a lot faster.

[ciaobaby]

Makes you wonder why UT doesn't read it into ram instead

It DOES.

BitTorrent clients understand pieces and each piece has a hashum stored in the metadata. On a recheck each piece has to be read off disc into memory, hashed and that hash is checked against the metadata hash to ensure that the piece has not been altered in any way.

[fusk]

So the process is so intense that ram can't keep up with a harddrive, and therefore the disk read speeds are decreased. Because when it's loaded into ram, it re-reads the data to check the hash?

Guess that explains why utorrent is only using 100 mb ram out of 8gb while checking a 3.3gb file, when while it's uploading it's using 200 mb of ram.