Author Topic: ssd and pclos for what its worth pt 2  (Read 525 times)

Offline loudog

  • Sr. Member
  • ****
  • Posts: 400
ssd and pclos for what its worth pt 2
« on: February 24, 2013, 12:09:15 PM »
# hdparm --read-sector 4662176 /dev/sda (enter)

If trim is working you will see only zeros on the block, it appears to be working here as this is what we see:

/dev/sda:
reading sector 4662176: 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
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Great! Time to move forward with our tweaks, my, my , my, this is much funner than defragging, removing viruses, trogans, spyware, adware, malware, worms etc. etc. etc. what? Where? Who? When? Why? Uhhh  errrr did I get lost? where were we oh, ok ummmm I think i need a time out for a refreshing beverage or 2 maybe. Ahhhh thats better. Uhhhh can someone please tell me where we were so uhhh  uummmm waaaahhh? Im so cornfused, maybe a little to much arkansauce during the beverage break. Oh, oh yea schedulers. Thats the ticket, schedulers. Whats a schedulers thingy anyway?

                                                         FILESYSTEM SCHEDULERS

   Pclos comes with the 3 different schedulers loaded but the default scheduler used is the cfq scheduler. It's a simple thing to implement the one that works best with the ssd. A scheduler schedules the sector requests for the particular processes asking for them. To give a basic idea of the process involved the scheduler will process the sector requests starting at the beginning of the platter to the end of the platter in one full cycle (kind of like a record player) then will purge satisfied requests, grab another batch of requests and start the process over again while trying to achieve a balance between  fairness, performance and realtime. and remember this is done very very fast. With the invent of the ssd there are no spinning platters and moving heads to slow things down so a different type of scheduler will increase performance.
   Some info on the 2 different schedulers we will be working with:

DEADLINE-    data requests to disk have a deadline so intermediate sectors are skipped when a request looks like it is going to expire.
NOOP-    basically just serve the sectors to the process in kind of a first come first serve rule.

A more in depth study on linux schedulers can be found here:

http://www.linuxhowtos.org/System/iosched.htm


   for our setup we will be using the deadline scheduler as how to geeks reports an additional tweak you can use with deadline to get a little more performance out of the ssd although I will also provide the edit for the noop scheduler as well in case you decide to use it instead. we will need to edit the rc.local file so open a terminal, su to root and type in:

kwrite /etc/rc.local

and you should see a file resembling this:

#!/bin/sh
#
### BEGIN INIT INFO
# Provides: rc.local
# X-Mandriva-Compat-Mode
# Default-Start: 2 3 4 5
# Short-Description: Local initialization script
# Description: This script will be executed *after* all the other init scripts.
#              You can put your own initialization stuff in here if you don't
#              want to do the full Sys V style init stuff.
### END INIT INFO

touch /var/lock/subsys/local

modprobe snd-usb-audio

# Fix linkage to cdrom/dvd and permissons since udev is screwed
ln -s /dev/sr0 /dev/dvd > /dev/null 2>&1
ln -s /dev/sr0 /dev/cdrom > /dev/null 2>&1
chmod 777 /dev/sr0 > /dev/null 2>&1
chown root:root /dev/sr0 > /dev/null 2>&1
chmod 777 /dev/sr1 > /dev/null 2>&1
chown root:root /dev/sr1 > /dev/null 2>&1

what the f%#@ is that sh%#! (sorry for the curse words bad habits picked up from youcantoo) hmmm it appears that udev is screwed on my desktop, well ignore that, thats a personel problem I will have to deal with on my own. ill get you and your other little error messages too my pretty. Anyway the file here will be edited, add the lines:

echo deadline > /sys/block/sda/queue/scheduler
echo 1 > /sys/block/sda/queue/iosched/fifo_batch

or if you decide to use noop instead add this line:

 echo noop > /sys/block/sdX/queue/scheduler

to the bottom of the file and it should look similar to this:

#!/bin/sh
#
### BEGIN INIT INFO
# Provides: rc.local
# X-Mandriva-Compat-Mode
# Default-Start: 2 3 4 5
# Short-Description: Local initialization script
# Description: This script will be executed *after* all the other init scripts.
#              You can put your own initialization stuff in here if you don't
#              want to do the full Sys V style init stuff.
### END INIT INFO

