You are not logged in.

#1 2011-08-19 05:59:49

KLIM
Member
Registered: 2010-11-18
Posts: 33

Ridiculous performance SSD

Hello guys,

Yesterday I got my new SSD drive up and running Arch 64bit. I were all excited to try out my new system and get some better performance. I quickly got pretty disappointed though.
I bought a OCZ Vertex2 60 GB, which according to case it came in has Read: Up to 285 MB/s and Write: Up to 275 MB/s.
This is not quite the result I'm getting. This is the average read speeds, and with the --direct option it's 10 MB/s higher. Still pretty far away from the manufacturers speeds.

[root@klim-desktop klim]# hdparm -Tt /dev/sdc

/dev/sdc:
 Timing cached reads:   20582 MB in  2.00 seconds = 10305.50 MB/sec
 Timing buffered disk reads: 420 MB in  3.01 seconds = 139.40 MB/sec

I think I've done anything right under the installation. I partitioned with gdisk (GPT)

[root@klim-desktop klim]# gdisk -l /dev/sdc
GPT fdisk (gdisk) version 0.7.2

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 117231408 sectors, 55.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 42DD6909-D9AC-485C-A11F-14A6F43C3054
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 117231374
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            4095   1024.0 KiB  EF02  BIOS boot partition
   2            4096          208895   100.0 MiB   8300  Linux filesystem
   3          208896       117231374   55.8 GiB    8300  Linux filesystem

Here is my fstab

[root@klim-desktop klim]# cat /etc/fstab
# 
# /etc/fstab: static file system information
#
# <file system>        <dir>         <type>    <options>          <dump> <pass>
devpts                 /dev/pts      devpts    defaults            0      0
shm                    /dev/shm      tmpfs     nodev,nosuid        0      0
none		       /tmp	     tmpfs     nodev,nosuid,noatime,size=1000M,mode=1777	00
# DEVICE DETAILS: /dev/sdc2 UUID=acf53ee3-6b90-4285-aa81-b4d5da5f3ef6 LABEL=bootssd
# DEVICE DETAILS: /dev/sdc3 UUID=2002e224-ca47-446e-a81a-65398e896d9e LABEL=rootssd
UUID=2002e224-ca47-446e-a81a-65398e896d9e / ext4 defaults,noatime,discard 0 1
UUID=acf53ee3-6b90-4285-aa81-b4d5da5f3ef6 /boot ext2 defaults,noatime,discard 0 1

#500 GB
/dev/disk/by-uuid/9979365EFA924345 /media/500GB ntfs-3g umask=000,users,noatime,uid=klim,gid=users 0 0

#HDD
/dev/disk/by-uuid/10de0bc9-2f9e-4ba6-9945-8e3d4abdefac /var ext4 defaults,relatime 0 1
[root@klim-desktop klim]# cat /sys/block/sdc/queue/scheduler
[noop] deadline cfq 

The only thing I could think of, that maybe could slow down the performance is, I came from a 32 bit system, and installed 64bit. To keep my settings, I copied /etc (without rc.conf, pacman.d, pacman.conf, fstab) and my /home/klim directory from my old system to my new system. Could this really have effect on my performance on my SSD?

Offline

#2 2011-08-19 12:14:17

kulpae
Member
From: Bremen
Registered: 2010-02-06
Posts: 34

Re: Ridiculous performance SSD

what interface is it connected with? SATA1 or maybe SATA3?
S-ATA has these ideal speed limits:
SATA1: 1,5 Gbit/s = 188 MB/s
SATA1: 3 Gbit/s = 375 MB/s
SATA1: 6 Gbit/s = 750 MB/s
in practice the values are often lower...

The speeds from the manufacturer refer to SATA2, so if you have SATA 1 then you've found the bottleneck.
There are many other factors, which can decrease the benchmark results, but in practice they are not relevant.

