Sony Z11 - Long Term SSD Performance - Post your results

Thank you guys for doing all these tests. I have read all of your (extremely long) threads and I feel slightly more confident in buying a Z now...

I wonder if the fact that Linux can see all four drives means you can use a software raid 0 configuration with mdadm and use TRIM from the 2.6.33 kernel...

Also, it seems that in the USA the 192GB configuration is preferable to the 256 if you want speed. I'll try and go for that.

 

So Zoinks, put it into perspective for us. Since you have had both dual and quad ssd now.

Can you compare the dual v. quad in actual use? Does a feel a lot faster, a little faster?

How fast does Windows boot compared to your first one?

 

i can read it in the first page of the thread....

 

It's faster, but nothing Earth-shattering.

I think boot times are a wash because the time required to post with 4 drives vs 2 is definitely longer. Any increases are nullified by this.

The quad processes installs/upgrades faster and moving large files is pure bliss. I haven't installed VMWare yet, but I expect this will be faster as well.

To be honest, I'm not sure an average user, doing normal tasks like email and word processing, would notice much difference between the two. Application launch times are so fast, they are practically instant with either configuration.

I'm sure that games launch faster as well, but I haven't installed any yet.

The 512GB volume is huge for a laptop. I debated long and hard how to carve it up. I ended up giving the OS partition 100GB and set the rest for storage.

 

How did you get your read and write speeds so high.. Yours is way faster than mine on the same machine.

 

-----------------------------------------------------------------------
CrystalDiskMark 3.0 x64 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 572.864 MB/s
Sequential Write : 424.731 MB/s
Random Read 512KB : 429.344 MB/s
Random Write 512KB : 436.618 MB/s
Random Read 4KB (QD=1) : 24.917 MB/s [ 6083.3 IOPS]
Random Write 4KB (QD=1) : 225.851 MB/s [ 55139.4 IOPS]
Random Read 4KB (QD=32) : 236.153 MB/s [ 57654.6 IOPS]
Random Write 4KB (QD=32) : 359.460 MB/s [ 87758.9 IOPS]

Test : 100 MB [C: 8.9% (41.7/467.1 GB)] (x5)
Date : 2010/03/31 17:30:27
OS : Windows 7 Ultimate Edition [6.1 Build 7600] (x64)

 

It's not that different, and your 512k random read is faster than his.

For those of you wondering why the cached writes are so fast, it's because you enabled write-back cache and that basically writes to RAM instead of the SSD. The OS chooses when to update the disk, and that usually happens later, or when the RAM runs out of space.

 

Turn on write cache in the Intel control app

 

yes that was one of the first things I enabled.

 

Dont know what to say then. Changing the volume policy in device manager didn't seem to make a difference but you can try it.

 

its fine.. Im good. I'm happy with the performanc. thanks.

 

In eager anticipation of my Z to arrive Tuesday (hopefully), I made a AutoIt-script to make the SSD testing a bit less tedious. Hopefully it may also make more people test their setups.

AutoIt is a script language able to start programs and then send key presses and mouse clicks to them, and with it, you can do pretty cool things, mostly when it comes to testing.

The attached .zip contains the source .au3 script, and also a compiled version that most people should be able to run without installing AutoIt. It's developed on my old TX1 and on that, it takes ages to run. It's also Windows XP, so some things may not work (as intended) on Windows 7. I'll be able to fix that once my Z arrives, but feel free to fix them before that. I'm sure it's pretty easy to spot any problems and change the script accordingly.

I've installed the test programs according to Zoinks list in the beginning of this thread. Only Atto must be installed as below, the others should be found via the registry.

ATTO Disk Benchmark v 2.41:
Must be installed/unpacked in the Atto\ subdirectory under the TestSSD program.

HD Tach v3.0.4.0
I guess you must set this to "Windows XP (SP3) Compatability mode" to make it work in W7. Not required in XP of course.

HD Tune Pro 4.01
Trial version

CrystalMark v2.2
I guess 3.0 will work with the script as well, haven't tried it though.

CrystalInfo v 3.5.2

When run, the script creates a directory named according to the current date and time. In the directory, all the result files will be placed. Some are pics, some are texts. I tried to extract as much results as possible from each program, but I guess I may have missed some. Particularly from CrystalMarkInfo.

