Out of the ballpark!! Benchmarking vertex 120g on Linux and Windows!

[devsk]

So, I bought the vertex 120G and paid a huge amount of money for it. Now, I needed to justify the buy, right? So, I ran the benchmarks...

Man! Talk of myths! My system is nearly 3.5 to 4 years old, but it was the king at the time it was built. All the components were of top notch quality at that time but still I was wary. So, it was my 4 year old mobo trying to match the latest kid on the block. And boy, did it make the vertex sweat, and then some...:-) Let's say 204MB/s seq writes and 272MB/s seq reads from a single vertex. Old kid pushing the new kid beyond its limits. Is my vertex on crack? 1199 firmware and partition alignment are the only two optimizations applied.

This is on-board sata controller on a nForce4 mobo called Abit AN8 SLI, with drivers from 2007. Neither the board nor the company exists anymore.

More comprehensive benchmarks, including the ones on linux, are coming soon.

PS: One thing is clear from the benchmarks - the write combining is working great!

EDIT: More benchmarks

IOZONE:

        O_DIRECT feature enabled
        Auto Mode
        File size set to 262144 KB
        Record Size 4 KB
        Record Size 64 KB
        Record Size 512 KB
        Command line used: iozone -I -a -s 256M -r 4k -r 64k -r 512k -i 0 -i 1 -i 2
        Output is in Kbytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                            random  random    bkwd   record   stride
              KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
          262144       4   40758   47147    43267    43255   23598   18345
          262144      64  159861  159879   207611   199224  117750   94226
          262144     512  217155  213906   255246   254838  216214  204157

iozone test complete.

real    1m8.870s
user    0m0.143s
sys     0m20.615s

5:24:14 root@localhost /sys/block/sdb/queue
# echo noop > scheduler
          262144       4   41757   47770    43577    43694   23525   18166
          262144      64  168125  160186   208385   208268  123958   93568
          262144     512  215540  213376   253598   253476  214176  205643
real    1m8.549s
user    0m0.137s
sys     0m18.975s

Note the DIRECT mode, meaning kernel FS cache is bypassed. Note how vertex can write random 512KB blocks at 205MB/s and read them at random at 214Mb/s. Sequential reads, writes and rewrites are all beyond 200MB/s. random 4k read/writes agree with what crystal mark returns inside windows.

DD Tests:

15:19:12 root@localhost /mnt/floppy
# \rm tempfile ;sync;time dd if=/dev/zero of=tempfile count=15000 bs=128k oflag=direct
15000+0 records in
15000+0 records out
1966080000 bytes (2.0 GB) copied, 11.2002 s, 176 MB/s

real    0m11.202s
user    0m0.007s
sys     0m1.267s

15:20:22 root@localhost /mnt/floppy
# echo 3 > /proc/sys/vm/drop_caches ;time dd of=/dev/null if=tempfile count=15000 bs=128k
15000+0 records in
15000+0 records out
1966080000 bytes (2.0 GB) copied, 8.55016 s, 230 MB/s

real    0m8.637s
user    0m0.013s
sys     0m1.430s

Again, note the DIRECT mode, meaning kernel FS cache is bypassed. That's sustained seq writes of 170+MB/s.

Bonnie: This is where things got interesting. Note how one benchmark differed in write speed from the first. Bonnie creates a large 8G file to do its tests. The second run onwards, wear levelling kicks in and reduces writes.

On root partition with noop scheduler:
Version  1.95       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
vrtxonboard      8G   498  99 158887  31 70732  14  1797  98 192184  22  3715  58
Latency             21877us     509ms     142ms   17082us   16882us    6556us
Version  1.95       ------Sequential Create------ --------Random Create--------
vrtxonboard         -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 28697  68 +++++ +++ +++++ +++ 25069  59 +++++ +++ +++++ +++
Latency              3609us     108us     833us   72381us    1204us    5227us
1.93c,1.95,vrtxonboard,1,1237266943,8G,,498,99,158887,31,70732,14,1797,98,192184,22,3715,58,16,,,,,28697,68,+++++,+++,+++++,+++,25069,59,+++++,+++,+++++,+++,21877us,509ms,142ms,17082us,16882us,6556us,3609us,108us,833us,72381us,1204us,5227us