How do you feel about the speed of the ssd? is it fast enough for you (do programs start fast enough?, does you system boot fast enough?)
I've Intel SSD 510 with Marvell Controller. My arch boots in 10 seconds + 3 sec for slim password input + 4 sec XFCE loading = after 17 sec my system is ready for usage.
I'm pretty happy with it, though it never reaches the speed values of the manufacturer, as I've connected it through SATA2 (on my thinkpad), not SATA3 which it supports...

With the help of Arch wiki I tested my ssd, here are the results:

hdparm (average of 5 calls):
Timing cached reads: 3827.3 MB/sec [min: 2922.39, max: 4092.49]
Timing buffered disk reads: 197.6 MB/sec [min:194.64 max: 200.64]

write: dd if=/dev/zero of=tmpfile bs=1M count=1024 conv=fdatasync,notrunc
137 MB/s

read (unbuffered): dd if=tmpfile of=/dev/null bs=1M count=1024
222 MB/s

read (buffered): dd if=tmpfile of=/dev/null bs=1M count=1024
3.1 GB/s

---

these are the values from the manufacturer:
seq. read: [sata2] 265 MB/s, [sata3] 450 MB/s
seq. write: [sata2] 200 MB/s [sata3] 210 MB/s

so my benchmarks doen't reach the manufacturer values as well, but it's fast enough for me wink

cheers, kulpae

Offline

#3 2011-08-19 14:10:05

steve___
Member
Registered: 2008-02-24
Posts: 452

Re: Ridiculous performance SSD

Make sure the HDD controller is in AHCI mode (vs IDE mode, I believe it is).  Sometimes this can be set in the BIOS.

$ lspci |grep AHCI
00:1f.2 SATA controller: Intel Corporation 6 Series Chipset Family 6 port SATA AHCI Controller (rev 04)

Last edited by steve___ (2011-08-19 14:10:32)

Offline

#4 2011-08-19 14:44:00

KLIM
Member
Registered: 2010-11-18
Posts: 33

Re: Ridiculous performance SSD

Thanks for the replies!

@kulpae
I am pretty sure my motherboard supports SATA 2, I have a P5Q-Deluxe and the tech specs says it does. Though I'm a bit curious if the ports I connected it to does, and have some limits. Since my other SATA 2 ports are filled, I choosed the orange ones seen here http://www.overclockersclub.com/reviews … luxe/3.htm (scroll a bit down)
It says:

The two orange SATA ports are for use with the Drive Expert utility, and only function in this capacity as data-only drives. 

Do you think I should try swapping it with one of the other cables in the red ports? and how would this effect my system, would the UUID or something else be changed then?

EDIT:
okay, I've done some searching. Looks like the orange ports (Drive Expert) are for RAID drives, but can be used for single drives aswell. Though many people complaining that the Silicon Image onboard raid controller which control the Drive Expert ports are slower than the others controled by the ICH10R. I'll try to swap the cables around and see if that do anything.

@steve__
I have already turned on AHCI

$ lspci | grep AHCI
00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller

It seems now I can't get the TRIM to work aswell, even with the discard option in fstab sad ......

Last edited by KLIM (2011-08-19 14:58:39)

Offline

#5 2011-08-19 15:03:15

steve___
Member
Registered: 2008-02-24
Posts: 452

Re: Ridiculous performance SSD

re: trim - make sure the drive supports trim.

$ hdparm -I /dev/sda |grep trim
           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read ZEROs after TRIM

Offline

#6 2011-08-19 15:12:58

KLIM
Member
Registered: 2010-11-18
Posts: 33

Re: Ridiculous performance SSD

Changing the cable to another SATA 2 port seemed to give it a bit boost!
Pretty strange, since the other ports are ment for RAID drives and got super speed option. Well..

# hdparm -Tt /dev/sde

/dev/sde:
 Timing cached reads:   21368 MB in  2.00 seconds = 10700.16 MB/sec
 Timing buffered disk reads: 632 MB in  3.00 seconds = 210.33 MB/sec