Good luck, I'll go back to anticipation mode and the non working parcel tracking page.


Edit: A little note about AutoIt. Since it sends key presses and mouse clicks to programs, it heavily relies on which program is in focus. So while a script is running, it's not very easy to do other things. Sometimes the script will pause if you take focus, and other times it will interrupt you. The best is to either just watch it (can be rather fun the first 2 times), or go for a swim or something.

 

Now that's what I'm talking about McMagnus. Bravo.

I did some tests yesterday, following some of the steps I did previously and adding some JBOD tests. Unfortunately, showing just how smart I am, I deleted all the screen snapshots so I have a big bag of nothing to share.

Since TRIM is supposed to function with RST 9.6 if the drives are setup as JBOD, I installed Windows 7 cleanly and did this:

• Setup drives 1 & 2 in RAID0
• Setup drives 3 & 4 as JBOD
• Setup drives 3 & 4 in software stripe (Win7)
• Setup drives 3 & 4 in RAID0

Long story short, I wasn't able to slow the drives down for longer than a few reboots. Performance recovered just as I witnessed before.

Now, if we are comfortable saying that TRIM functions on individual drives with RST 9.6, you can, in theory, do this to restore performance to all drives.

• Image system with Ghost or your backup software of choice
• Set all drives in JBOD
• Install Windows7 with the RST 9.6 by selecting the new drivers during setup
• Format all drives with simple volumes
• Run AS Cleaner with FF on all drives. This took about 15 minutes with the 128GB drives, you can do multiple drives simultaneously
• Reconfigure your drives in RAID0, restore your backup

The steps above may be easier if TRIM commands can be sent during Windows 7 setup and after loading the RST 9.6 drivers. I'm not sure on this one.

• Boot to the Windows 7 install media (I do this from a USB drive)
• Select Install Windows, load driver when prompted
• Hit SHIFT+F10 to open a command prompt
• Run diskpart
• Do a "clean all" on each drive

Is all of this necessary? I don't think so, but time will tell.

 

You guys are Awesome.

McMagnus, this is very cool. I will play with your script. Question: Why do you start with a 5 minute wait?

Zoinks. Those results look very promising, with regards to not having to regularly do the whole jbod/re-install thing.

 

As per Zoinks initial test procedure described in the first post of this thread. I think its purpose is to wait for the computer to settle down after reboot. However, if the purpose of the test run is to test the speed immediately after hammering the drives full, then I guess you should bypass the 5 minute wait.

 

Thanks a lot for that test Zoink.
I will just keep my fingers crossed and hope that the lappy does not slow down so much that I decide to hammer it and take timelapses of me doing that
Cheers m8 you are great

 

Wow this is some great work by you guys! Bravo!

 

So basically, nothing should be done right? Just leave and it should recover by itself....self-healing you could say?

 

My tests have shown the above method didn't improve performance dramatically. In fact there's a slight decrease in write speed but probably statistically insignificant. I think the reason why there was no performance gain is because the disk wasn't filled 100% full prior to the FF method.

 

I think that method was intended to restore drive performance if they have been severely degraded. But since nobody have been successful in causing real bad degradation, the method can't really be proved or rejected at this point.

Or were your drives badly degraded already?

 

Not at all You are right on the money thou.

 

I tried backing up my Z with Ghost 15.0 and it didn't even detect my drives. I have them setup in RAID0 with 2 partitions.

Does Windows backup support RAID0 volumes?

 

Received Z today. What's the latest recommendations???

1) Intel RST 9.6 (done)
2) defrag setting??? where is this and what to change?
3) write-back cache enabled (done)
4) Other??

 

I don't have my Vaio Z with me at the moment, but when you go to defragmentation schedule, you should turn off the schedule just to make sure defragmentation never ever happens. Also, make sure you disable all defragmentation on all drives because while it is beneficial to hard drives only. Defragmentation actually shortens the lifespan of the SSD because of the multiple write/erase cycles involved, and you would not like that to happen especially with striped SSDs.

 

Is this done in control panel setting? I couldnt find any deragment software? Could you guild me? thank you

 

