New SSD is very slow under Xubuntu 14.04

Question

I got myself a Transcend 64GB SSD (model number: TS64GSSD340).

I put the SSD into a tiny netbook I have. Netbook specs are:

• Make/Model: Acer V5-123
• CPU: AMD E1-2100 with Radeon HD 8210
• RAM: (came with 4GB, but, I upgraded to 8GB because I put /tmp into tmpfs)

This netbook came with Windows 8.1, but, I removed that entire HDD and put the Transcend 64GB SSD in its place. Then, I installed Xubuntu 14.04 onto the SSD.

Firmware info for the Transcend SSD is as follows:

$ sudo hdparm -I /dev/sda | grep -i firmware
    Firmware Revision: SVN263

I checked online and couldn't find any (new/updated) firmware files for this drive.

Based on various notes found all over the web, I have done the following ssd optimizations:

• Left about 4GB of unused + unallocated space on the drive at the time of creating partitions (i.e., at the time of installation)
• Added noatime for / to the fstab
• Added "fstrim -V /" to rc.local and yes, my rc.local is always executable because I have a bunch of other things i do in it
• Removed the fstrim from cron weekly
• Made sure that the ff cache is 0

Now, the real issue is that the drive is DEAD SLOW. I mean, booting up takes over a minute. Starting firefox, terminal, gedit, etc, take a lot of time. (Before you jump onto me ... yes, I did install a lot of software, including my favorite editor gedit, onto this system).

My only point of comparison at this point is time is my other notebook (fujitsu, core i3, 8GB, 500 GB magnetic HDD) running Xubuntu 13.10. That notebook boots up in under a minute, possibly in half a minute! But, this SSD netbook running Xubuntu 14.04 neither boots up quickly nor does it start apps quickly. Clearly, my assumption that an SSD will speed up things was wrong!!??

Additional info: Xubuntu kernel is 3.13.0-30-generic (64 bit).


Update # 1
I did two tests mentioned in the Arch wiki SSD Benchmarking page, as suggested by @Tuknutx. Each test was done four times:

1. "sudo hdparam -Tt /dev/sda" generated "average cache reads at 1030.7125 MBps" and "average buffered reads at 362.2075 MBps"
2. dd read test with empty buffer cache generated "average reads at 383.5 MBps"

I put together the following script (based on the contents of Arch wiki SSD Benchmarking page) to do the "dd read test":

# first create a file 
dd if=/dev/zero of=./tempfile bs=1M count=1024 conv=fdatasync,notrunc

for i in 1 2 3 4
do
  echo "Run number ${i} ..."
  # then clear the buffer cache
  sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"
  # now read the file
  dd if=./tempfile of=/dev/null bs=1M count=1024
  echo
done

I have not performed other tests mentioned on that page.