touch /var/lock/subsys/local

modprobe snd-usb-audio

# Fix linkage to cdrom/dvd and permissons since udev is screwed
ln -s /dev/sr0 /dev/dvd > /dev/null 2>&1
ln -s /dev/sr0 /dev/cdrom > /dev/null 2>&1
chmod 777 /dev/sr0 > /dev/null 2>&1
chown root:root /dev/sr0 > /dev/null 2>&1
chmod 777 /dev/sr1 > /dev/null 2>&1
chown root:root /dev/sr1 > /dev/null 2>&1
echo deadline > /sys/block/sda/queue/scheduler
echo 1 > /sys/block/sda/queue/iosched/fifo_batch

what the f%@# is that sh%#! It seems that udev is screwed on my netbook as well, go figure.
   Now lets go see if the scheduler we have chosen is the one that the kernel is using shall we? In a terminal type in:

cat /sys/block/sda/queue/scheduler

you should see this:

noop [deadline] cfq

the names of the different scheduler's avalivable on your system are listed, the one in parenthases is the chosen scheduler the kernel will default to. I am using deadline as the command return shows. All is good.

                                                                    SWAP

   Now lets explore the swap filesystem shall we? This can be an interesting read if your in the not know even though it is rather basic in nature and if you are in the know I did say it was rather basic in nature. Swap, is a seperate partition on the hd that the os can utilise to write pages of data to if you run low on ram (remember that the ssd memory chips were arranged into pages of data also). There are no permanent files stored there, so swap is basically virtual ram or otherwise known as virtual memory. Now its interesting to note that linux will swap out less used data from ram to swap, for data that is being used in realtime, if it thinks that ram is getting to low for its liking. so when the system percieves that ram is running low it starts swaping out pages of data from ram to swap for quick retrieval and swapping them back in again as soon as it gets a call for that data, hence the possibility of constant writing and rewriting of the same data to swap and back again. The basic reason for this is all realtime data transfers to the processor go through ram. All  data that the processor is using in the exact moment, to give you, the user, what you are asking for on your screen, must be transferd to ram first before you will see anything, like it or not that is just the way it works. If you had no swap partition to use as a ram buffer when you ran out of ram the system would crash and a system crash means death to linux so the system try's very hard to avoid death at all costs. Although linux is very good at not using swap unless it is actually needed, it can initiate a lot of writes and rewrites in a very short amount of time if it thinks it is needed. Other than the constant writes and rewrites that degrade the life of the ssd chips, swap on a ssd would in essence be fantastic because the data access delay would be much shorter than on a standard platter drive. Let me explain. When the os is using data for an application, it needs to put all that data into ram or as much of it as it can so it can access it directly, data access between ram and the processor happens in nano seconds (billionths of a second), whereas standard platter drive's data is accessed by the processor in microseconds (millionths of a second) note: micro, nano and next is pico (trillionths of a second) are used in computing as measurments of time, with todays processors running in the billionths of hrz per second a micro second to a processor is like having to wait an eternity to get the next data batch to proccess. I remember back when the default text editor was named pico and it looks as if they downgraded to a slower editor with nano now being the default. Hmm seems we are in a regression stage. OK I did say I was a werido so moving on. Because platters are mechanical in architiecture they are slower. a thousand times slower than ram access times. Ok, for clairification purposes here is the typical low ram scenario: the ram is critically low, you open another program and linux goes to work. First it has to open up enough ram space for the program data to fit in so it swaps out  pages of program data you are not currently using to the swap partition. To swap this data out it takes microseconds to write it to the platter. Then it writes the data for the program you are wanting to use now to ram for immediate access. It had to get the data from the platter (taking microseconds) and put it in ram. Next you use the program for a couple of minutes and everything you do realtime while the program is loaded in ram is taking nanoseconds for the processor to complete. Linux must always swap data into the ram from the hd before the processor can use it for realtime results. This is where the bottleneck occurs when you dont have enough ram in the system. alternatly hibernate writes all the data to swap before hibernating so we would want to make sure that it is used only when absolutly nessessary. You can set up a swap partition on a seperate platter drive on your system and edit the fstab file instructing the os to look for it there but in the case of the netbooks out there you are usually restricted to one hdd and a limited ammount of ram. Running without a swap partition at all is fine if you have plenty of ram but that also depends on the workloads you put on the machine and many other considerations like hibernation. The suggested 4gb of ram minimum and a small swap partition for a netbook is the configuration we will be using for our writeup.
   Now the first thing we want to do is to instruct the os to ignore using swap unless we run out of ram. We do this by editing the rc.local file. open a terminal, su to root and type:

kwrite /etc/rc.local

You will see the by now familiar rc.local file. Add this line to the bottom of the file:

echo 0 > /proc/sys/vm/swappiness

this line tells the os that the swap partition will only be used if the system is out of ram. remember to add the newline at the end of the text file if you are using kwrite. Save the changes and exit. You can test this by opening up a terminal and typing in top (more on using the top command later).

                                                    /TEMP FILES

   Temp files hold a lot of information temporarily, often being written and rewritten to during normal use. the system cache is also written to temp. to keep the system from writing to the ssd needlessly we will workaround this by instructing the os to mount the temp files in a ramdisk which just means create the /temp files in ram memory, hence the usefullness of plenty of ram memory. We will be editing the fstab file again. In a terminal su to root and execute:

kwrite /etc/fstab

at the bottom of the file add these lines:

tmpfs   /tmp       tmpfs   defaults,noatime,mode=1777   0  0
tmpfs   /var/spool tmpfs   defaults,noatime,mode=1777   0  0
tmpfs   /var/tmp   tmpfs   defaults,noatime,mode=1777   0  0

and if you are not concerned with losing your log files between boots, your not running a server and you want to get the last little bit out of the tweak (do not use this on a pclos tester machine) add also this line:

tmpfs   /var/log   tmpfs   defaults,noatime,mode=0755   0  0

since many everyday applications may generate lots of log files this is a nice little tweak.
   Now lets reboot and get with the testing to make sure its working. This is what I did to test it. I opened a terminal, executed the top command and noted the ammount of ram that was being used. I then copied a small iso file to my temp folder and checked the ammount of ram usage compared to the previous reading. You should see the ammount of ram usage go up the same ammount as the file you wrote to temp and in this case the top command did report the proper increase in ram usage so we know the tweek worked.


                                                       APPLICATIONS

aplications that generate large ammounts of cache writes to the disk are also candidates for possible changes. Of these we will only focus on one but it is considered for the average user the biggie, the internet browser. For the sake of the average intelligent user we will be using firefox instead of Internet  Exploder for the example. What we want to do is move the browsing cache to a ramdisk thus saving maybe thousands of writes rewrites a day. for those of you who surf the net often this is the biggie for ssd life. What this will do is tell firefox to use the /tenp folder that you have already set up in a ramdisk for the cache. The drawback is that it gets erased each time you close firefox so choose wisely. To enable this open the web browser and type about:config in the address bar. There will be a warranty warning so just tell firefox you will be careful. OK now we are on firefox's config page. now There are 2 suggested ways of doing this, the first way is to scroll down to the entry:

browser.cache.disk.enable,

right click it and toggle the value from true to false. Next, right click on an open area of the list, from the menu chose new- string and type in this:

browser. cache.memory.capacity
 
in the next window type in the size of the ramdisk you want firefox to use, the suggested is 16000, = 16 mb but your needs may vary. Close the browser completely and restart to save changes.
   The second suggested way to do it is to right click on an open area of the list, choose new-string and type in this:

browser.cache.disk.parent_directory

