Upgrading Juno

Towards the end of 2012 I upgraded my desktop computer, Juno, in several ways. I replaced the original solid-state drive (SSD) with a larger, newer one, I upgraded the BIOS, and I took a two-year leap in the software installed.

SSD swap

Juno was constructed with an Intel X25-V, a value-oriented 40 gigabyte SSD.

This device was large enough to hold the operating system (Linux) and applications, but all my user data was stored separately, on a regular spinning-platter hard drive. SSD drives were and are more expensive than regular hard drives, although now not so much as 3 years ago. Having the operating system and apps on the SSD made Juno fast to boot and fast to launch applications.

My choice to replace it was a Samsung 830, the 128 gigabyte version.

With this size, I could keep not only the operating system and applications on the SSD, but also all my user data except the extensive photograph folder, which remains on the hard drive. The Samsung device, being of a newer generation and not designed as a "value" item (not compromised to reduce cost) is, according to the specs, three times faster reading data and ten times faster writing data than the X25-V.

Fortunately, I also discovered while researching which SSD to purchase that SSDs using the new SandForce controller (interface between the SSD memory and the rest of the computer) did not play well with the I/O chip on my motherboard, the Nvidia MCP79. Many SSDs such as Intel, Corsair, and others now use the SandForce controller.

The MCP79 supports device speeds of 1.5 Gb/sec and 3.0 Gb/sec. (The newer SSDs also support 6.0 Gb/sec.) When the MCP79 negotiates the connection speed with a SandForce controller, they end up using the 1.5 Gb/sec setting instead of 3.0 Gb/sec! The Samsung SSDs use a Samsung controller and have no such problem. This, plus the excellent reviews of the 830, made the choice an easy one.

When I took the faceplate off Juno, it was clear that the dust filter needed to be cleaned again.

A dust vacuum wasn't sufficient; I ended up removing the filter and washing it.

Juno is constructed with the SSD installed in a drive bay underneath the optical (CD/DVD) drive. Thus, the first step was to remove the tray for the drive and disconnect the cables.

Here we see the Intel X25-V still in the drive bay.

Installing the Samsung was just a matter of removing the Intel (4 screws) and sliding in the Samsung, reinserting the 4 screws and reattaching the cables. By then the filter was dry, and I could reassemble Juno.

The upgraded system is certainly snappier than before. I'm pleased with it.

BIOS Upgrade

My motherboard, the Zotac gf9300-i-e, theoretically supported both methods of chatting with bulk storage devices such as hard drives and SSDs. The ATA specification is the much older of the two, and to support advanced features of newer hard drives and of SSDs there is the newer AHCI interface. However, when first building Juno, it became clear that the AHCI option didn't work. In fact, if I enabled AHCI in the motherboard's BIOS (embedded firmware), the computer would no longer see any of the attached devices: no hard drive, no SSD, no CD/DVD drive. Urk! I proceeded in ATA mode, which seemed to work well enough.

After swapping the SSDs I decided to try AHCI mode again. Same result, very disappointing. However, this time I stumbled across a Zotac forum posting mentioning a BIOS upgrade that had come out a few months after I assembled Juno, which solved this problem. There were some technical hurdles to overcome -- this motherboard, unlike some others, won't recognize a BIOS upgrade automatically if a USB stick is plugged in -- but eventually I applied the new BIOS, and voilá, AHCI mode was good! 

Installing XUbuntu 12.10

I had ceased installing newer versions of Ubuntu, sticking with 10.10, because of the controversy over the new default user interface, Unity, and the changes in the GNOME desktop between version 2 and 3. I was happy with my GNOME 2.x desktop, and 10.10 was supported with updates and security patches for 18 months. Then those stopped. After two years on 10.10, Juno's software was showing its age and some new software packages would not install.

I had played around with some other packages on my ancient laptop, primarily LMDE (Linux Mint Debian Edition) with its Cinnamon and Mate desktops. But I wasn't completely pleased with Cinnamon or Mate, which were efforts to maintain a pre-Unity desktop environment. Finally I went with XUbuntu, which is an Ubuntu distribution that also installs a more traditional and lightweight desktop manager, xfce. I have a few quibbles with it, but xfce was my best fit.

Here are some miscellaneous points I noticed:

