Upgrading a Mac Pro 2008 (3,1) with the Sonnet Tempo Pro Plus SATA 6G PCI Card

I’m a huge fan of continuous integration. So I was pretty disappointed when Apple removed the 4-core options for the 2014 model of the Mac mini.

That’s why we bought a used 2008 Mac Pro with 2 4-core Xeon CPUs (Model identifier 3,1) to replace our 2010 Mac Mini, which just couldn’t keep up with the number of of build jobs we were throwing at it.

According to Geekbench the 2008 Mac Pro offers roughly the same multi-core performance as a 2012 4-core Mac mini (Both offer about twice the performance of the top-notch 2014 MacMini).

However, the Mac Pro offers room for 4 internal drives, PCI expansion cards and supports more RAM, that’s why we decided against buying the 2012 Mac Mini, even though our local reseller still has some in stock.

The Mac Pro’s major disadvantage is it’s lack of a SATA 6G interface. It’s older SATA 3G interface offers a theoretic peek throughput of 300MB/s, while modern SSD drives easily reach 500MB/s or more. We thought we could work around this bottleneck by buying an SATA 6G PCI card, but that process didn’t work as smoothly as we thought.

We ordered an Sonett Tempo SSD PCI card, which lets you mount a single SSD directly onto the PCI card itself. This way we wouldn’t need an extra adapter or cables to mount an 2.5″ SSD in the MacPro’s 3.5″ drive bays.

Shortly after having placed the order, I run into this little detail on Sonnet’s product page:

Tempo SSD Pro is recommended for Mac Pro 1,1 2,1 and 3,1 instead of Tempo SSD. These early Mac Pros have PCIe 1.1 slots which will negotiate the two-lane Tempo SSD card down to one lane. These early Mac Pros will correctly negotiate with the four-lane Tempo SSD Pro.

That didn’t sound too promising, but luckily I was able to change our order to a Sonett Tempo SSD Pro Plus – which is twice the price, but also offers room for two SSD drives on the PCI card.

Once the card arrived, we installed it – only to discover that while we could install OS X Yosemite on an SSD attached to it, our Mac PRO refused to boot from that drive. According to the Sonnet support page, our card already comes with the most current firmware. Since the card is advertised as bootable on OS X, we were a little confused.

After a while of digging around, we found a Sonnet blog post from 2013 announcing boot support for their Tempo SSD and Tempo SSD Pro cards, which led us to a firmware update, that was not offered on the Tempo SSD Pro Plus downloads page.

We decided to give that firmware update a shot, and the updater offered our PCI card as a target. It told us the actual firmware update process would be performed during next restart, but much to our dismay, nothing happened during reboot. We were still stuck with a non-bootable SSD drive.

Since the firmware update was created before Yosemite was released, we weren’t sure it was fully compatible. Also, the Mac Pro was booting of an FileVault encrypted hard drive, which could interfere with whatever process the Sonnet updater uses to flash the PCI card.

We booted the Mac Pro from an external, unencrypted drive with OS X Yosemite, run the updater application again, and this time the Mac Pro started into an EFI prompt, asking us if we wanted to update the card’s firmware. After that procedure had finished, we were finally able to boot from the SSD drive attached to the Sonnet card.

Disk throughput went from around 60 MB/s with the internal 1TB hard drive to around 450 MB/s with an Samsung 840 SSD attached to the Sonnet card. That’s still not as fast as 1TB/s a current Mac Pro or Mac Book Pro achieves, but a pretty solid number compared to the money (~1000 €) we invested in this whole project. My only wish is that getting this setup to work wouldn’t have been that time consuming.

Why the 2014 Mac Mini is a disappointment for developers

My company purchased a around a dozen of different Mac Minis since its introduction in 2005. Some of these machines were used for standard server issues, like serving web pages or database entries. But many of these Mac Minis have been used for continuous integration.

With continuous integration there’s a dedicated server monitoring the code repository a group of developers uses to store the code for their software projects.

