A server I use to mine bitcoin has 2 individual ATi Radeon 5970 video cards. These cards each contain two individual GPUs, for a total of 4 GPU cores. These GPU cores hail from the Radeon 5870 video card, where they are stock clocked at 850 MHz. In the 5970, however, they are downclocked to 725 MHz, and the voltage is reduced to 1.05 volts to stay within the power consumption specifications of the PCI-Express standard. So, this video card is just ripe for overclocking.

Step 1 for me was to just play with the core clock. I have my VRAM underclocked to 1/3 of the core clock – it is unneeded in bitcoin mining and running it fast only serves to create more heat. I nudged the core clock north, but hit a pretty hard wall around 816 MHz. I wasn’t going any further on this overclocking journey without applying a little more voltage to the GPU cores. However, all the overvolting tools for ATi are Windows-only! After extensive googling, I found a project that someone wrote to overvolt his/her Radeon 5850 – named [radeonvolt]. It didn’t quite work for me as-is, but after some hacking I was able to get the program to recognize both cores of each of my 5970’s, and change my core voltages successfully.

If you’re interested, click [here] to download a .patch file of my modifications. Otherwise, I will explain the few changes that needed to be made below.

1) Fix the card locating loop. Find the lines that look like this:

if(dev->device_class == PCI_CLASS_DISPLAY_VGA &&
dev->vendor_id == 0x1002 && dev->device_id == 0x6899) {

and change them to look like this:

if(dev->device_class == PCI_CLASS_DISPLAY_VGA ||
dev->device_class == PCI_CLASS_DISPLAY_OTHER) {

One GPU core registers as a VGA compatible controller, the other is just a “helper core” with no outputs, so it gets the DISPLAY_OTHER identifier. We also strip out the vendor and device ID checks – this allows us to attempt to probe the I2C bus of any video card detected. This appears safe still, I’ve tried the code with non-reference GPUs and nothing broke, the software properly reported it was incapable of modifying non-reference cards.

2) The radeon 5×70 cards, unlike the 5×50 cards (for which radeonvolt was originally written), use power profile slot #3 for high-performance, not slot #2. So, we just have a couple more changes to make. Find the line:

float voltage = vt1165_get_voltage(i2c, 2);

and change the “2” to a “3”:

float voltage = vt1165_get_voltage(i2c, 3);

additionally, make a similar change on this line:

vt1165_set_voltage(&i2c, 2, value);

…should of course read…

vt1165_set_voltage(&i2c, 3, value);

And that’s all, folks. Compile, use, and enjoy. I was able to push my core voltage to anything I wanted, but with great power comes great responsibility. Running my core at 1.1125 volts, I have now achieved a rock-stable 900 MHz core clock. Just be sure to keep an eye on the VRM temperatures!

[root@localhost ~]# radeonvolt
Device [6]: Device 689c
Current core voltage: 1.1125 V
Presets: 0.9500 / 1.0000 / 1.0375 / 1.1125 V
Core power draw: 70.55 A (78.49 W)
VRM temperatures: 83 / 89 / 84 C

Device [7]: Device 689c
Current core voltage: 1.1125 V
Presets: 0.9500 / 1.0000 / 1.0375 / 1.1125 V
Core power draw: 63.58 A (70.73 W)
VRM temperatures: 115 / 114 / 113 C

Device [14]: Device 689c
Current core voltage: 1.1125 V
Presets: 0.9500 / 1.0000 / 1.0375 / 1.1125 V
Core power draw: 67.06 A (74.61 W)
VRM temperatures: 87 / 89 / 89 C

Device [15]: Device 689c
Current core voltage: 1.1125 V
Presets: 0.9500 / 1.0000 / 1.0375 / 1.1125 V
Core power draw: 66.19 A (73.64 W)
VRM temperatures: 108 / 108 / 111 C

The blue dragon was misbehaving once again. To repeat, it’s a 1987 Oldsmobile Cutlass Ciera with the Tech-4 variant of the 2.5L Iron Duke engine. She was idling really rough, had a lot of vapor coming from the exhaust, and was drinking coolant at an alarming rate. After replacing the faulty radiator, the coolant leakage got better, but didn’t stop. Sounded like a head gasket issue. Someone told me to check the oil, if it’s a milky color, that means there’s coolant in it, which signals a blown head gasket. So, when I popped the valve cover off, I saw this:

I think that qualifies as a “milky color”. Yikes. Ok, so time to start pulling the engine apart to get to the head gasket. After about 4 more hours of labor and a few smashed arm incidents (those head bolts are tight!), I finally got the head off, and saw this:

Now, a lot of this coolant got in there while I was taking the head off, so it’s really not as bad as it seems. But, notice that cylinder #1 (leftmost) is slightly more full than the others. After drying the water out, the problem became much more apparent:

Yikes again! And so was it really the gasket? I inspected the head and didn’t find any cracks. Then, taking a closer look at the gasket, I found the problem:

So long story short, it was another 5 hours of labor to get everything back together into good working order. I think the total job ran me about $285, which isn’t bad considering I did pretty much an entire upper engine rebuild. That price includes new head bolts (which you should always do – if you reuse, they can snap. If they snap, you’re done), two oil changes, new exhaust manifold, more coolant, and all the associated gaskets.

Photos from my phone from Sunday, 8/28, the day after the storm went through.

Photo of the lake behind my apartment, the water is supposed to stop a few feet short of that fence you see sticking up.

The crushed stone is supposed to be a dam all the way across the end of the lake, with probably a good 10-foot drop-off. As you can see, the water does no dropping. Houses past this dam had at least two feet of water against their walls.

River, errr, Route 1. This is the view from the Route 95 overpass. Looking north, there were a few cars that had gotten stuck. The water was halfway up their windshields.

I do have a droid 3, and have been waiting anxiously for a rooting mechanism. Yesterday, when someone on a mailing list I frequent posted a link to a forum announcing a droid 3 root, I had to get in on it. But the mechanism was in the form of a Windows binary-only application. Below the link were several people complaining that the file was tripping up their antivirus software. Running strings on the file, I was able to see that it was creating outgoing TCP connections to port 6667 (IRC). You do the math on that one. I was also able to extract the rooting method, though, and I’ll reproduce what I did for others:

Run “adb shell” on a computer connected to the droid to enter these commands.

mv /data/local/12m /data/local/12m.bak
ln -s /data /data/local/12m

Now, reboot the phone. When it comes back up, adb shell into it again and run:

rm /data/local/12m
mv /data/local/12m.bak /data/local/12m
mv /data/local.prop /data/local.prop.bak
echo ro.sys.atvc_allow_netmon_usb=0 > /data/local.prop
echo ro.sys.atvc_allow_netmon_ih=0 >> /data/local.prop
echo ro.sys.atvc_allow_res_core=0 >> /data/local.prop
echo ro.sys.atvc_allow_res_panic=0 >> /data/local.prop
echo ro.sys.atvc_allow_all_adb=1 >> /data/local.prop
echo ro.sys.atvc_allow_all_core=0 >> /data/local.prop
echo ro.sys.atvc_allow_efem=0 >> /data/local.prop
echo ro.sys.atvc_allow_bp_log=0 >> /data/local.prop
echo ro.sys.atvc_allow_ap_mot_log=0 >> /data/local.prop
echo ro.sys.atvc_allow_gki_log=0 >> /data/local.prop

Reboot the phone again. When it comes back up, adb to it a third time, but this time notice that you have a root prompt! Setting atvc_allow_all_adb to 1 disallows adb from dropping its root privileges. Now, to make this accessible to the device, run:

mount -o remount,rw /dev/block/system /system
cat /system/bin/sh > /system/xbin/su
chmod 4755 /system/xbin/su

Now, go into the market and search for the “superuser” application. Install the one with the jolly-rogerish logo, then run it and have it install its su binary. Once that’s done, we need to remove the su application we created, so in the adb shell you still have open, run:

rm /system/xbin/su
mount -o remount,ro /dev/block/system /system
sync

That’s it! You’re all set. Enjoy having root on the droid 3!

I took several classes in college that were all about corporate buzzwords, but all of them failed to mention a trend that is huge in corporate culture – that of the “best practice” document. In theory, these documents are great, and help you get the most out of your product, methodology, or technology. However, there are a few problems that these documents tend to create, and it is up to the reader to take them with a grain of salt. Listed below are a few of the pitfalls of adhering directly to one of these documents.

1) No one is perfect
“Best practice” documents are generally written by an idealist. This person has the responsibility to make the product or technique about which they are writing perform optimally. This means there is very little consideration for outside variables. Points in best practice documents tend to be very black and white – Do this, do not do this other thing, etc. Yet, how often is it the case that a reader is concerned with making only one piece of a puzzle work flawlessly? The answer is a resounding “never”, it takes the other 499 pieces of the puzzle working in tandem as well to produce something worthwhile and appealing.