Update # 2
I did one thing after completing those tests: I had put "vm.vfs_cache_pressure=50" into my /etc/sysctl.conf, but, now I removed it. After that change and a reboot, the system seems to be booting up (from "Acer" logo to auto-login") in just under 30s. But, my assumption was that things should be even faster than that because my magnetic HDDs are giving me those sort of boot times!!

Update # 3

I still have to follow @Lekensteyn suggestion of moving the SSD onto the core i3 notebook. I will do that soon and report here.

Shouldn't SSDs be blazing fast?
Given all that info, what would you recommend I do to speed up the drive.

I would appreciate if you give me specific directions (text + commands) to run to speed up the drive.

Update # 4

People! Thanks a lot for your helpful replies. But, this SSD was so PATHETIC that I threw it out of the window ... no kidding. Let me know how to close this question as there is no point in wasting our time on this pethetically low quality product produced by Transcend and sold by Flipkart in India.

Adios! Peace!

Solution 1

The product sheet lists the following performance data for capacities "32GB~256GB":

• Seq. Read/Write 520MB/s, 290MB/s
• Max. 4k random file read 69,000 IOPS
• Max. 4k random file write 68,000 IOPS.

The truth is that performance of SSDs greatly depends on the number of storage dies and that the smallest versions of a product line usually are slower and don't achieve the performance of the top model.

Knowing that, the following data from geizhals/skinflint look more accurate and somewhat disappointing:

• Read: 364MB/s
• Write: 73MB/s
• IOPS 4k read/Write: 33.096k/17.674k

Yes, SSDs have faster access times, but transfer speeds of low end models can actually be lower than HDDs. You should read tests (with real world data and scenarios) of up to date available consumer hardware before shopping (The last one I read was about the 840 EVO mSATA release earlier this year). If you are searching for bargains, read tests of last years hardware too and make comparisons to pick the right product that meets your expectations.

---

dd if=/dev/zero of=./tempfile bs=1M count=1024 conv=fdatasync,notrunc

To be polite, this is the most unreliable way of testing HDD performance and for SSDs it's even worse. The controller on the SSD probably saw all the incoming zeros and stored the information that you wrote 1 GiB of nothing. Also real data is not made up of ideal continuous streams in one portion of your storage space, therefore use real data and real scenarios.

Solution 2

You are running fstrim at boot time, so add that time to your normal boot. Run it manually to see how long it takes:

sudo  fstrim -v /

You might be better off putting the weekly cron job back, or just running fstrim manually.
Also, you don't want the "discard" option in fstab, that will impact performance.

Comments

[Lekensteyn]

I suggest to take out the HDD of your other notebook, then insert your SSD into it and see whether the boot time is still absymal. If so, then you should blame the CPU in the netbook.

[TuKsn]

Is AHCI activated in your BIOS ? And perhaps you can add some benchmarks to your question wiki.archlinux.org/index.php/SSD_Benchmarking

[TuKsn]

Don't expect to much, if it is now booting up (from "Acer" logo to auto-login") in just under 30s, I think it is a good value for this SSD and CPU.

[thatmaheshrs]

Thanks a lot! That was a great answer. I learned a lot through your answer. I will keep those things in mind the next time I am shopping for an SSD. (I cannot up vote you answer because i don't have enough reputation. This comment is a place-holder for that up-vote.)

[thatmaheshrs]

Thanks a lot for that very informative answer. I should have thought of that earlier: fstrim will take time. I will run it manually to see the impact. If the timings are too bad, I will add the weekly cron job back. And yes, I may have missed adding it into the orginal question but I had removed the "discard" option from the fstab immediately after install. But, I will check that once again, just to be sure.

[thatmaheshrs]

The dd if=/dev/zero ... was specified in the Arch wiki. If you think that is not the best test, I would request you to update the arch wiki (link in my question). Thanks!

[thatmaheshrs]

plz don't mind that i selected the other answer. i liked both the answers but i had to select one of them.

[thatmaheshrs]

Hey @tracker1 thanks for the "assurance" that the bottleneck isn't my drive. :) That was a bold claim. And just FYI: please read the original question once again. I had clearly stated that the netbook is an "Acer V5-123 with AMD E1-2100 and 4GB of RAM". Under ordinary circumstances "Acer V5-123" would be the model number of the netbook. Now, if you want me to add info on whether I have SATA-1 or SATA-2 then that can be done.

[thatmaheshrs]

... and I just checked the SATA controller and it is a 6Gbps SATA, which I assume is a SATA-III controller till you wish to "assure" me otherwise. :)

[thatmaheshrs]

Hey @livewirebt, have you updated the Arch Wiki or at least brought it to their notice that the "dd if=/dev/zero ..." is a "very bad" test?

[Tracker1]

Okay... short of testing the performance in another system, I'm still pretty sure that the bottleneck isn't your drive. I'm sorry I didn't catch the model number in question. I'd run a test of the drive in a more powerful system to be certain, though I haven't seen an SSD behave slowly (unless it's nearly full, and there are a lot of dead regions) I've seen them outright fail, and many other issues, never slow.

[thatmaheshrs]

let me do that and report back.

[jamadagni]

@thatmaheshrs I'd suggest to use /dev/urandom rather than /dev/zero. Lots of smart utils like dd see the multiple zeroes and create sparse files in a snap, that's all! :-)

[jamadagni]

@thatmaheshrs Did you remove fstrim from the boot? Any improvement? I'm also thinking of buying an SSD for higher speeds. And AFAICS Transcend has been a reliable company but maybe this particular product is a low-end item I don't know...

[thatmaheshrs]

@jamadagni, that ssd broke! :( like, physically broke! so I am back to using the original hdd with windows 8.1 on it. windows 8.1 makes me cry. :)

[thatmaheshrs]

@jamadagni, true. /dev/random is definitely a better option.

[jamadagni]

@thatmaheshrs /dev/random will not be able to feed you 1G of data all that fast as it looks for real randomness. dd will probably timeout or something. You'll have to use /dev/urandom (note the u before random) to include some pseudo-randomness which is sufficient for such purposes. See the relevant manpages for more info.

[jamadagni]

@thatmaheshrs Physically broke?!!! Like what happened?! Anyhow I also recently saw Win 8.1 on a friend's laptop and was horrified at the bloat! I installed Kubuntu Trusty for him parallely without any problem and using GRUB to dual-boot. (BTW you can take a dd backup of the initial pre-partition space of the HDD to restore the original boot sector if wished later.)

[thatmaheshrs]

thanks @jamadagni for those helpful tips. my usual way of operation is: get a laptop; if (laptop has windows on it) { buy a new hdd; install new hdd into laptop; label windows hdd "appropriately"; } install xubuntu on new hdd in laptop; live happily ever after; :D