• The system will now wake up from sleep (suspend to RAM) when I press any key on the keyboard. Previously I had to push the power button. Hurrah!
• xfce can use either xfwm4, the standard xfce desktop compositor, or compiz, a fancier one. (Desktop compositors manage visual issues such as overlapping windows, partially transparent windows, wobbly windows, multiple workspaces, etc.) I finally decided that xfwm4 was more stable; occasionally windows would go black under compiz. I was willing to give up my wobbly windows for reliability.
• Some of the programs I use on a regular basis, such as the GIMP, an open-source Photoshop, were not installed by default. They can still be installed from the Ubuntu repositories, so it's not a large issue.
• LibreOffice, as distributed by Ubuntu, would crash on some of the spreadsheets I had created in the Ubuntu 10.10 environment. I filed a bug report, and it may be fixed in the next release. In the meantime, I installed OpenOffice, which worked just fine. Because of a file name conflict, I had to remove LibreOffice before I could install OpenOffice.
• The xfce desktop has, unfortunately, a mandatory snap-to-grid feature. That is, any icons/documents placed on the desktop are automatically lined up to use the center of one square of an invisible checkerboard dividing the desktop. I wish I could turn it off, as I could in GNOME 2.x. But I don't have very many desktop items anyway, so it's just an annoyance rather than an impedance to my workflow.
• The version of the C++ compiler supplied jumped forward two years as well. One of my programming projects would crash until I changed some global constructor usages that had worked OK with the older compiler.
• The audio/video command-line program ffmpeg is now deprecated, and a couple of the arguments have changed. The new version fails on some of my video projects where the old one did not -- arrgh! However, the program avconv, the immediate descendant of ffmpeg, did work. It leaves me wondering how or why the maintainers managed to break ffmpeg.

Going Forward

This is probably the end of the Juno upgrades. If it were inexpensive, I would increase the memory (RAM) from 4 GB to 8 GB, because sometimes when working on blog entries (many tabs open on the Web browser) and processing photos or videos Juno starts to swap (move some programs to disk to make room for other programs to run). This slows things down. However, this motherboard takes an obsolescent memory, DDR2-800, which is pricey when available. Perhaps next fall or winter I will build my next computer based on the upcoming Haswell generation of Intel CPUs, and I'll put 16 GB of memory in it. That would be enough RAM to allow me to experiment with virtual machines.

Further Education with juno

Now that I've been working with juno for a few weeks, I have a few updates.

• I found the setting that preventing booting and locked me out of the BIOS. Twice. If I chose "AHCI" or "Linux AHCI" instead of "IDE" for the SATA interface -- that which talks to the various storage devices, including the optical drive, hard drive, and SSD -- I got my unbootable lockout. So, having had to open the case and reset a jumper twice to get back to defaults, I know to avoid these! (Theoretically they should work. Theoretically.)
• The memory (RAM) was rated at 1.8-1.9 volts. The motherboard auto-chose 1.9 volts. I decided to manually set it to 1.8 volts, and it still works fine, even under the stress test. The idle power consumption edged down from 30 watts to 29 watts.
• It looks like the CPU temperature reporting isn't fully locked at 42°C, but rather won't report anything less than that. During some of the stress tests I saw brief flickers up to 43°C, leading me to believe that the sensors are alive. This summer, when the room temperatures are 5°-6°C higher than now, the sensors are more likely to wake up during the stress tests.
• I've been slowly experimenting with overclocking -- running the CPU and memory at faster than the rated speeds. The bog-standard default for juno's equipment is 2.93GHz for the CPU, and 800MHz for the RAM. Gradual bumps in speed have been followed by stress testing, so that I know sooner rather than later that it's gone too far. By now, juno is up to 3.16 GHz / 864 MHz. I've left the CPU and RAM "linked" -- overclocking in tandem. If I care to, I can unlink them, so that, for instance, I could continue to bump the CPU speed without taking the memory further than it can go. That juno can accomplish this with the -.10v undervolt of the CPU and the 1.8v setting on the RAM shows how some parts are binned by demand rather than quality. That is, my CPU may be a perfectly good 3.06 GHz or better part, but Intel needed more of the less expensive 2.93 GHz parts to sell, and fixed it as such. In any case, I plan to be conservative, and back off a couple of steps when either 1) the stress test starts to throw errors, or 2) the power consumption starts to climb more than a watt or two.
• I may also experiment in future with the power consumption response to deliberately underclocking the system.