in the box presented type in the path to your /temp folder. Mine looked like this: /home/loudog/tmp. As with the other modifications concerning /tmp to ramdisk you can check to see if its working by using the top command in a terminal.

                                                 FIRMWARE UPDATES

   Updating your firmware in linux requires the use of the command line, although in some special cases there is a live cd-usb type of updater supplied for some makes and models. We will go through a brief tutorial using my ssd (OCZ vertex 2 60gb) as the test subject. Errr ummm ahhh I hope I dont toast it because my toast is usually ummm burnt. If you are famillar with the bios flashing of a motherboard then you can appreciate the delicate process involved, one mistake and the ssd's ROM is toast, uuhhhmmm, burnt toast to be exact. Proceed at your own risk.
   I was fourtunate enough to find a bootable iso for the updating procedure and an executable file that could be run from the command line (linux based of course). We will try the iso method. I downloaded the iso and the user's guide. I did read the guide (thoroughly) because I can only imagine my post to the ocz forum. “Help iv toasted my ssd and cant boot up” and of course the standard reply on many forums “Did you RTFM dumba$$?” dont really want that type of response from a forum (again). Pclinuxos's forum is quite nice comparativly. Very tactfull. I would expect a response something similar to “Was there a manual or users guide we could reference” signed OP or ucan2. Of course there would be the big grinning smiliey face at the end to make you feel all happy inside with the (at least in the early days) DYRTFM comment at the end that us newbies had no clue what it meant untill later. OK, all joking aside I burned the iso to a cd and will be using my external dvd player to run the program.
   The updater os was suprisingly pleasing to look at. The graphics were crisp and clean with some cool extra features that made it something to load into virtualbox just for fun (gotta love linux). Weighing in at a whopping 48.5 mb the iso was very lightweight. The toolbar featured firmware update, cleanwipe (think they shoulda used a tp paper roll for the icon here) fix temprature, (it seems the ssd controller would report an internal temp of 120c to the os by mistake which appears hot for any hardware), fix sata io, update for mac, fluff and internet browsing.
   I poked around a little for curiosity sake and then got to work. The first things I checked was the temp fix and the sata speed fix. The temp fix returned a not needed for this drive. The speed fix returned the same message. It was interesting to note that all the executed toolbar clicks opened up in a terminal type-cl enviorment. And finally here we are, the next thing on the list, the dreaded rom flash. OK, click the shiny little update button. Wait for the terminal to start, and  survey says! GREAT! The configuration looked acceptable to the flashing utility. COOOOL,  yes I feel better! Please enter cntrl+c to abort. in the meantime the flash utility started the proccess of updating the firmware. Ummm,   ashamed at being so queasy, I quickly ran away, and tucking my tail between my legs ran for a can of courage, four-loco to be exact, grape. very very courage inducing (I know because my friends try me when we drink it and I have to show em im not afraid of you punk, but,  I do go easy on em cause their not injin and dont understand the ill fu(#) you up pal and smile while you cry and tomorrow Ill have forgotten anything has happened.) Half a can down and the dreaded “failed to update” “internal error” message appeared in the mini console. Crap. What the hell is going on? This is a linux based mini system here right? So the designer or someone knows something right? Yep! Its off to the forums for us because the guide specifically says that if you get the failed to update message to post the results to the forum for analasis.
   Oh sure another forum, rules, regulations, codes of conduct, prerequisits, identity, blah, blah. As it turns out the forum was very helpful and all was well with the ssd firmware.

This thing is blazing fast and on the newly released 64 bit version of pclos WOW.
 
LOVE YOU ALL, PCLOS = SOFTWARE FREEDOM. Stay in the struggle, fight for your right for freedom.
  Sorry for any old info. loudog



Friends don't let friends boot windows

Offline gseaman

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 3801
Re: ssd and pclos for what its worth pt 2
« Reply #1 on: February 24, 2013, 12:48:53 PM »
On the new test kernels there is an additional scheduler to consider: bfq. From some recent benchmarking, it can do better than noop and deadline with ssds. Every scheduler works better than cfq for ssds.

Galen

Offline Just17

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 10697
  • MLUs Forever!
Re: ssd and pclos for what its worth pt 2
« Reply #2 on: February 24, 2013, 05:26:08 PM »
Thanks loudog .......  a valuable reference  ;)

MLUs rule the roost!

Linux XPS 3.4.38-pclos1.bfs  64 bit
Intel Core2 Quad CPU Q9450 @ 2.66GHz
4 GB RAM
MCP51 High Def Audio
GeForce GTX 550 Ti
PHILIPS  ‎DVD+-RW DVD8701
‎Logitech ‎BT Mini-Receiver
Afatech DTT

Offline tschommer

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 1890
  • MLU and BLU (Bacon lovin' user)
Re: ssd and pclos for what its worth pt 2
« Reply #3 on: February 24, 2013, 05:34:47 PM »
On the new test kernels there is an additional scheduler to consider: bfq. From some recent benchmarking, it can do better than noop and deadline with ssds.

I'm using the bfq kernel on a 64-bit system with a Samsung 840 SSD myself, and it feels as smooth as never before. Haven't done any benchmarking, though.
Our defense is in the preservation of the spirit which prizes liberty as the heritage of all men, in all lands, everywhere."
Abraham Lincoln --September 11, 1858 Speech at Edwardsville, Illinois

Offline gseaman

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 3801
Re: ssd and pclos for what its worth pt 2
« Reply #4 on: February 24, 2013, 05:48:18 PM »
On the new test kernels there is an additional scheduler to consider: bfq. From some recent benchmarking, it can do better than noop and deadline with ssds.

I'm using the bfq kernel on a 64-bit system with a Samsung 840 SSD myself, and it feels as smooth as never before. Haven't done any benchmarking, though.

This is good to hear. I don't have an ssd to test it myself.  :'(  ;)

Galen

Offline agmg

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 1924
  • Certified Windows Hater
Re: ssd and pclos for what its worth pt 2
« Reply #5 on: February 25, 2013, 01:13:33 AM »
On the new test kernels there is an additional scheduler to consider: bfq. From some recent benchmarking, it can do better than noop and deadline with ssds.

I'm using the bfq kernel on a 64-bit system with a Samsung 840 SSD myself, and it feels as smooth as never before. Haven't done any benchmarking, though.

I'm also using the bfq kernel with my OCZ Vertex 4 and I have the same feeling, compared to the standard and the .bfs kernels.
Doesn't show much difference in benchmarks using hdparm and dd but booting is about 1 sec faster and the general feeling using the O/S is that it's snappier.
For the whole world, you are someone.
For someone, you are the whole world.

Offline agmg

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 1924
  • Certified Windows Hater
Re: ssd and pclos for what its worth pt 2
« Reply #6 on: February 25, 2013, 01:15:57 AM »
@loudog

The info you provided would make an excellent article for the magazine ;)
For the whole world, you are someone.
For someone, you are the whole world.

Offline gseaman

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 3801
Re: ssd and pclos for what its worth pt 2
« Reply #7 on: February 25, 2013, 01:16:43 AM »
@loudog

The info you provided would make an excellent article for the magazine ;)
+1

