Wednesday, November 02, 2016


Like most technologists, my home is an informal museum of the history of computing. For many years I had been running Asterisk, an open source IP PBX, on an ancient Dell Dimension 3000 personal computer. Here is the PC after being decommissioned, along with its VGA monitor and its PS2 keyboard and mouse.


In an effort to clear out some of the older computer gear, I replaced the Dell with an Asterisk appliance: a Grandstream UCM6102, which is a purpose-built off-the-shelf IP PBX based around an embedded processor with an ARM core. It's about the size of a paperback book... or a Kindle, if you prefer.

Grandstream UCM6102 Asterisk Appliance

The new device supports my analog business line that I still insist on maintaining, and even an old Radio Shack analog phone that is an antique itself and which I use just for testing. It works just fine with the SIP phone in my home office. My dial plan changed a bit, as I accommodated the new system's way of doing things. Since I'm the only user, this was a minor issue.

I took the old PC to be recycled. Just before it was carted off, I used my iPhone to take a photograph of its company asset tag, and of the Dell service tag on the back. It was only when I got home that I realized it was Digital Aggregates Corporation asset #1 (although that probably has more to do with when I started using asset tags to keep track of company property than anything else.)

Asset Tag DIAG0001

I looked its service tag up on the Dell web site and was told that my system shipped in August 2005. This old Dell PC was at that time the fastest computer in the Palatial Overclock Estate. I was more than a little surprised to discover that, eleven years later, it was still the fastest computer in the house, on a per processor core basis.

Dell lists it as a singe-core Pentium 4 processor at 3 GHz. My second oldest Linux system is a four-core Q6600 processor at 2.4 GHz. My newest Linux system is an eight-core i7 processor at 2.8 GHz. My MacBook Pro runs at 2.8 GHz, and my MacMini desktop at 2.6 GHz.

I have written before at length about the transition from higher clock speeds to multiple cores, and the problems this entails with taking advantage in software of this perhaps hypothetical increase in performance. But I didn't expect to be faced with this evolution in such practical terms.

I'm having some second thoughts.

Tuesday, October 18, 2016

John Sloan and Hardware Entropy Generators

My good friends at Gogo Business Aviation have been following my interest in hardware entropy generators and asked my alter ego John Sloan to give a talk on it. They videotaped the talk and generously agreed to let me share it. Plus: they fed an entire class room of attendees! It doesn't get much better than that.

You'll hear Jaguar mentioned from time to time in the video. That's the code name for an upcoming Gogo BA product that will bring new meaning to the term cloud server.

Once I complete this little research project, you can expect one of my ginormous tl;dr blog articles on the topic.

Thanks again to my colleagues at Gogo Business Aviation.

Tuesday, June 28, 2016

Separate But Equal III

I'm making it a hobby to notice when data communications technologies move to separate control and data into independent channels, a common architecture pattern I've written about here more than once. A little more than a year ago I was writing software to control a Sierra Wireless MC7354 cellular modem in an Internet of Things project for which, somewhat remarkably, the Thing was going to be an aircraft on the ground.

After the usual noodling around and web searches I discovered that to use the modem in LTE mode, the usual serial port and PPP wasn't going to hack it: too slow. Instead I entered the (for me anyway) brave new world of QMI (Qualcomm MSM Interface) and RMNET, proprietary Qualcomm modem interfaces supported by both a software stack from Qualcomm for their "Gobi" family of devices, and an open source software stack consisting of the libqmi library, the qmicli command line tool, and the qmi_wwan driver, for your favorite Linux distro.

In PPP mode, the control of the modem is done using variants of the Hayes modem AT commands from the 1970s that we old folks all know and love. Once the data call was set up, a data channel using Point to Point Protocol was established over the same serial port, and IP packets were tunneled through it to the far end. Lots of layers of bits on top of bits there, all limited by the baud rate of the serial port.

But when using QMI and RMNET, the device exposes a control channel using Qualcomm's QMI messaging protocol, and a data channel using Qualcomm's RMNET virtual USB Ethernet framework. Once the appropriate QMI messaging is exchanged with the modem, the RMNET interface appears as just another Ethernet dongle. Except this Ethernet cable terminates wirelessly somewhere else in the world.

Again: separation of control and data. The old serial port interface is exposed via USB as well, and in fact has its own uses which can be exploited even while a data call is up over the QMI and RMNET channels. But it was another great example of optimizing a control channel for small packets with low latency, and a data channel for big packets with high bandwidth.