The easiest way is just to disable defrag task in the Task Scheduler.

Just type "Task Scheduler" in the start menu's search box.

Then open the folder tree on the left and go to:

- Task Scheduler Library -> Microsoft -> Windows -> Defrag, and then right click on the task in the right pane, and select "Disable" in the popup menu.

That should permanently disable the defrag task.

You can also delete it, if you plan not to use hard drives inside your Vaio.

 

To day i have tried above method and it doesn't help improve perfomance infact after do that write result is worse than before but not much

JBOD After installed windows with intel 9.6 test



Run AS Cleaner FF On all drive


Benchmark after run as cleaner



I run AS Cleaner again then restart, make raid0 volume, install windows with 9.6 floppy drivers and run benchmarked


PS. Something that i found on this test
- Turn on/off Windows write cache buffer flushing on device did not affect benchmark results
- Stripe size 128k yielded best results, on strip size 16k you'll get half of sequencial read/write speed but 4k speed will remain same, on strip size 4k all benchmark very very slow
- When i run all test simulantenous all drive show equal result except the fourth drive. It seem to slow than other(even run it at first so it's not bottleneck problem) but when run it alone it looks fine (may be my hardware defect or cause from sony custom connector???)
- I also enabled advanced bios option and try AHCI mode but windows setup see only 3 hdd and when load intel 9.6 floppy driver it show the raid volume that i didn't delete before switch to AHCI mode how come???

 

I think when you have a quad-SSD config and you go to AHCI, you cannot see the 4th SSD because its the 5th SATA device - ACHI/JBOD supports only 4 sata devices. so you see 3 ssds and one dvd (or HDD if that's what you have). read that somewhere in this forum...

 

fyi... http://www.mydellmini.com/forum/windows-7/2441-windows-7-ultimate-solid-state-drive-speed-tweaks.html

 

I have some interesting findings

I have a quad SSD (64GBx4) setup. Here's what I have done:
1. Deleted the RAID volume and, as a result, 4 non-RAID drives (JBOD).
2. Install Win7 on disk 1 with RST 9.6 loaded.
3. Filled up disk 2 completely with files using dummy file creator.
4. Deleted the files, then deleted the volume.
5. 4k random write test was run on disk 2 using iometer. The average write speed was around 3MB/s.
6. Created a volume on disk 2 and cleaned the disk using AS-cleaner (freespacecleaner) with the FF option enabled.
7. Deleted the volume.
8. 4k random write test was run on disk 2 using iometer. The average write speed was around 1.7MB/s

Can someone can explain to me why the write speed decreased after cleaning? Was TRIM working or not? Did AS-cleaner/writing FF really clean the drive? Other reasons?

TIA

 

Run the tests again.

There is no true speed reclamation method yet, other than time.

 

I will.

What do you mean by the last sentence?

 

Nothing is proven to restore performance on the drives yet. It is all theory.

The drives do recover write performance over time. This could be garbage collection or wear leveling, nobody knows.

 

I made a first attempt to see some degradation yesterday:

For these tests, I mostly used CrystalDiskMark 2.2. I ran the other tests as well as a baseline for later comparison, but not when trying to degrade the drives.

The initial, baseline run said:


Then I filled the drive, 4x64GB in Raid 0. But when it's full, the last file failed to write completely, so it didn't get really full. So the numbers for that run became:



I think another reason why the numbers on that run was rather good is that the drive has enough time to recover while CrystalDiskMark is running the seq and large random tests. By the time it gets to the small random writes, it has already recovered.

After that, I selected a ~10GB directory and removed ~10GB of other files. Then I made a copy of the 10GB directory so that it almost completely filled up the drive. It left just enough so that CrystalDiskMark was able to write its 100MB of data for the test. Then I immediately ran CrystalDiskMark, but only 1 pass of the small random test and got:



About a minute later I ran it again:



A full run a few minutes later again:


So, after a first test, not very unlike Zoink's, but on the other hand not identical either, I can only confirm his suspicion that something is keeping the performance in check, even after it should have been degraded if nothing was done about it.

I'll continue now with some JBOD/Raid combinations and see if I can see other behaviour for those. But the slowness of the recovery process is *killing* me! Any hints? Bootable USB drive? Network boot?

 

I just notice you are using CrystalDiskMark 2.2. I have been using v3 and the results look very different.

@ZoinksS2k
You are right - time heals It seems the SSD controller does have "self-healing" ability.

 

Yes, 3.0 has another test but I'm not sure if the others are comparable. I'll try 3.0 later and compare, but I think it's not really out of beta yet, or is it?

And thanks for yet another confirmation that time heals. Can you re-check the time frame? For me, when filling up the drive with files and running CrystalDiskMark, it recovers in less than a minute.

 

I'm wondering if this recovery to unique to this generation of Z's SSD, or to Sony's SSDs, or to SSDs in general...

 

I think it's related to the Samsung S3C29RBB01-YK40 controller.

 

*Nod*

The Samsung controller has some type of GC. It apparently keys off NTFS, but I'm not sure how that works at a drive-level in a striped volume.

Something is doing the trick, at least for now.

 

Shed some light on GC but still as clear as mud

http://www.ocztechnologyforum.com/forum/showthread.php?65994-Garbage-Collection-(GC)-operation

 

Im curious why is there so little info about this subject and no one seems to know the answers with regards to trim and raid support, GC etc on the new Z or any raid ssd setup.

Is it because of some of the tech being proprietary? I mean Ive already bought my Z love the machine but it just seems strange that SSD as a whole has so many unanswered questions.

You would think after what close to 2 yrs now we still know so little about it. just saying.

 

It is borderline silly. The least they can do is quantify the benefit.

People are aware of the issue enough to be concerned about long term performance. You'd think manufacturers would use their GC as a competitive tactic.

 

I have some, I think new, interesting data to share. I noticed that when copying files to the drives to fill them up, Windows 7 is kind enough to tell me how fast it's copying (if I enable copying details). When I copy that last 10GB directory to completely fill up the last 10 GB of the drive, I see that it copies pretty fast to begin with, but then it slows down until it levels out. At first, I though this was the normal, at-the-end-of-the-disk slowness, but then I tried emptying a drive and then copied that same 10GB dir from another drive, with exactly the same speed in the beginning and then slowly settling for about 28-29MB/s.

If I, when the copying was done, immediately copied the same dir to another location on the same destination drive, it started out a bit faster than the 28-29MB/s, but then quickly settled down at the same rate again.

Instead of copying to a JBOD drive, I made a Raid 0 array out of 2 disks, and this had the intended effect of more or less doubling the rate. This time, it levelled off at about 64MB/s. Then I re-created that raid array but used only 100GB of the 128GB array. This time, the copy rate levelled off at about 95MB/s. When copying my 10GB dir to a raided volume, I had to copy it twice to actually reach the lowest sustained copy rate. After copying the 10GB once, it kept going at ~122MB/s, but if I immediately copied the same dir to another location, it continued from roughly 122 downwards.

So, I don't think the fill rate of these disks matters at all. What matters is the number of raided disks, *and* the amount of slack space it has for the moment. That slack space can be raised by adding disks to a raid 0 array (since each disk has a bit of built-in slack), or by not using all of the array as partitioned space. (Note that you have to limit the raid array size in the Intel RST setup, not in Windows' Disk Management.) The more slack space it has, the more efficient it can do GC and prepare for future writing.

I also have some CrystalDiskMark numbers from these runs, but they only confirm what we already know. That these drives can get pretty slow, but recovers within 1-2 minutes to full speed.

After filling up a JBOD volume, the slowest 4k random read was 0.875, write 1.475. 30 sec later they were 16.35 and 3.941, after 1 minute 16.43 and 8.162, after 2 min 16.51 and 10.54.

The same numbers for a 2x64 raid array were:
0 sec 5.992 5.145
30 sec 12.92 6.916
1 min 16.23 9.920
2 min 17.77 11.70

Note that I have not upgraded the RST drivers yet, nor have I enabled the write back cache. It doesn't matter for the sustained copy rate anyway (I tried), but it would raise the 4k random writes above substantially.

 

I decided to sign up after noticing all the great information on these forums. You guys are awesome. Anyhow, I should add something to this SSD thread that has many of us concerned. To be honest, I was concerned about the issue too until I came across two articles first:

http://www.anandtech.com/show/2829/19

According to Anandtech (a fairly reliable source I believe), the Samsung drives arn't very fast compared to their competitors at random write. This would explain why Sony decided to raid these things. I think Sony also got these drives at a good price at least until you exceed the 256GB mark. If you graph the price difference versus size of the SSD (at least on the Canadian site). I noticed that the price rises linearly, at least until you hit the 256GB mark and then it skyrockets which means you're starting to pay too much past that size.

Anyhow, Anandtech is quick to point out that all Samsung drives past a certain firmware revision will most likely support idle garbage collection. These custom Samsung drives although not really that closely related to the retail drives appear to have a higher firmware version number which would support this theory. The time of the article was Aug 2009 which was well before this laptop existed so you should hope that Sony was still in development with Samsung at the time. In testing, I think most of you have discovered that it seems to work. Another very interesting article is here:

http://www.pcper.com/article.php?aid=766&type=expert&pid=11

If you read carefully it says the drive does two types of background garbage collection:

a) "peeks at the NTFS $bitmap to clear up unallocated areas during idle time"
b) "Samsung units self-defragment on-the-fly during sequential writes"