real    3m50.327s
user    0m1.317s
sys     0m53.267s

echo 256 > queue/nr_requests and echo 65536 > queue/read_ahead_kb

Version  1.95       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
vrtxonboard      8G   445  98 139034  30 84383  17  1314  88 235350  30  3653  54
Latency             23594us    1041ms    1414ms   87231us     523ms   10666us
Version  1.95       ------Sequential Create------ --------Random Create--------
vrtxonboard         -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 27870  69 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency              1115us     108us     169us    6139us    9751us    5852us
1.93c,1.95,vrtxonboard,1,1237270140,8G,,445,98,139034,30,84383,17,1314,88,235350,30,3653,54,16,,,,,27870,69,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,23594us,1041ms,1414ms,87231us,523ms,10666us,1115us,108us,169us,6139us,9751us,5852us

real    3m31.965s
user    0m1.210s
sys     0m57.016s

First ATTO run with NTFS and 64kb block size. This is the 64KB block size that pushed vertex beyond its limits.
http://www.ocztechnologyforum.com/fo...1&d=1237262819

Second ATTO run with NTFS and default 4KB block size. It performs to the spec.
http://www.ocztechnologyforum.com/fo...1&d=1237262962

Third ATTO run with FAT32:
http://www.ocztechnologyforum.com/fo...1&d=1237262962

Crystal mark:
http://www.ocztechnologyforum.com/fo...1&d=1237262962

HDTune read:
http://www.ocztechnologyforum.com/fo...1&d=1237262962

Can't upload anymore PNGs. But IOMeter test was as expected. About 2500IOPs, with 10MB/s transfer rate, 0.4ms avg access time, 10ms max access time.

[rhys]

So, I bought the vertex 120G and paid a huge amount of money for it. Now, I needed to justify the buy, right? So, I ran the benchmarks...

Man! Talk of myths! My system is nearly 3.5 to 4 years old, but it was the king at the time it was built. All the components were of top notch quality at that time but still I was wary. So, it was my 4 year old mobo trying to match the latest kid on the block. And boy, did it make the vertex sweat, and then some...:-) Let's say 204MB/s seq writes and 272MB/s seq reads from a single vertex. Old kid pushing the new kid beyond its limits. Is my vertex on crack? 1199 firmware and partition alignment are the only two optimizations applied.

This is on-board sata controller on a nForce4 mobo called Abit AN8 SLI, with drivers from 2007. Neither the board nor the company exists anymore.

More comprehensive benchmarks, including the ones on linux, are coming soon.

PS: One thing is clear from the benchmarks - the write combining is working great!

You haven't used Red Bull in a water cooling loop have you?

[HDCHOPPER]

exellent ! and on nforce too

going to have to dig out my old A8V Deluxe

[RDubus]

Wonderful, and quite surprising actually! But hey, If it ain't broke,.........ya know. You might post the exact chipset driver version your using, might help others with nf4 boards. Good job!

[LeJimster]

Hey, I used to have a nforce4 board. They were the best at the time, but I'm REALLY suprised by those results! Bet that drive has made your PC feel like a whole new animal again.

[devsk]

Wonderful, and quite surprising actually! But hey, If it ain't broke,.........ya know. You might post the exact chipset driver version your using, might help others with nf4 boards. Good job!

Will do once I get back into windows. I am in linux, my main OS, at this time.

EDIT: Since all my downloads are in a shaed location between linux and windows, I found the driver version that I am using: its 6.86.

-rwxrwxr-x 1 root portage 45268256 Dec  3  2006 6.86_nforce_win2kxp_international_whql.exe

[Sung Young Gui]

