eMachines, Slackware64 and more audio work
(This is the fifth post in a series. You might want to start from the beginning for context.)
Part five: eMachines, Slackware64 and more audio work.
As previously described, my Linux box at the time was way too underpowered for the kind of data crunching I was trying to do with GNU Radio. It wasn't too surprising, given that it was built around technology that was now pushing five years old, and it was never built with speed in mind in the first place.
Given that it was the middle of the night, I couldn't exactly go out and find new hardware right then. Rather than sitting around idly waiting for stores to open, my thoughts turned to my dumb little eMachines laptop with Vista loaded on it.
A couple of years before, I had purchased it in order to take some classes online. It managed to run Windows, Office and Netbeans, so it actually succeeded at that. It wasn't quick, but it was newer than my Linux box. I figured it was worth a shot, and if nothing else, it was something to do for a few hours.
I got to go through the fun of shrinking a partition in Vista and then booted from my handy Slackware 13.37 subscription CDs and did a quick install. Then I rebooted, jumped through LILO, and pulled over all of the code from the other box. This should come as no surprise, but it choked really badly. It was even slower than my original machine. Considering it had been the cheapest laptop at Fry's at the time, this did not surprise me, but it did disappoint me.
I started wondering if any of this was worth it. Maybe I should just buy a bunch of ~850 MHz receivers and a bunch of USB audio receivers and call it done. All of that CPU had to be going somewhere. What is this Python code doing, anyway? I started stracing it in an attempt to profile it the hard way. There were dozens of threads with futexes flying around as things locked and unlocked. One was going crazy on the USB device. Another was sleeping strange intervals: 1, 2, 4, 8, 16, 32 ms, in that order.
I'm not sure if it was the powers of two in those sleep calls or not, but suddenly it occurred to me: this box was still running the "classic" 32 bit build of Slackware. Of course! This particular install had started life as Slackware 7.0 back in 2000 and had migrated across systems and hard drives, but it had always been the mainline install.
Slackware64 didn't exist when I put it on the latest hardware, so I just shrugged and went on with life. Who needs 64 bits anyway? I didn't have more than 4 GB of memory, after all. Then I found a quote from a developer about the benefits:
"Twice as many registers available for the compiler in 64-bit mode. This makes a big difference, since the X86 architecture is register starved."
I was sold. It was time to take the leap and see if I could upgrade this thing in place without breaking my whole system. I'd done it with countless Slackware boxes starting back in the 3.x days, so why not?
I started a download of the S64 13.37 DVD ISO and started thinking about contingency plans. What if this doesn't work and I need to build a bigger machine? What do CPUs look like now? What about motherboards? What kind of RAM do they take now? I don't keep track of this stuff normally. It changes too often, and there's no reason to know about it. Pragmatism is weird that way.
My download and burn finished, and my machine booted successfully off the disc, so I decided to go for it. I booted back off the normal filesystem and mounted that image over loopback. I installed just a few basic things, like x86_64 libs and a x86_64 kernel, and rebooted so I could start using 64 bit userspace. That worked and I proceeded to upgrade everything else from the DVD, evicting the old 32 bit packages.
About 90 minutes later, my machine was humming along as a totally x86_64 situation with no complaints. Now I had to go and rebuild all of the radio stuff: UHD, GNU Radio itself, and gr-smartnet. After all of that finished, I tried my program again.
This time, it didn't melt down. The load was high and it was running really hot, but it was staying just under the thermal trip limit. It didn't hurt that I was keeping close tabs on it and was only running my program for brief intervals. I also had the machine propped up with a fan pointing at it and my A/C set back a few degrees. I needed to make sure this stuff was for real before spending any more money on things like hardware, and this would be the way.
Still, it was not getting any audio. The WAV files were empty aside from a header written by the wav file audio sink. After far too much fiddling around, I finally just decided to pull the squelch out of the call graph. It would mean a horrible noise at the end of a recording, but anything was better than nothing in my book.
I pulled it out and restarted.
It recorded audio. It sounded terrible and had tons of static at the end, but it RECORDED AUDIO. It had this head-exploding clipping going on, and there was some bizarre wavering going on the whole time, but you could tell that it was getting closer than ever before.
Next: part six: New hardware, fiddling with squelch, and the Dojo.