Whenever a change is checked into this repository, this continuous integration server tries to compile the changed source (if the source code is written in a programming language which needs to be compiled into machine code) and executes tests to confirm that the code does what it is intended to do.
Should any of these tasks fails, the developer that made the breaking change gets notified and is hopefully able to fix the problem, before co-workers are on his or her throat.

Common software tools, that are used for continuous integration are Hudson or Apple’s own Xcode Server.
There are even hosted continuous integration services like Travis, but depending on the project you are working with, these services are not always an option, e.g. because of a client’s security policy.

Continuous integration is especially handy, when you are working with code modules that are shared between different projects.

When a developer makes a change to such a module, for instance to add a new feature into application A, he is usually not aware that application B also depends on that code module (at least that’s the case with me).
With continuous integration setup right, the change will trigger builds and tests for all software projects that depend on the affected module.

Hence, a change that only effects a single line of code my trigger a dozens of build and test jobs. Speed matters here, because you wan’t all projects that are affected by late-afternoon code checked before the developer goes home.

image

Also, if a developer has been fixing a specific bug, he wants the fixed version of the software project in the hands of his testers as fast as possible, so these people can check if the bug has indeed been fixed. Usually, test builds are distributed by the continuous integration machines, too.

Up to this date we use an aging Mac Mini Mid-2010 for continuous integration, but the machine has become painfully slow compared to a current Mac (Book) Pro most of the developers in my company use.

We always considered the purchase of an Xserve (while it was still around) or Mac Pro as overkill, because we neither needed a lot of graphics power, internal storage capacity, nor redundant power supplies for continuous integration. Also, these machines usually sold at around 3 to 4 times to price of a maxed-out Mac Mini. All that mattered was somewhat decent compile times, which depend on the clock speed of the CPU and the number of its cores.

We wanted to buy a new machine in 2013, but no new Mac Mini model was released that year. So we were hoping for a 2014 model, which was finally released last week. Unfortunately this iteration is very disappointing:

Much to our dismay Apple removed the 4-core option it’s predecessor offered, which results in approximately half the compile speed of the former top-of-the-line Mac mini (Geek bench multi-core score 11319[2012] vs. 63518[2014], Source PrimateLabs).

image

This strategy is confusing to me: One the one hand, Apple supports continuous integration with Xcode Server (which was released last year), on the other hand it takes away the only attractive Mac to deploy it own.

Most likely Apple’s hardware department doesn’t see a market, where Apple’s developer tools department does.

The 2014 Mac mini is clearly not made for continuous integration, so we see ourselves forced to shop for a used Mac Pro (pre-2013).

“Snap To Road” in iOS 6 breaks accurate GPS recording

A lot has been written about the quality of Apple’s iOS 6 Maps data. As it turns, there is another side to the story. It was not noticed before, possibly because it only affects people who want to accurately record a GPS track of their outdoor activities. Here is how I learned about this problem:

When my new iPhone 5 arrived, I was excited. Finally I was able to use my new Bluetooth heart rate strap while cycling. (I had an iPhone 4 before, which doesn’t support Bluetooth smart accessories.)

I was hoping for a more accurate track recording of my bike rides, too, because alongside GPS the iPhone 5 also supports the Russian GLONASS geo-positioning system (as did the iPhone 4S ). My old iPhone’s GPS recordings occasionally become inaccurate, especially when riding through forests. The more satellite signals coming in, the better.

I was in for an unpleasant surprise.

I usually track my rides with the popular Strava iPhone app. What sets Strava apart from other GPS tracking apps, is that it lets you mark arbitrary sections of your rides or runs as ‘segments’.
Whenever you run or ride through any of these ‘segments’, the time it takes you to finish is compared against other Strava users, who also completed this segment. This is an really easy way to see how your performance improves over time and how you compare against other cyclists or runners.
However, there is a catch: If your recorded GPS track doesn’t follow the pre-recorded segment closely, Strava won’t recognize your effort. All your suffering has been in vain.

