Want to be part of AnandTech Storage Suite 2013? Read this

[bradcollins]

Would you be interested in the trace from 15-30 user terminal servers? I could provide 4 from very different uses at different companies. May not be strictly relevant to a single user, but would almost be like mega tasking - hah? All of them of course don't have the line of business app database on the same server though of course.

 

[Hulk]

I don't see the point in doing tests where SSD performance is not important because it's just added workload for us that serves no real purpose. If SSD performance is not important in the task, then why should we use that task to test every SSD when in fact we would be testing some other component in our system?

We used to have tests like boot time but it becomes irrelevant when all SSDs perform about the same. The drive is no longer the bottleneck so testing it won't be useful because the next SSD won't be any faster at that task.

I'm not sure but I think jwilliams4200 is saying just test it once and if the SSD turns out not to be the bottleneck then fine don't test it again. At least we know that is something not bottlenecked by SSD performance. Is there a way to just time Windows boot to desktop not including post? Because as you wrote post varies greatly from board to board.

 

[jwilliams4200]

I don't see the point in doing tests where SSD performance is not important because it's just added workload for us that serves no real purpose.

If you have not tested it, then how do you know?

If you have tested it, then please link to the test results.

 

[jwilliams4200]

I'm not sure but I think jwilliams4200 is saying just test it once and if the SSD turns out not to be the bottleneck then fine don't test it again. At least we know that is something not bottlenecked by SSD performance. Is there a way to just time Windows boot to desktop not including post? Because as you wrote post varies greatly from board to board.

Well, even if it does not vary much between SSDs, boot speed it is still a worthwhile test. If there are a number of common tasks (that many people do) where the speed of the SSD does not make a difference, then that should be represented in the review testing. At a bare minimum, one of those common tasks should be included in the tests, and preferably more if there are a lot of tasks like that. Otherwise, the review gives the wrong impression about how important SSD performance may be.

I think the boot test should include the POST time, but the review should also specify the approximate time required for the motherboard to finish initializing (easy to measure with a stopwatch), so that it is clear to the readers how much of the boot time is taken up by that process.

 

[Hellhammer]

If you have not tested it, then how do you know?

If you have tested it, then please link to the test results.

Here are some tests: http://www.anandtech.com/show/2738/28

They are old but even back then, the difference between SSDs was rather small in real world tasks even though benchmarks showed major differences (some being much bigger than what we see nowadays).

 

[Hallo32]

removed

 

[jwilliams4200]

Here are some tests: http://www.anandtech.com/show/2738/28

They are old but even back then, the difference between SSDs was rather small in real world tasks even though benchmarks showed major differences (some being much bigger than what we see nowadays).

Those results show that there is a measurable difference between the fastest and slowest SSDs. I certainly would not dismiss it as "small".

I think you drastically underestimate the importance of including realistic tests in the review for common tasks, even if you think there is not much difference between SSDs.

 

[Hallo32]

removed

 

[Ao1]

Here is a comparison between the Anandtech heavy workload average write speed trace results for the Vector, compared against the manufacturers specs for sequential writes speeds and Anandtech sequential write results using AS SSD.

Using IPEAK Service MB/s to analyse trace results is proportionally similar to results using AS SSD. The only significant difference is between the manufactures specs for the Intel 335 and 520 and the AS SSD / Trace results, which seems to confirm that the trace cannot be compressed.

A trace should show how a drive performs with real data, but instead it is showing sequential write performance.

Putting aside the fact that IPEAK alters the I/O when it records it is possible to use IPEAK to analyse performance that is more relevant. Granted that analysis will not show a huge difference in performance between SSD’s, but it is relevant information for the objective of the trace and it’s how Intel recommend to present results for client users, so I’m curious as to why Anandtech do not follow Intel’s recommendation.



Uploaded with ImageShack.us

 

[Ao1]

http://www.computerbase.de/artikel/laufwerke/2012/test-samsung-serie-840-pro-256-gb/6/

Interesting!

 

[jwilliams4200]

@jwilliams4200

http://www.computerbase.de/artikel/laufwerke/2012/test-samsung-serie-840-pro-256-gb/6/

The page itself is in German, but I think you can understand the graphs with the boot time and application start times.

The differents between the SSDs are very low and also depend of the tested application.

I think no one will feel the difference smaller than 1 second.

Which application should AnandTech test?

I don't think it matters very much which specific applications are tested. Just as long as several common ones are included, like in the review you linked to.

 

[jwilliams4200]

A trace should show how a drive performs with real data, but instead it is showing sequential write performance.

That graph shows that the heavy workload trace average write speed is similar to the (incompressible data) sequential write speeds of the SSDs.

But what about the overall trace average speed, and the average read speeds?

I also notice that the gap between red and blue on your graph for the 840 Pro stands out compared to the other SSDs.