You are not logged in.
Hello. Today, I ran hdparm -t and noticed unusually low performance:
/dev/sdb:
Timing buffered disk reads: 342 MB in 3.00 seconds = 113.85 MB/sec
This is on a Samsung 840 EVO with an FX-8320 4.5ghz. Testing /dev/sda, my mechanical hard drive, gives me nearly identical results, which makes pretty much no sense. I ran this about a week ago, and got numbers around 520 MB.
I am using the BFQ scheduler and the Linux-ck kernel. I tried other IO schedulers, but only gotten worsened performance.
The only thing I can think of that I've changed recently was from the performance to ondemand CPU governor. Could that have caused this?
Any help would be appreciated. I am using UEFI/GPT. uname -a:
Linux msw1 3.13.11-2-ck #1 SMP PREEMPT Fri Apr 25 20:19:47 PDT 2014 x86_64 GNU/Linux
EDIT:
Now solved! It turns out the 840 EVO with its TLC NAND is an odd SSD, and that the alignment needs to be a multiple of 1.5.
Last edited by msw1 (2014-05-01 21:28:31)
Offline
There are several things that can affect SSD performance and one of the most obvious is disk fragmentation and write amplification.
Start with enabling FSTRIM. Also check arch wiki (and google) they have a bunch of advises about SSD performance https://wiki.archlinux.org/index.php/SS … erformance
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
There are several things that can affect SSD performance and one of the most obvious is disk fragmentation and write amplification.
Start with enabling FSTRIM. Also check arch wiki (and google) they have a bunch of advises about SSD performance https://wiki.archlinux.org/index.php/SS … erformance
Thanks for replying.
I was not aware that fragmentation existed with SSDs and ext4.
I have followed that guide. blockdev --getalignoff /dev/sdb returns 0. I have discard set in my fstab. I have also tried running fstrim -v / and fstrim -v /home before running hdparm -t, to no avail.
Last edited by msw1 (2014-05-01 17:42:30)
Offline
It seems to get worse and worse as the computer runs. Upon the start of the computer, it is at around 200MB, which is still much too slow. Now, hdparm -t gives me:
/dev/sdb:
Timing buffered disk reads: 272 MB in 3.02 seconds = 90.19 MB/sec
Offline
I have the same SSD(840 EVO) as you do and i am getting similar results with hdparm -t, although i thought this had something to do with the fact that my SSD is only connected to SATA 2.
Partitions are aligned and manually trimming the partition doesn't seem to change anything.
I noticed there is new firmware update available on Samsung's website(You can boot from a CD with the ISO without having to use Windows), unfortunately i cannot get it to work as the program just crashes.
Using the standard 3.14.1-1 x86-64 kernel with default cfq scheduler
EDIT: It appears i already have the latest firmware installed, still i recommend checking with
hdparm -i /dev/sdX | grep FwRev
and seeing if new firmware is availbe here: http://www.samsung.com/global/business/ … oads.html#
hparm -t results:
/dev/sdc:
Timing buffered disk reads: 368 MB in 3.01 seconds = 122.36 MB/sec
Last edited by supermariolinux (2014-05-01 20:14:58)
Offline
Everything seems normal for me using 3.10 LTS kernel and 840 PRO SSD.
/dev/sda:
Timing buffered disk reads: 1506 MB in 3.00 seconds = 501.56 MB/sec
Offline
I had exactly the same issue with my EVO when it was not aligned to EBS. It's 1536 KiB or 2048 KiB (depending of source), so it's safe to set the sector alignment value to 12288 (6144 KiB), multiple of 1536 KiB and 2048 KiB.
Last edited by gedgon (2014-05-01 20:15:21)
Offline
I have the same SSD(840 EVO) as you do and i am getting similar results with hdparm -t, although i thought this had something to do with the fact that my SSD is only connected to SATA 2.
Partitions are aligned and manually trimming the partition doesn't seem to change anything.
I noticed there is new firmware update available on Samsung's website(You can boot from a CD with the ISO without having to use Windows), unfortunately i cannot get it to work as the program just crashes.
Using the standard 3.14.1-1 x86-64 kernel with default cfq scheduler
EDIT: It appears i already have the latest firmware installed, still i recommend checking with
hdparm -i /dev/sdX | grep FwRev
and seeing if new firmware is availbe here: http://www.samsung.com/global/business/ … oads.html#
hparm -t results:
/dev/sdc: Timing buffered disk reads: 368 MB in 3.01 seconds = 122.36 MB/sec
I do have the latest firmware. As for you, it could be SATA2. I, however, have this connected to a SATA3 controller. As I said, this used to get 500+ easily. Now, it's more like 80.
I had exactly the same issue with my EVO when it was not aligned to EBS. It's 1536 KiB or 2048 KiB (depending of source), so it's safe to set the sector alignment value to 12288 (6144 KiB), multiple of 1536 KiB and 2048 KiB.
I wish this solved it. However, I still get the same result:
sudo blockdev --getalignoff /dev/sdb
0
Offline
I wish this solved it. However, I still get the same result:
Unfortunately, to change partitions alignment, you need to repartition your SSD.
Edit: Please post
sudo fdisk -l /dev/sdX
Where X is your SSD
Last edited by gedgon (2014-05-01 20:42:51)
Offline
i noticed that both
cat /sys/block/sdc/queue/physical_block_size
cat /sys/block/sdc/queue/logical_block_size
report 512, now i believe this SSD supports advanced format 4096 sectors correct? so i guess its possible my disk is formatted with only 512 byte sectors?
or is this not reporting the correct information? I understand i would need to reformat the drive to change this, so when i do how can i be sure its formatted with 4K sectors?
When i first got ths disk i formatted it with GPT and ext4 partitons using gparted
EDIT: here is what fdisk -l /dev/sdc reports for me:
Disk /dev/sdc: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6B11202A-B789-45D9-AC99-FD39FCCA4F51
Device Start End Size Type
/dev/sdc1 2048 6143 2M BIOS boot partition
/dev/sdc2 6144 209721343 100G Microsoft basic data
/dev/sdc3 209721344 243275775 16G Microsoft basic data
/dev/sdc4 243275776 276830207 16G Microsoft basic data
/dev/sdc5 276830208 488396799 100.9G Microsoft basic data
/dev/sdc2 is my Arch partition, the partiton is listed as a Microsoft basic data type, could this relate to any issues?
Last edited by supermariolinux (2014-05-01 20:52:06)
Offline
msw1 wrote:I wish this solved it. However, I still get the same result:
Unfortunately, to change partitions alignment, you need to repartition your SSD.
Edit: Please post
sudo fdisk -l /dev/sdX
Where X is your SSD
It gives me this:
Disk /dev/sdb: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E6A55B73-13E3-48E3-92E9-B9D28143D618
Device Start End Size Type
/dev/sdb1 2048 616447 300M Windows recovery environment
/dev/sdb2 616448 821247 100M EFI System
/dev/sdb3 821248 1083391 128M Microsoft reserved
/dev/sdb4 1083392 235458391 111.8G Microsoft basic data
/dev/sdb5 235458560 264755199 14G Linux filesystem
/dev/sdb6 264755200 487411711 106.2G Linux filesystem
/dev/sdb7 487411712 488396799 481M Linux swap
Offline
Yup, it's aligned to 1MiB.
Offline
Yup, it's aligned to 1MiB.
Is that a bad value? If so, how can I fix it?
I partitioned this drive with gparted.
Offline
Is that a bad value? If so, how can I fix it?
I partitioned this drive with gparted.
For example in gdisk http://cillian.wordpress.com/2013/11/16 … -on-linux/ but like I said it's safer to set the sector alignment value to 12288. Of course, remember to make a full backup first. It's fast and easy with Linux partitions https://wiki.archlinux.org/index.php/Rs … tem_backup , not sure about Windows backup these days.
Offline
msw1 wrote:Is that a bad value? If so, how can I fix it?
I partitioned this drive with gparted.For example in gdisk http://cillian.wordpress.com/2013/11/16 … -on-linux/ but like I said it's safer to set the sector alignment value to 12288. Of course, remember to make a full backup first. It's fast and easy with Linux partitions https://wiki.archlinux.org/index.php/Rs … tem_backup , not sure about Windows backup these days.
Thank you so much! I used gdisk to align it to 12288, and now I get 500MB/s. I was close to reinstalling Arch. Thanks!
Offline
gedgon wrote:msw1 wrote:Is that a bad value? If so, how can I fix it?
I partitioned this drive with gparted.For example in gdisk http://cillian.wordpress.com/2013/11/16 … -on-linux/ but like I said it's safer to set the sector alignment value to 12288. Of course, remember to make a full backup first. It's fast and easy with Linux partitions https://wiki.archlinux.org/index.php/Rs … tem_backup , not sure about Windows backup these days.
Thank you so much! I used gdisk to align it to 12288, and now I get 500MB/s. I was close to reinstalling Arch. Thanks!
Did you need to reformat your disk before doing so?
Offline
msw1 wrote:gedgon wrote:For example in gdisk http://cillian.wordpress.com/2013/11/16 … -on-linux/ but like I said it's safer to set the sector alignment value to 12288. Of course, remember to make a full backup first. It's fast and easy with Linux partitions https://wiki.archlinux.org/index.php/Rs … tem_backup , not sure about Windows backup these days.
Thank you so much! I used gdisk to align it to 12288, and now I get 500MB/s. I was close to reinstalling Arch. Thanks!
Did you need to reformat your disk before doing so?
Nope. I didn't have to do anything really. Gdisk remade my GPT, I rebooted, and it was fixed. No data lost or need to restore from backups or anything.
Offline
supermariolinux wrote:msw1 wrote:Thank you so much! I used gdisk to align it to 12288, and now I get 500MB/s. I was close to reinstalling Arch. Thanks!
Did you need to reformat your disk before doing so?
Nope. I didn't have to do anything really. Gdisk remade my GPT, I rebooted, and it was fixed. No data lost or need to restore from backups or anything.
Nice, anyway thanks for creating this topic, and thanks to gedgon for posting a solution.
Offline
Nope. I didn't have to do anything really. Gdisk remade my GPT, I rebooted, and it was fixed. No data lost or need to restore from backups or anything.
Not sure if it's a proper way ;)
Offline
hmmm well i tried using gdisk but my speeds remain the same, also fdisk reports the same thing as before.
Here is what i did, i put gdisk in expert mode with X, used the L option to change sector alignment value, and entered 12288 as the value, then i wrote the table to the disk with w and rebooted.
but it doesn't appear like anything changed, so i guess i just need to reformat all my partitions?
I know I'm only on SATA 2 but i believe i should be getting values in the 200MB/sec range (SATA 2 max is 3Gbps = 384MB/sec)
Offline
[...]but it doesn't appear like anything changed[...]
Because that shouldn't change anything ;) I've no idea what msw1 did :)
Offline
hmmm well i tried using gdisk but my speeds remain the same, also fdisk reports the same thing as before.
Here is what i did, i put gdisk in expert mode with X, used the L option to change sector alignment value, and entered 12288 as the value, then i wrote the table to the disk with w and rebooted.
but it doesn't appear like anything changed, so i guess i just need to reformat all my partitions?I know I'm only on SATA 2 but i believe i should be getting values in the 200MB/sec range (SATA 2 max is 3Gbps = 384MB/sec)
Well, I did all that, but I also ran n and just did the default to everything.
It said it created a 2MB partition.
I have no idea if that's related, but perhaps that was the solution?
EDIT:
There's a bit more to it than that.
I didn't see gedgon's link at first, and attempted the solution at http://lifehacker.com/5837769/make-sure … erformance
I did the resizing to my first partition along with my Windows partition, but didn't do the step of shrinking the preceding space for my Windows partition. gdisk used the preceding 2MB for whatever it did when I ran n.
I have no idea if the resizing fixed it alone, or if the gdisk was necessary. I guess you'll have to try
Last edited by msw1 (2014-05-02 01:59:57)
Offline
I just want to confirm that this actually made a small difference for me. I didn't really take issue with the speed as it was before, but I came across this thread and figured I would give it a whirl. I have two 250G Samsung 840's one is an evo and one isn't. They are set up in a btrfs raid1. I changed the sector alignment to 6144 since this would work if the TLC were aligned to either 1.5 or 2.0 (as suggest by Rod Smith in this post to the 'ask ubuntu' page).
Before the change, hdparm was reporting ~400MB/s for both disks. After the change, they now both report ~500MB/s.
Interesting...
Offline
I would just like to add that updating the firmware on my EVO drive has changed the speed from 188Mb/s to 324Mb/s.
(Thanks for the hints on this)
This is quite the change. It also reduced 4 seconds of my boot time...
However, I'm sure I can achieve better with the correct partition alignment too...
I'll update this post as soon as I have something else to show for.
Offline
this is mine:
Disk /dev/sda: 167,7 GiB, 180045766656 bytes, 351651888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F05ADD2C-50AD-4C11-9978-FE9555ACFEBE
Dispositivo Start Fine Size Tipo
/dev/sda1 2048 2050047 1000M Windows recovery environment
/dev/sda2 2050048 2582527 260M EFI System
/dev/sda3 2582528 2844671 128M Microsoft reserved
/dev/sda4 2844672 136134809 63,6G Microsoft basic data
/dev/sda5 177758208 178475007 350M Windows recovery environment
/dev/sda6 178475008 178679807 100M EFI System
/dev/sda7 178679808 187072511 4G Linux filesystem
/dev/sda8 187072512 229809824 20,4G Microsoft basic data
/dev/sda9 229809825 306777239 36,7G Microsoft basic data
/dev/sda10 306778112 336971775 14,4G Windows recovery environment
/dev/sda11 336971776 351651839 7G Intel Fast Flash
/dev/sda12 136134810 177758207 19,9G Microsoft basic data
Last edited by tano70 (2014-06-28 06:35:07)
Offline