Monday, February 11, 2013

Linux SSD Setup

A solid state drive (SSD) is often the cheapest way to improve all-round performance in a computer.

There are many guides for setting up an SSD for each operating system. When I did a recent reinstall of Xubuntu, I looked through a few of the guides and picked what I felt were the most important things. To my mind, these are the two biggest things:

  • Ensure that the drive controller is running in ACHI mode. This is an option in the BIOS. (Note: With Windows, you need to change this mode before installing. I haven't tried changing it with a Linux install, but it will trash a Windows install).
  • Edit /etc/fstab to add "noatime,nodiratime,discard" options for the SSD partitions.

Since SSDs have a lifetime measured in "number of writes", much of the tuning advice is aimed at reducing the number of unnecessary writes.

Here's a few other things I did.

WARNING: I based doing this on the principle of "OS/applications on SSD, data/media on HDD", and "reduce unnecessary writes". Whether or not they are good things to do (particularly, mapping /tmp to a different drive while the system was running), I have no idea. It worked for me, but I didn't base this activity on any existing guide.

System Setup

I have one SSD (Samsung 830 128GB) and one HDD (Seagate Barracuda 2TB). During installation, I partitioned the SSD into ~80GB for the "primary" OS and the remainder for "experimental" OS installs.

I allocated the swap space to the HDD, since this could case a lot of writes if the system ever needs to swap out (probably rare, given the RAM available). I mounted the HDD as "/files".

Mapping Files in User Home Directory

By default /home contains all the user's files. When I was using Mint, it automatically created "Documents", "Downloads", "Pictures", "Videos" etc. in the user home directory. I maintained this with Xubuntu (can't remember if Ubuntu variants do this by default), but replaced the true directories with symbolic links to the equivalent directories in the HDD (in the /files partition).

For example:

    $ rmdir Documents
    $ ln -s /files/ashley/Documents Documents

This means that all these files are stored on the HDD, keeping the SSD free from associated writes.

Mapping Email and Browser Data

The user's home directory also contains email and browser data. So I symbolic linked my thunderbird mailbox to the HDD as well. This Firefox support post explains how to move the Firefox cache to another drive. In hindsight, I probably should have just linked the entire Firefox folder as well.

Remapping /tmp

I remapped /tmp from the SSD to the HDD. This one was a bit of an experiment. It could have killed my system, I suppose, but everything seemed okay, so I'll explain what I did.

The system uses the directory /tmp to store random runtime stuff as needed. It's a special directory in that anyone can write to it. You need to set the "sticky" flag for this. If you do an "ls -l" on it, you'll see something like this:

    drwxrwxrwt  2 user user 4096 Nov 19 20:13 tmp

The "t" character at the end of the first column indicates the sticky bit is set. This is what I did to move my /tmp directory:

    $ sudo mkdir /files/tmp
    $ sudo chmod 777 /files/tmp
    $ sudo chmod +t /files/tmp
    $ sudo rm -rf /tmp
    $ sudo ln -s /files/tmp /tmp

The reason I noticed I needed to set the sticky flag (the "chmod +t"), is that without it, filename completion in the terminal stopped working. I imagine a whole heap of other stuff would have to.

Also, when I look at my tmp folder now, the "t" flag no longer appears. Not sure why, but everything still seems to work.

So, there it is: cowboy setup for reducing SSD writes.

Tuesday, February 5, 2013

AMD HD7770 GPU in Linux


Update (Oct 2013): For anyone who stumbles across this, I've posted an update where I got the proprietary driver to work acceptably (but only on single screen).


After researching and asking around on forums about GPUs and Linux, I decided to get an AMD Gigabyte HD7770 1GB as an experiment. From what I could gather, AMD support in Linux was pretty bad, (or at least, more problematic than nVidia cards), so I went in with low expectations, willing to wear the difference of flogging it off secondhand if it didn't work out.

TL;DR: It wasn't all bad, but nothing "just works" (as was pointed out in forum responses). From my experience, I have to conclude that the AMD Linux drivers are effectively broken at the moment.

Rationale