Once I returned home from my ride I was disappointed. Strava hadn’t picked up one particular segment, where I went pretty fast, hoping to improve my personal record. Sometimes this happens when the GPS reception is bad. But since I had placed high hopes in the iPhone 5’s supposedly improved GPS reception, I decided to take a closer look.

The quality of GPS tracking in general was pretty good. In comparison to the iPhone 4, the recording followed my actual route much closer. Here’s a comparison of the same route, recorded with the iPhone 4 on iOS 5 and the iPhone 5 on iOS 6.

A track recorded with an iPhone 4 on iOS 5.

A track recorded with an iPhone 5 on iOS 6.

I also noticed that iOS 6 doesn’t know about Berlin’s popular Mauerradweg bike street, a 160km long route following the perimeter of the former Berlin Wall. Cars are prohibited on this route and it’s therefore used by joggers, skaters, and cyclists like me. I often use the ‘Mauerradweg’ for cycling, because it’s a quick and safe way to get from Berlin’s center to its outskirts.

The Strava segment for with I was hoping to improve my time is on the ‘Mauerradweg’ bike street. While following my recorded route further I noticed something odd. Once I reached a certain speed threshold, the recorded GPS track jumped about 50 feet onto a highway that runs in parallel to the bike street. This jumping is probably the reason Strava didn’t take my time into account. My recorded track simply doesn’t match Strava’s reference track close enough for my time to make it into the segment’s leader board.

A screenshot of the Strava app on iOS 6. I was going on a bike street unknown to iOS 6 (gray, dotted line). Once I go a little faster, my GPS location jumps onto the nearby highway.

Here is what I think happens: Unlike it predecessors iOS 6 has direct access to map data. Once iOS detects you are going faster than a certain threshold (in my testing around 20 mph), it will correlate your GPS data with the location of a nearby street running in parallel to your actual track. I presume this was implemented to improve the turn-by-turn navigation experience for car drivers, in case where the received GPS signal is slightly off.

In theory, this might be a good optimization. However, when used in combination with the map data on iOS 6, it makes accurate GPS recordings impossible in areas where street data is less than perfect (probably everywhere outside San Francisco, especially when it comes to bike-only streets not covered by whatever car-only data provider Apple acquired its data from).

On iOS 6 perfectly good GPS recording is turned invalid, just because iOS 6 doesn’t know the street you are traveling on. While this might not effect the majority of users, it ruins the experience for users of the Strava iPhone app and similar apps.

I contacted Strava about this issue, and this is what Elle from Strava told me:

Thank you for sending along this very helpful info! Indeed, we are already aware of this problem, but unfortunately the Apple OS does not allow us to choose whether we have this “snap to road” feature or not. All location data is bundled into one source, called “Location Services” and it is not possible to distinguish the factors that go into this location data.

We are in contact with Apple about this, and hopefully some progress can be made there!

Hopefully Apple implements an API for GPS recording apps to opt out of this optimization and puts the fun back into Strava for me and other users. Apple’s intentions with this optimization are probably good, but considering the current state of the iOS 6 map data, they actually worsen the results for people like me.

Update (Nov 5, 2012): I filled a bug with Apple about this. I posted my bug report here. If you are hit by the same bug, please duplicate it with Apple’s bug reporter.

2nd Update (Nov 5, 2012): I was contacted by the developer of another GSP related fitness app. He suggest that Strava simply forgets to set CLActivityType on iOS 6 to CLActivityTypeFitness. Without a correct type being set, Apple guesses and assumes an automotive activity beyond a certain speed threshold.
If true, that would be a pretty embarrassing oversight on Strava’s part.

3rd Update (Sept 12, 2014): So it’s been almost two years since the original post, and the bug is still in Strava. Pretty unbelievable.😦

My workaround is to use the Wahoo Fitness app for ride recording and then use the built-in export to Strava feature.