2) Context is key
While we’re on the subject of black and white bullet points, we should discuss context. While adhering directly to a “best practices” document, it becomes easy to miss apparent pitfalls right in front of you. The document might say, “XYZ should look like ABC.” It becomes increasingly easy to see only the fact that XYZ != ABC, and even easier to miss the circumstances that made XYZ a little different than ABC. As mentioned in point #1, the writer of the “best practices” document is concerned only with making XYZ the best it can be. Often it is the case, however, that the overall quality of a product can be increased by decreasing the effectiveness or simplicity of a single component in the equation. Hence, context really is everything.

3) Stagnation is an enemy
“Best practice” documents literally define the status quo. Anyone who uses the same product or technology that you use will have access to this document. Therefore, it follows that they will have the same setup, the same features, and the same problems as you. At this point, what sets you apart? Where is the innovation, the fresh ideas to shake up the ordinary? As I remember reading elsewhere, what would have happened if Google followed the search engine “best practices” set forth by Yahoo and Alta Vista? Where would Apple be today if they took pages from IBM’s book about personal computers? This all lends itself very nicely to the next point.

4) Opinions become squelched
Now suppose you or a member of your team has an idea that challenges something stated in the “best practices” document. Which do you follow? Who do you trust? Odds are that you or your team member has much more insight into the issue than a document. However, when adhering directly to one of these documents, it becomes way too easy to ignore the opposing opinions altogether and do what is recommended in the document.

Now, I’m not saying that “best practice” documents are complete garbage. Often they contain many helpful tips and tricks for getting the most out of whatever they are written about. Yet, it is important to remember they are not the bible. To summarize my feelings on the subject, context is everything, and if there’s one thing “best practice” documents lack, it is context.