Testing the Intel X25-M 80 GB Postville’s performance on the 8371

Encouraged by a comment on my previous post about my Acer TravelMate TimeLine notebook, I have benchmarked my Intel X25-M 80 GB Postville solid state drive using IOzone. My results are as follows:

Iozone: Performance Test of File I/O
        Version $Revision: 3.308 $
        Compiled for 64 bit mode.
        Build: linux

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
    KB  reclen   write rewrite    read    reread    read   write
262144       4   38211   42784    46048    45918    8684   37782
262144      64   69923   77192   115359   113808   91553   74527
262144     512   77909   60055   220997   221988  204858   77677

Through Google I found comparable benchmarks. This one was posted on the Ubuntu Forums. It should be noted that this is a 160 GB X25-M, the poster mentions that his one is a ‘G2’ which means that it’s a second generation one with the Postville code name like mine. Probably the greater amount of storage would have some benefit for performance, but I’m not sure. These numbers are taken from the benchmark without TRIM. If I understand correctly it doesn’t matter if you use an X25-M with the latest firmware which supports TRIM (like I do), because there is no support for it in Linux/Ubuntu yet and it looks like it won’t be in the next Ubuntu release either. With Google or in that topic you can find an explanation on how you could use a recent version of hdparm and some kind of trick to use TRIM, so that’s how that poster probably got his follow-up benchmarks with TRIM. I didn’t bother because I think I’d rather wait until the support for TRIM is mature enough for it to work out of the box. The poster used an HP Elitebook 8530p with an Intel Core 2 Duo T9400 CPU and 4GB DDR2-800 RAM.

                                                  random  random
    KB  reclen   write rewrite    read    reread    read   write
262144       4   55854   61601    77975    77408   18740   37199
262144      64  102575   87223   200613   201029  141870   70205
262144     512  110951   93840   244588   242498  233184   95013

I found a second post with benchmarks on another forum, but unfortunately no more than that. In the specific post I just linked it’s not mentioned, but in an earlier post in the same topic the poster gives the model number of his SSD, INTEL SSDSA2M080G2GC, which means he has the same model I have. He posted his benchmarks at 5 December mentioning that it they were made with the most recent firmware. If I recall correctly, that’s still the latest firmware at this moment. So he’s using the same firmware as I am, the first firmware to include support for TRIM. Not sure what system was exactly used for the benchmark, but the poster mentions it’s a notebook. I’ve asked him and I’m waiting for a response.

                                                  random  random
    KB  reclen   write rewrite    read    reread    read   write
262144       4   39360   46785    53897    51421   11412   39529
262144      64   71098   54363   130520   129911   98805   74485
262144     512   81657   78925   207837   210842  218651   81242

So which conclusions can be drawn from this? No definitive. I should also take into account I’m using the EXT4 filesystem on my X25-M in combination with an alpha version of Kubuntu 10.04, which uses the 2.6.32 kernel. Benchmarks done by Phoronix show that with this and other recent kernels EXT4 suffers from performance regressions. The numbers presented by the benchmarks done by the poster  on the Ubuntu Forums leave my X25-M in the dust, but comparing to the last benchmarks doesn’t give such a dramatic difference. The greatest difference can be found in the benchmark with the 4KB blocks (first row). If anyone has a better interpretation of these benchmarks and the context to offer, please comment.

Edit 12 February 2010: the following results were achieved with the ext3 file system, using the noatime option. Contrary to my expectations it’s not better, but sucks more.

                                                  random  random
    KB  reclen   write rewrite    read    reread    read   write
262144       4   45452   42928    43576    43587    9120   40782
262144      64   59020   73224   109954   108622   90028   74706
262144     512   81555   82546   172479   171934  174380   82114

Leave a Reply

Your email address will not be published. Required fields are marked *