Galen

Offline gseaman

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 3801
Re: ssd and pclos for what its worth pt 2
« Reply #8 on: February 25, 2013, 01:17:51 AM »
On the new test kernels there is an additional scheduler to consider: bfq. From some recent benchmarking, it can do better than noop and deadline with ssds.

I'm using the bfq kernel on a 64-bit system with a Samsung 840 SSD myself, and it feels as smooth as never before. Haven't done any benchmarking, though.

I'm also using the bfq kernel with my OCZ Vertex 4 and I have the same feeling, compared to the standard and the .bfs kernels.
Doesn't show much difference in benchmarks using hdparm and dd but booting is about 1 sec faster and the general feeling using the O/S is that it's snappier.

The bfq kernel also has bfs. :)

Galen

Offline agmg

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 1924
  • Certified Windows Hater
Re: ssd and pclos for what its worth pt 2
« Reply #9 on: February 25, 2013, 01:26:04 AM »
Thanks for the info, Galen! :)

You have done a great job with 3.2.18 bfq kernel ;)
For the whole world, you are someone.
For someone, you are the whole world.

Offline beta1

  • Full Member
  • ***
  • Posts: 93
    • What I do
Re: ssd and pclos for what its worth pt 2
« Reply #10 on: May 10, 2013, 03:08:14 AM »
Very good, many thanks for the info.
I incorporated it as as part of my changeover to 64bit as I have a SSD for both   / & /home  with my data elsewhere on other discs.

One thing to watch out for judging by what happened on my system was when I used the
 
tmpfs   /var/log   tmpfs   defaults,noatime,mode=0755   0  0

for that "extra tweak"  ;D the machine would not reboot with all sorts of messages about var/log  and not being able to be written to, read only file systems............ etc etc and so forth. It all came right, after a couple of extra reinstalls and my realizing what the problem was, so maybe this is something to look out for...... 

again many thanks
There is always a way