Despite being warned away from AMD cards, the 7770 is an entry-level gaming card and not overly expensive. It was also overkill for the games I expect I would be trying to play (of which there isn't a huge selection on Linux yet anyway).

Since it wasn't too expensive ($119), I was willing to take the risk and try it out, partly for the chance to experiment, partly because AMD are reckoned to be good value for money in that price range, and partly because AMD at least supports an open source driver (for varying degrees of "supports").

Machine and OS Specs

Hooked into the i5 3470 system I built in December 2012, running LinuxMint 14 (Nadia) Cinnamon 64-bit.

On with what I found.

Card Installation

Quick and easy. Dropped right into the PCI-E slot without the firm coaxing that RAM and SATA cables usually need. I chose the second port because it looked like the USB 3.0 cable might get in the way of the card. After I put it in, I thought it probably wouldn't have been a problem, but I left it where it was.

Plug in the 6-pin power cable and away we go.

Note: If I'd got the slight less powerful 7570 (which I was considering) I wouldn't have needed the power, but I got a beefy PSU and it seemed a shame to not try out some of those cables sitting around in the bottom of the case).

With the GPU plugged in the on-board graphics is disabled. This is (I gather) expected behaviour.

Open Source AMD Video Driver

Single Screen

After plugging in the GPU and booting up, I didn't have have to do anything in particular. LinuxMint 14 has drivers installed by default to drive the GPU.

First test I plugged into the DVI port. It started up fine at full resolution.

A command you can use to see how the system has detected your GPU is:

    lscpi --nn | grep VGA

Mine displayed "[Radeon HD 7700 Series]"

Dual Screen

Then I added in the second monitor. If you've ever heard someone claim the dual-monitor support in Linux is limited, you can believe them.

Initially with both plugged in, only the HDMI monitor would work. The other monitor (plugged into the DVI, which was originally working), displays its "Current input timing not supported by monitor display" message.

I worked out how to get things going by using xrandr, a command-line tool that configures the displays.

By itself, executing xrandr outputs details about the detected displays. You need to know the "names" the system has given the monitors plugged into each port in order to control their output settings. In my case, the monitor plugged into the DVI port was "DVI-0", and the one plugged into the HDMI port "HDMI-0".

To make my main screen on the left and the second screen on the right, I used the following command:

    xrandr --output DVI-0 --auto --output HDMI-0 --auto --right-of DVI-0

This works, but leaves the taskbar on the right hand side screen (HDMI-0 in this case). To make the system use a particular screen as the "primary", use the following command:

    xrandr --output DVI-0 --preferred --auto --primary

This shifts the taskbar to the DVI-0 display.

Saving Dual Screen Setup -- Attempt 1

So, after using these commands to set up the displays as desired, I had to work out how to make the changes permanent. The "normal" way to do this (if that's the right word) is to put the configuration into the /etx/X11/xorg.conf file.

Using this answer, I adapted a minimal xorg.conf file and came up with this:
Section "Monitor"
  Identifier "First monitor"
  Option     "PreferredMode"   "1920x1200"
EndSection

Section "Monitor"
  Identifier "Second monitor"
  Option     "PreferredMode"   "1920x1080"
  Option     "RightOf"          "First monitor"
EndSection

Section "Device"
  Identifier  "Radeon HD 7700 Series"
  Driver      "radeon"
  Option      "DVI-0"   "First monitor"
  Option      "HDMI-0"   "Second monitor"
EndSection

Something went wrong when I ran it though. At least, the HDMI-0 monitor got a new name, and became "HDMI-3". So it didn't quite work.

Saving Dual Screen Setup -- Attempt 2

Next I thought I'd try and set things up with xrandr, then go into the Preferences/Display dialog and use the "Keep current configuration" option to save the setup.

This creates a monitors.xml file in ~/.config with the current settings. However, it only applies after you login. The HDMI screen, if plugged in, always seems to be considered the "primary".

Saving Dual Screen Setup -- Give Up

I tried a couple of other wild and fancy things that I found on various sites to set up dual screens, but in the end just gave up. No matter which way I plugged the monitors in, if the smaller 23" LCD was attached, it was the one that "lights up" for the splash screen. After login the 24" came to life, but not before.

I couldn't work out how to get both screens going at the system level, rather than the user level, so I gave up.

Open Source Driver Performance

First test was running a fullscreen 1080p video. It ran with lots of glitches and jaggies when playing. The CPU went up to 50-55 degrees on all cores -- was is actually processing in software?

Then I downloaded the Phoronix Test Suite. The suite package itself is reasonably small, but the full test suite takes over 5GB of download and can take a few hours. I managed to run a few of them, but none of them ran very well. For example, Nexuis looked like it was running at about 0.1 FPS.

It was clear that, unfortunately, the open source driver was not even close.

Proprietary AMD Video Driver

It seemed I could choose between the Catalyst driver from AMD's site, or one of the fglrx drivers that were listed in the software centre. I still haven't worked out what the difference between these two things is -- I think they're related in some way, but I'm not sure how.

So after looking at askubuntu.com/questions/142627, I did:

    sudo apt-get install fglrx-updates flgrx-amdcccle-updates

Bam! Upon reboot, the video was completely broken. I could see the motherboard post, and then nothing -- not even a prompt. The onboard video also wasn't working (at the time I didn't realise you have to unplug the GPU completely for the motherboard to activate the onboard video).

