Rotor -
I agree the winsxs is full of small file data -
However if you carry out that test using SSD A
Do the same test using SSD B
One turns out faster than the other you cannot deny regardless that performance of drive A is worse than B.
Forget the winsxs test for now as AIDA is serving the purpose of giving us another test to prove HDTune's results.
What do you consider real world performance? It's only real world if you notice it? or have a feeling of slow performance?
Acronis can do a sector copy but I did a file level copy which I think is it's default as cloning a drive is much faster at file level.
Just because the files are small is no excuse for poor performance. Though I know and am aware of what you describe about small files. If you look at people's drives though you are seeing GB's in some cases 10's of GB's of drive space that is showing the 50MB/S performance
Regardless you are forgetting a key fact. If the small files were the cause of the issue. Explain to me why after a secure erase with a cloned copy of the EXACT disk (i.e all the small files are still there and put back) is the drive performing at over 400MB/S across the board where it was previously doing 50MB/S in sections. Acronis image creation has gone from 30mins+ to 10 mins to do exactly the same image?
Sorry mate it doesn't fly. I appreciate that this is a difficult issue to accept when you don't really notice the issue until you look for it but that doesn't mean it's not there.
The issue is real world I think we have proven that but I agree even I didn't "feel" there was a problem when I first encountered it for general drive usage. I did however feel there was a problem when a backup that should take 10 mins suddenly start's taking 30 mins.
Most people who tested and did a secure erase put their data back and are not seeing the poor performance they had before. In my case it was an exact clone. So all the data that was there is back yet performance is fixed so your small file thoery just doesn't stand up, sorry but keep the idea's coming.
I agree the winsxs is full of small file data -
However if you carry out that test using SSD A
Do the same test using SSD B
One turns out faster than the other you cannot deny regardless that performance of drive A is worse than B.
Forget the winsxs test for now as AIDA is serving the purpose of giving us another test to prove HDTune's results.
What do you consider real world performance? It's only real world if you notice it? or have a feeling of slow performance?
Acronis can do a sector copy but I did a file level copy which I think is it's default as cloning a drive is much faster at file level.
Just because the files are small is no excuse for poor performance. Though I know and am aware of what you describe about small files. If you look at people's drives though you are seeing GB's in some cases 10's of GB's of drive space that is showing the 50MB/S performance
Regardless you are forgetting a key fact. If the small files were the cause of the issue. Explain to me why after a secure erase with a cloned copy of the EXACT disk (i.e all the small files are still there and put back) is the drive performing at over 400MB/S across the board where it was previously doing 50MB/S in sections. Acronis image creation has gone from 30mins+ to 10 mins to do exactly the same image?
Sorry mate it doesn't fly. I appreciate that this is a difficult issue to accept when you don't really notice the issue until you look for it but that doesn't mean it's not there.
The issue is real world I think we have proven that but I agree even I didn't "feel" there was a problem when I first encountered it for general drive usage. I did however feel there was a problem when a backup that should take 10 mins suddenly start's taking 30 mins.
Most people who tested and did a secure erase put their data back and are not seeing the poor performance they had before. In my case it was an exact clone. So all the data that was there is back yet performance is fixed so your small file thoery just doesn't stand up, sorry but keep the idea's coming.