I'm not sure how (A) would work considering the drives are Raided but I would imagine Samsung would've had to realize that could be a problem considering the Z11's SSDs are being custom built for it so maybe they found a workaround. (B) is very interesting. It would mean in theory that wiping out the entire drive with 0's sequentially would reset it. I also wonder if some of you are doing a sort of partial reset / garbage collection because a part of your benchmark tests are large sequential runs. So what this likely means is that the only way you're going to get these drives to degrade badly is to constantly pound them with random access benchmarks which really only happens on servers.

After reading all this I figured I was comfortable with the Z11's SSDs. I figure about every year or two, I can use BartPE + Acronis Plugin to reimage and wipe out the drives completely. BTW, that combination makes an awesome image / rescue disk setup especially if you custom load the Intel SATA and Network drivers into it. I also found another free tool (SDELETE) which will write zeros to free space which used with BartPE might be useful. I suspect doing that should fix any performance loss if at all.

Oh, I should point out for those of you testing that you shouldn't keep benchmarking your drive for fun. SSDs will burn out as MLC flash is only rated for 10,000 cycles typically. While the SSD will try to spread out the writes, it can't do that forever. Anandtech did however note a downside to this background garbage collection. It will wear out your SSD faster because it needs to rewrite / shuffle data around. Still considering the 256GB drive version I ordered that's 256GB X 10,000 = 2560 TerraBytes. Even if we assume something nasty say 10x write amplification that's still around 256 Terrabytes of data write before your SSD starts to seriously fail.