I am really ignorant with a lot of this stuff, but I was reading an article about another SSD drive that seemed to show maximum spec performance on systems with a 3 year old MB and reduced in performance by at least 20% when switched to the absolute latest and greatest i7 setup.
After running extensive tests, they discovered that the culpret was the newer systems power saving features; That, and something else that I think was even more a contribution. The article actually narrowed it down to about 3 or 4 settings that made all the difference.
I will try and find the article if anyone thinks it may be a factor that could give many of us even more performance from these drives. If devsk can get it, it must be available!

[Sung Young Gui]

Found it:
Regarding the above suspicion, here are a couple of quotes:

"We found that the sophisticated power saving mechanisms—such as the Active State Power Management for PCI Express, or the deeper C states that switch off entire functional units within the CPU at a transistor level—have a noticeable impact on the performance"

"The conventional power saving techniques, such as Enhanced SpeedStep—which reduces clock speed and voltage during idle or low load periods—showed the least impact."

I will post the link to the whole article if I am allowed to.
So does anyone think this could be a factor as to how devsk is getting this amazing result?

[m.oreilly]

i would love to see the info/link.

[Sung Young Gui]

There you go

http://www.tomshardware.com/reviews/...ower,2170.html

[m.oreilly]

thank you

[bjd223]

Wow this sucks. My motherboard has the most sophisticated energy savings setup ever, and it can't be disabled.

"Enables the Most Energy Efficient Motherboard in the World
The ASUS EPU utilizes innovative technology to digitally monitor and finetune the CPU power supply with improved VR responses in heavy or light loadings. Working together with AI Gear 3, it automatically provides power for higher performance or improves efficiency by 50% when the PC is running low intensity applications - helping you attain the best possible power efficiency and energy savings of up to 80.23% to help save the environment."

I guess ASUS boards aren't the greatest for SSD performance.

[devsk]

Has anyone tried the 64kb block size while formatting their NTFS partition? The OCZ folks don't know this (is it their drive? I wonder....) but the write combining is working better with larger block sizes for obvious reasons and taking vertex beyond its specs. If we were to go by benchmarks alone, OCZ can easily claim my first benchmark with 64kb block size because its definitely doable for a normal setup. Yeah, you waste space for files smaller than 64kb, but you get higher throughput. In fact, unless you are doing block based forced 4kb random writes (like the benchmarks), your small file random writes are getting converted into larger 64kb random writes, which are definitely and immensely faster than 4kb random writes. Note that with 64kb block size, your crystal mark 4kb random read/write numbers will not improve because not creating files of 4kb size but doing block based IO of size 4kb. If it were to create files of 4kb size (which will result in a file of size 64kb on disk) randomly, you will see a huge number with 64kb block size.

So, unless and until you really want to save that extra 1GB of storage on your typical install, using 64kb block size makes a perfect performance sense because it converts your smaller random files read/write into larger read/write. Try booting a winxp install with 64kb block size against an install with 4kb block size if you don't believe me. I would add this to the sticky if I was Tony because this can single handedly help remove stutter in all OCZ drives, if customers are ready to take hit on space.

[devsk]

I also ran the vertex on the Perc RAID card and found that its read performance goes down, whether I enable readahead or not. This goes well what I had already researched before. Vertex works best on-board sata headers.

[Sung Young Gui]

Wow this sucks. My motherboard has the most sophisticated energy savings setup ever, and it can't be disabled.

"Enables the Most Energy Efficient Motherboard in the World
The ASUS EPU utilizes innovative technology to digitally monitor and finetune the CPU power supply with improved VR responses in heavy or light loadings. Working together with AI Gear 3, it automatically provides power for higher performance or improves efficiency by 50% when the PC is running low intensity applications - helping you attain the best possible power efficiency and energy savings of up to 80.23% to help save the environment."

I guess ASUS boards aren't the greatest for SSD performance.

You probably have the same board as me; P5Q3 deluxe...? dang tree huggers