@steve__
According to hdparm it supports TRIM. Though it says (limit 1 block). Your says 8 blocks, what does that mean?

# hdparm -I /dev/sde 
 *	Data Set Management TRIM supported (limit 1 block)
 *	Deterministic read data after TRIM

Offline

#7 2011-08-19 15:35:12

KLIM
Member
Registered: 2010-11-18
Posts: 33

Re: Ridiculous performance SSD

Hmm, TRIM might work. It does take a while though like 5 mins, could that be right?

What I did was following:

[root@klim-desktop ~]# dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct 
100+0 records in
100+0 records out
52428800 bytes (52 MB) copied, 4,87092 s, 10,8 MB/s
[root@klim-desktop ~]# hdparm --fibmap tempfile

tempfile:
 filesystem blocksize 4096, begins at LBA 208896; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0     744448     746495       2048
     1048576     733184     739327       6144
     4194304     856064     864255       8192
     8388608    6713344    6729727      16384
    16777216    6746112    6762495      16384
    25165824    6778880    6832127      53248
[root@klim-desktop ~]# hdparm --read-sector 744448 /dev/sde

/dev/sde:
reading sector 744448: succeeded
c8a1 b24b da7c 50c2 7ab2 6135 ea78 76e4
2812 42f4 679e c4b7 9610 e73b 1763 122c
049a c520 8370 e025 3a89 e02e 326a 531f
a2ca 3299 8ff8 7dab 8422 1a59 f483 0bd8
6894 3b5c f2d9 a023 acd5 2eec f7a4 9b90
b45c 4f4e 1720 e43d 261e 321a d45d f210
99f5 63cf 0484 ef0a 8755 a4f4 74e0 bfe1
3b49 a476 c5b0 1071 5847 08fd 493f 19d5
7222 2105 8fe1 b536 cdcf 162c 1ec5 8cb6
2e22 36d1 7f9c aa9e 2853 4355 b371 065a
0f93 a1e4 716f 7474 c981 c98a ac04 6743
d8f5 2ff7 a255 8b06 eb08 9f99 0d58 b847
1167 c457 2a96 45ed 3943 cb99 a132 7b3c
4711 27b9 7d2f 0c97 7ffe b1a2 77ee dd28
c47a 7780 f17d 3553 7ba1 1742 9b98 f807
3cf6 7943 4771 4253 c349 1584 46d0 adde
019b 8f40 be04 b3f5 b8ea 2644 9bc3 baec
3a79 153d baea f17a cb72 5fa8 99af 73b8
3c28 bbd2 5e51 765d 47b7 8d26 45c2 e0a6
1295 1f2c c111 cb73 0610 e363 a09f 99b1
7864 9359 3b8d 8efa 9df0 a264 3a57 f1a4
93a6 626b 4b81 0f26 ebde e8e7 c682 34f2
feec 56c6 335c 7732 5a66 f96b e2f3 db45
cda3 abeb 2304 7b1e 99ba 6de9 722d 74ba
61b9 ef30 fe2a ac02 95e6 64df 3f2f 072e
d0e7 24cb 666c 8424 b22d 3b25 1810 4d50
4ec2 c4eb c7d9 f806 bfdf f9d8 32c0 805d
a40e 95b9 58e4 b7b1 ad88 b61d 65fc 6ea4
400e f103 fd9e 8f70 6de6 4f3a 95b3 3f90
600a 1566 7139 9b4a e10d 3c78 4c00 2a15
7fd2 2312 351e 6622 3440 bfe8 4846 ca7f
eaa7 85be 9824 b005 5b91 cac0 567c b437
[root@klim-desktop ~]# rm tempfile
[root@klim-desktop ~]# sync

After like 5 mins:

[root@klim-desktop ~]# hdparm --read-sector 744448 /dev/sde

/dev/sde:
reading sector 744448: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000

Offline

#8 2011-08-19 18:44:54