So I think I've concluded that these drives probably won't suffer massive performance loss but will die many years down the road which is fine because after about 5 years most computers aren't all that useful anymore. Unless of course you're pounding the drives with huge amounts of data or benchmarking them to an early death.

 

So do you guys think foxalopex's solution is the optimal option?

Sounds pretty solid to me.

 

McMagnus, makes sense. I'm still leaving 15% of my total space unpartitioned, forcing some slack space. This is probably excessive, but I can afford it right now.

Nice summary, foxalopex. Welcome aboard.

The information you listed is mostly correct, although we have discussed the Anantech and PCPer articles in other threads. Anantech and PCPer are both reliable, IMO.

I totally agree with the comfort level you have and share it. I'm not worried at all.

However, the process to clear the drives hasn't proved to be a "fix" for long term degradation. It doesn't hurt either.

 

erp, hit post too quickly...

In closing, we need to figure out how to do a full SECURE_DELETE and still need RAID TRIM support.

 

Well said, foxalopex. I agree with your viewpoints.

Regarding point b below, I have been using freespacecleaner to "clean" the SSD. I think it create a file filling the whole disk using the sequential write method.

 

I think in order to do a full SECURE_DELETE the BIOS must be bypassed/modified to unfrozen (security-wise) the SSD.

 

I have managed to bypass the BIOS and run a secure erase on the SSDs.

Here are the baseline CDM benchmarks (Model: VPCZ117GG, 64GBx4, RST 9.6, 3 full passes)