what a difference an AHCI makes

Last week, I noticed how, whenever huge disk IO was taking place on my Quad-core – with 4Gb of RAM and 64bit Ubuntu – workstation at work, the whole desktop environment would pretty much grind to a halt.

SSH’ing in from a remote machine and using top, iotop and nethogs didn’t show anything particularly heart stopping going on either.

I googled around and found that this seemed to be a fairly common problem with any of the newer kernel releases.

One post in particular said that a person had fixed the problem by disabling the SATA disk controllers AHCI mode in the BIOS – switching it back to IDE.

Cool I thought – let’s have a go! Interestingly, the BIOS was already set to IDE. I decided I’d try enabling AHCI instead.

Wow – what a difference that made. I then remembered one of the other posts I came across that just said to switch the BIOS setting as that forces the OS to load a different disk controller driver.

It certainly did the trick – said work-beastie is now much faster and more responsive under load.

fleeting moments

Travelling the 45kms or so to work every day, affords some amazing views of two local mountain ranges – among other geographical features. One particular morning, I was marvelling at the light shimmering on the moving wind turbine blades, the snow capping one of said mountain ranges and the mauve sky behind it all.

As the sun was rising behind the mountains – before it was entirely in view, it’s light caught the edges of some clouds on the other side of the ranges. It was an amazing sight – almost like the proverbial ‘silver lining’ but, instead of clouds, it was the mountains that had the silver lining.

An awe inspiring moment of the wonder of God’s creation. It amazes me that some would choose to dumb down the beauty around them …. but that is their choice after all.

Within seconds, this sight had been replaced by the overwhelming brightness of the rising sun – you could no longer see anything in direction. Not any detail at least.

At that moment, I was reminded of some things:
1) How cool that I happened to glance to the east at that precise time!
2) Our lives are as fleeting as that beautiful sight
3) The Glory of God shines much brighter than the amazing sun which He created

I believe we need to live our lives to the fullest – in Him. No matter what beauty is there, it is because we are reflecting His glory – like those clouds were, the sun. And finally, we should make it our goal that it’s His glory that overshadows us – not try and make it the other way around.

God Bless
donkey

segfaulting multimedia processes -or- The Case of the Badly Cooled……Case

A wee while ago (yes, I’m catching up on things I’d hoped to blog about for a while!), I had a problem with my home PC. This culminated in a post to the Ubuntu Forums.

General stability of this machine is great – it’s normally on for weeks at a time serving the familys various document/web/email/printing needs – and has done this for about four years with the only major hardware change being a new 7600GT graphics card (most recently – about 12 months ago) and a new Socket 478 P4 Extreme Edition CPU about 18 months ago).

So, what do you guys think? Hardware or software? And how do I troubleshoot this one further? (BTW, I’ve been a linux user for about 8 years now, so I’m not really a guru and definitely not a noob. Perhaps more of a goob. 😀 )

Basically, I had an issue where, whenever I’d do some ‘heavy lifting’ tasks – like audio or video encoding, the app would just disappear. Very odd it was – I tried all sorts of things to fix it. New linux distro’s, replacement RAM etc.

Starting the processes from the command line, I was able to see that the app termination was actually a segfault – which I subsequently found in the dmesg log. That and two other distro’s (lenny and a Fedora Core live CD) gave errors in dmesg about the CPU overheating:

Turned out to be the CPU overheating. Interesting, there was nothing in dmesg about the CPU overheating – though, when I had Debian on, it did show messages about that – and, when I booted into the Fedora 10 Live CD, it also complained about the CPU overheating in dmesg.

So, to solve the problem, I transplanted the guts of my box into a new case which breathes better and also used the correct heatsink for my CPU (one with a copper core).

The problem was that I was using the same case and heatsink from my old P4 2.8Ghz which wasn’t cutting it with the new P4EE 3.4Ghz and the amount of heat it generates.

Once the correct heatsink and better case with more efficient thermal dynamics were in place, the differences in internal temperature were quite remarkable:

If anyone is interested, here’s some temps from lm-sensors that show the difference in internal temps between the two cases and heatsinks. These are both just at system idle with no loading.

Before
SDA: 37C | SDB: 34C | GPU: 57C | CPU: 40C

After
SDA: 33C | SDB: 28C | GPU: 40C | CPU: 23C

During loading, the CPU was getting to around 70C, now its able to stay around the 57C – and with no segfaulting going on! Yaay!

The rather cool thing – from my point of view anyway – is that Windows would merely have blue screened under the same circumstances (or just rebooted as the default blue screen setting dictates). Obviously that would make things much harder to troubleshoot.

So linux dealt with the overheating by terminating the offending process. A much more elegant way of handling things – don’t you think?