KLIM
Member
Registered: 2010-11-18
Posts: 33

Re: Ridiculous performance SSD

Well, looks like the TRIM support was only temporary ????

I tested it once again, and even after an hour still got the same output

[root@klim-desktop klim]# hdparm --read-sector 528384 /dev/sdd

/dev/sdd:
reading sector 528384: succeeded
699e 18fc 4926 20f3 36cc 2400 4ab1 2244
0609 6b63 a85b 02bf 1d8f 00f9 27c4 7fa0
aa78 4b1d 606e 66ff b9fe 0f2e 3eea 85fe
6654 87b7 288c df7a 22de 7003 dd01 dd52
bc4f 07fe 1420 3b66 c4e2 c750 0ef3 896a
7ab7 d567 9032 6144 2a49 1bf4 c672 30a2
2363 da8f 6ab5 5dda fa5c 7be0 5009 9364
22cf 2e77 3f55 d967 e739 93bd c027 0a4e
740a 7ada 73ae 46ad 64a9 b790 2352 be12
aa05 1c93 e7e9 cef3 d0e9 0bea 5ee0 0666
5360 1e7b 18f7 4ecf 5ed3 5e20 99e9 b895
9130 a387 e029 4152 4996 4ce9 587c 4c06
2759 1011 74e7 2287 a1c6 d454 2cba 2c13
9be1 752f 13bd 2bbe 1bcb 256c a020 b018
b11f e77e 80a6 e400 d2de 9ee1 f131 fd03
fc1a 8827 2ef9 b922 6bc8 a543 e802 f845
a6ab 14e3 49e6 8ca0 fbd0 0091 56af a1b7
20b2 e2a3 0103 c1cb 8181 f4d4 446d e273
7317 4642 38fd 2e4e cdd9 0dc1 992b 1a27
cbe5 af83 c872 d41b 01c6 5d1c 9782 340e
cac9 3122 d4ea 1583 8535 d443 31b7 2a09
6122 db61 93f1 d74b ca3c bd0c 840b 293c
58ef af19 961d 2d4e 59c1 d9b1 e9b7 960b
c8da faba 7d22 b0cf ee8f e942 7447 44ac
2c17 c4a9 096e 08db c323 96dd c52b 5469
d0be 6aad 0b68 510b 65fe 6f37 6aa2 fb85
c063 8c92 0cd8 6270 b7b2 dc2e 77fc 8c7d
17d0 7f4d b36e d041 243d 7a15 8997 2851
cde9 33b9 86cd 51cc 0188 eb19 eb84 64a4
5f58 8214 e97d 5b4c 35b8 2094 3ce0 ac9d
9a42 59bc a64f 7991 b832 7a35 ce2a fca9
aee6 828f 64ff a19d 56c2 f435 1842 01f3

Just noticed that my hdparm output says:

 *	Deterministic read data after TRIM

Which means it doesn't turn them in to ZERO's like your does. How could this be?

Last edited by KLIM (2011-08-19 19:02:32)

Offline

#9 2011-09-12 00:40:51

dl.zerocool
Member
Registered: 2011-02-04
Posts: 8

Re: Ridiculous performance SSD

Just to let you know guys that sync takes time (well you don't see it but it doesn't take effect immediately)
I found it somewhere in the arch forum, but don't remember the post.

sudo dd if=/dev/urandom of=tmpfile bs=1M count=10 && sync
sudo hdparm --fibmap tmpfile
sudo rm tmpfile && sync && sleep 120
sudo hdparm --read-sector zzzzzzzz /dev/sdX

Where z is somewhere between the "begin_LBA and the end_LBS"  << Take a random number more or less in the midle,
and where X is your drive letter.

I was thinking that Trim didn't work first because I didn't let enough time after the sync. So it was not full of zeros.

Last edited by dl.zerocool (2011-09-12 00:41:51)

Offline

Board footer

Powered by FluxBB