So, at a loss, I booted up and started typing blind the following steps:

  • Reboot
  • Ctrl-Alt-F1 (open a console, that wasn't visible at all)
  • Enter username
  • Enter password
  • sudo apt-get -y remove --purge fglrx-updates
  • Enter password again (for the sudo)
  • <wait>
  • sudo reboot

Fortunately, this fixed the problem. So I can't really recommend installing the fglrx-updates variant of the driver.

Next I tried installing the Linux Catalyst driver from AMD's website. This was version 12.11beta at the time (see upubuntu.com/2012/08/install-amd-catalyst-128-on-ubuntu.html for the steps I followed).

This driver seemed to work fine (it at least didn't black out my screen) but came with the "beta" watermark in the bottom right. To get rid of that, follow the instructions at askubuntu.com/a/216730.

Dual Screen -- Proprietary

Unfortunately, getting dual screens set up with the proprietary driver was, if anything, more difficult than with the open source driver.

I tried the following mechanisms:

  • Steps at unixmen.com/howto-install-ati-driver-in-ubuntu
  • Then superuser.com/questions/395927, but the Virtual 3820 caused tearing when the taskbar animated up
  • Then I used arandr to get the 2nd display going
  • Then I tried the amdcccle (admin) application to apply "Digital Monitor(2) -> Adjustments -> Scaling (0%)" This resulted in another refresh problem on the second monitor, where it would only update while the taskbar on the primary screen was animating during hover.

So I gave up on the dual screen idea in order to get some testing done for the driver. With the dodgy dual screen setup, running the test application fgl-glxgears got 500-600 FPS, but was very choppy.

Proprietary Driver Performance

To revert to a single screen, I entered the following at the command line:

    aticonfig --initial -f

Now running fgl-glxgears got around 2500-3000FPS. So, same driver but running with only a single screen instead of dual screen improved the performance of this benchmark application by 6x, and it no longer looked choppy. But this is a pretty simple little application, I wanted something with a bit more meat.

So I installed xonotic and ran it up fullscreen (1920x1200) with the highest settings I could set. Within the game is ran just fine (too fast for my old hands), but my old eyes couldn't discern any difference between the "default" versus the "high" settings, so I'm not sure if I did it right.

But, after running this (or, it seemed, any "fullscreen" game), the taskbar animation back in the desktop became choppy and caused tearing all over the screen.

Last Ditch

All this playing had taken a couple of weeks by this stage. I got recommended to run the sgfxi script at smxi.org (a "fix it all" graphics driver script). When I downloaded it and ran, it exited saying I needed to run it from outside X.

Which was fine, I thought, so I tried to Ctrl-Alt-F1 into a console. But I couldn't see the console, at all. I could see the X session, but none of the TTY console (1 through 6) were working.

Somewhere along the way I'd borked those. By this time I'd had enough "experimentation".

Blew away Mint. I'm now running Xubuntu with the onboard video. Anyone want to buy a barely used Gigabyte HD7770?

Conclusion

My experience has led me to conclude that both the open source and proprietary drivers for AMD GPUs on Linux are broken. The Intel drivers for the onboard video aren't without their quirks (for example, I find it really hard to configure the login screen to start on a specific monitor at a specific resolution, and setting up dual monitors is still a bit of a chore). But for the most part they work.

With the AMD proprietary drivers I had crashes, no screen at all for a while, and dual screen setup was diabolical. With the open source driver I had tearing and I wasn't quite sure it was actually using the GPU to do anything.

Hopefully I'll get an nVidia card at some point to get another perspective, but I'll be starting with pretty low expectations.