jmke

In the end, only three of the SSDs we looked at today are strong enough to earn TR Recommended distinction. Intel's X25-M remains the all-around performance leader, and even with a higher cost per gigabyte than its rivals, the 80GB model's $325 asking price is relatively affordable.


The Samsung PB22-J and its Corsair twin aren't quite as quick as the X25-M overall, and with these 256GB models running about $700, they're not as affordable. However, a low cost per gigabyte combined with frugal power consumption and solid performance makes these drives easy to recommend

http://techreport.com/articles.x/16848

__________________

jmke

TechReport reporting issues with the Indilinx drives (Vertex/UltraDrive) on their aging Pentium 4 test rig; you can read more about it here: http://www.techreport.com/ja.zz?id=404998

basically the Indilinx under XP with the older ICH don't perform as expected; thus the lower results seen in this review.



yah; wtf

__________________

Kougar

As I remember isn't the first hint their disk test platform was causing performance issues.

Newly released OCZ Summit drives use the identical controller+cache as the Corsair & Samsung Indilinix drives.

jmke

on the other hand, it does paint a nice picture of how some SSDs don't play nice with older systems

__________________

Kougar

XP is a bad choice for SSD's in general, for a myriad of reasons. Anyone using an SSD on it should expect a slight performance hit and other issues.

jmke

I don't agree, any product released today should take into account an OS used by 80% of PCs

__________________

Rutar

I would say it isn't XP but the hardware.

Kougar

I think you misunderstand what I am getting at. The issues and performance hit would be from the OS itself, not the firmware on the drive. The SSD firmware has zero control over:

What sector the OS first writes to (W7 writes to 0 first)
OS handling of I/O requests & queuing (Vista + W7 minimize I/O requests and queues & groups them at the OS level)
OS reduced number of small OS file writes/reads when SSD detected (Vista + W7)
OS will disable caching, prefetching, Superfetch, Readyboost, when detecting a "fast-enough" SSD (W7 disables these along with defrag utilities)
XP won't support TRIM and other upcoming new ATA-commands
XP does not natively support AHCI, few bother setting it up (AHCI is needed for NCQ, PCPR has shown it gives a 2-3x boost in small file writes)
XP is completely hard drive agnostic, it makes no optimizations whatsoever when an SSD is used.

Also real world figures generally place XP around the 61-68% mark, far cry from 80%.

jmke

ok, it's closer to 60% here at the site

-----

I never disagreed with the fact that XP is not optimized for SSD; but that doesn't mean it shouldn't work; if you want to leave 60% of the market untapped...

btw it's possible to tweak XP a lot to improve SSD speed noticeable; but it's far from end-user friendly and requires a proper clean install

__________________

Kougar

Ah, but it DOES work in XP... just not work well. I am not sure how much optimizations they can do since most of it cannot be fixed by firmware. Especially if the OS does not (and may never) recognize the ATA commands and wouldn't recognize an SSD from a laptop hard drive.

As you said, it is indeed possible to heavily tweak XP to slightly optimize it. However, the MSDN article that covers Windows 7 said that not all cache/prefetch, etc disabling is beneficial to those SSDs with problematic controllers, in some instances it makes the situation even worse!

Many "people" suggest moving the pagefile off the SSD, not sure what the point is in having an SSD if they are going to slow their OS back down by having the paging file on a hard disk.

In the end, much simpler and better solution to just upgrade to W7 than to try and optimize a new install of XP and "make it work" as it should, in my opinion. Especially if XP never receives an update to support the TRIM and other ATA commands.