Friday, December 6, 2013

Cooling Down an ITX Board by Replacing Junk Thermal Pads

About a year ago I picked up the Sapphire Pure Mini E-350. I subsequently put a system together around it on the cheap over the next 2-3 months as some good deals showed up. It's performed well enough for some light HTPC duties (Netflix, a little indie gaming, etc.), and has enough expansion options and flexibility to have some decent longevity.


Being a mini-ITX board, the cooling is nothing to really write home about - especially with its screaming 40mm CPU fan, but this really shouldn't matter since it has such a low power draw. Since I had recently toyed with the option of leaving it on 24x7 I decided it was time to double check just how bad the temps could get if left unchecked. So I started OpenHardwareMonitor, loaded up the CPU and GPU and let it sit for an hour. Upon coming back to check how things were, I was pretty shocked:


Looking at the temps:
Max CPU: 89.8° C
Max GPU: 90.0° C
Max Temp 1: 78.0° C (I'm assuming this is the FCH -Fusion Controller Hub, see why below)

Just a note that the CPU and GPU temps should always be almost identical considering both parts are on the same die.

After idling for a while temps dropped to around the current values in the screenshot above:
Idle CPU: 62.0° C
Idle GPU: 62.0° C
Idle Temp 1: 52.0 C

Not what I like to see for a product I'm thinking of holding onto for a while. Let's see what the problem is.

The two heatsinks on the board have to be for the APU (CPU and GPU), and FCH. The APU (AMD E-350) has a max TDP of 18 watts, and FCH (AMD A50M) of 5.9 watts. Fully loaded these will get pretty toasty. Time to void the warranty.

First, we pop off the APU heatsink. It's mounted well with 4 spring loaded screws from the back. It has a crappy thermal pad slapped on the bottom:


Notice how thick the material is where the APU made contact - not good for thermal conduction at all. Residue still on the APU, you can see how brittle the material is:


I removed the residue from the APU with isopropyl alcohol. Then, I scrapped it off the bottom of the heatsink with a small wooden skewer. The entire bottom is a rough finish of anodized aluminum. To do this right, the bottom should really be sanded and lapped to a nice finish, maybe a project for another day. At this point - lets check on the FCH:


Same story as before, looks like the pad was almost folded over too. I finished cleaning everything up - we're ready for some thermal paste:



I applied some Arctic Silver I had lying around - really almost anything would be better then the original stuff. Once everything was back together, I powered on and went strait to the BIOS to monitor temps before booting. Things looked good, so I let it boot and ran our test again:


What a huge difference:

Max CPU: 75.3° C        - Δ of 14.5° C
Max GPU: 75.0° C        - Δ of 15.0° C
Max Temp 1: 62.0° C    - Δ of 16.0° C

Idle CPU: 47.5° C          - Δ of 14.5° C
Idle GPU: 47.0° C          - Δ of 15.0° C
Idle Temp 1: 36.0° C      - Δ of 16.0° C

What a huge difference! I was kind of surprised that the temp delta was identical between load and idle, but this is likely due to the rough bottom of the heatsink. Things should only improve as Artic Silver takes several heating/cooling cycles to spread out and "flow" evenly.

Looking at improving things further, the APU heatsink is larger then the 40mm fan. I test fitted a 60mm fan and it would fit while hanging off on one side. This would provide increased airflow over a larger surface area, all while spinning at at a slower speed. I could have this fan hang over the passively cooled FCH heatsink, further improving tempts there.

The board does also support a 4-pin PWM fan on the CPU. This would be an additional option to quiet things down when idle.

I'll update in a few weeks once the thermal paste has cycled a bit.

Sunday, November 10, 2013

Dell PowerEdge R610/R710 Firmware - "The updates you are trying to apply are not Dell-authorized updates"

The other day I was performing some much needed firmware updates on a Dell PowerEdge R610 using the built in UEFI GUI. This usually goes pretty smoothly, but this time I received the following message:
"The updates you are trying to apply are not Dell-authorized updates."

After searching around I finally came up with a solution. The firmware updates have the signing certificates checked by iDRAC and the Lifecycle Controller. Dell changed/expired their cert so it is no longer considered valid by the old firmware. To get the new certs to be considered valid the iDRAC and Lifecycle Controller need to be updated, but since they are considered invalid this can't be done from the UEFI GUI. The answer is to update from the iDRAC web GUI.

Quick note: I documented this after updating, so some screenshots and instructions may not be 100% exact, but should be close enough to get through. Also, if you FUBAR your server its on you. This worked for me, but verify that the files mentioned and process shown match your hardware.

On reboot enter the iDrac by hittering CTRL-E when prompted:

Now enable iDrac. Set "iDRAC6 LAN" to "On":

Under "LAN Parameters" scroll down to IPv4 Settings and set IPv4 to "Enabled" and set valid LAN parameters (static would likely be easiest):


Now would also be a good time to set your iDrac credentials to something you know. Set the password in "LAN User Configuration":

Save changes and exit.

The server will start to boot normally. Would be best to halt the boot process here as you'll just have to reboot again soon (Windows - F8, VMWare - CTRL+O, Linux - Arrow keys, etc).

Now you need to wait for the iDrac to start its networking services. This could happen in 30 secs, or maybe a few minutes. I usually just run a continuous ping of the IP I just set it to until I start seeing a response.

Log into the iDRAC web GUI - https://<IP-you-set-the-idrac-to> (root and whatever you set the password to)

Click the "iDRAC Settings" on the left then choose the "Update" tab at the top:

Download this file (Life Cycle Controller Repair): http://downloads.dell.com/FOLDER00502596M/1/BDF_1.5.5_BIN-12.usc

Click on the "Choose File" button and point it at the BDF_1.5.5_BIN-12.usc file. Click "Upload".

The file will be uploaded and after a few minutes it will prompt you if you want to update. Choose Yes. It should quickly come back saying the update has been applied successfully.

Download this file (iDRAC firmware updater): http://downloads.dell.com/FOLDER01270825M/1/iDRAC6_1.95_A00_FW_IMG.exe

This contains a .d6 file you need (firmimg.d6). I just extracted the file from the exe using 7zip.

Navigate back to the update page (I had to navigate to a different page first) and upload the .d6 file.

The file will be uploaded and after a few minutes (could take up to 20) again it will prompt you if you want to update. Choose Yes. Eventually it should come back saying the update has been applied successfully and the iDRAC will now restart.

You now have to wait for the iDRAC to restart. I just run a continuous ping again and wait to see a few timing out - this happens when iDRAC restarts. Once it starts responding it's successfully restarted.

Restart your server and enter the UEFI - "F10 = System Services"

Run your update again and it should now complete successfully (usually takes several reboots). When its done it will drop you at the main UEFI screen. I usually run the update one more time and it should show everything at the current version:

Reboot and disable iDRAC again unless you have appropriate security measures in place to protect it.

I was able to apply the same process to both R610 and R710 servers of the same generation. YMMV.

Credit to the original thread where I found this solution: http://en.community.dell.com/support-forums/servers/f/177/t/19475476.aspx

Thursday, November 7, 2013

iPad 2 + iOS 7 = Weak WiFi Signal

A few weeks ago my SO upgraded her iPad 2 to iOS 7. No issues other then the the iPad would show an extremely weak WiFi signal throughout the house, where previously the signal was good. Other devices showed no problem in these locations so it was clearly the iPad that was at fault.

Went through all the recommended things: reset networking in iOS, changed channel on AP, tried a different AP, and still had the same problem.

I had recently picked up a dual band AP but hadn't gotten around to migrating over from the old one yet, so on a hunch a powered it on. Low and behold the 5 GHz SSID is immediately seen by the iPad, while the 2.4 GHz one is no where to be seen. This of course contradicts the usual observation that 2.4 GHz networks should have better coverage due to poor wall penetration by 5 GHz signals.

This at least provided a band-aid while I figured things out.

While looking around for more solutions I came across several forum posts stating setting their network to N-only had helped with little additional explanation. So on a whim I set my AP to N-only and with that change the iPad suddenly showed the network it previously couldn't find when it was more then a few feet from the AP.

Going through all the possible setting for the WiFi mode with the iPad in a single location:

Mode
Signal
802.11 b/g/n
None
802.11 b/g
None
802.11 g/n
2 Bars
802.11b
None
802.11g
None
802.11n
2 Bars

Tried this with a different brand AP and saw the same results. That's good enough evidence for me. There is clearly an issue with iOS 7 and how it handles mixed mode wireless standards - specifically non-N or modes including B. Since it isn't all iOS 7 devices there has to be some other factor - likely firmware loaded at run-time by iOS for the wireless chipset in the iPad.

Changing the setting fixes things while the iPad is home, but does little everywhere else since almost all routers/APs will be set to some mixed mode out of the box for maximum compatibility. 

I'm waiting for a fix Apple.

Wednesday, November 6, 2013

TRENDnet TEW-711BR Review


So I needed to get a router for my grandmother-in-law after finding out her PC was directly connected to her cable modem. She only has one device (her computer) which is only used for email and web browsing. She doesn't need wireless, but obviously needs something that can be set and forget. I went for a gamble and picked up a TRENDnet TEW-711BR, it was on sale at Newegg for $15.99 with free shipping and I had yet to have bad luck with TRENDnet products so far.



The router was held securely in the box in a cardboard tray. Almost everything it was shipped in was recyclable which is nice. Received hardware version 1.0R. Shipped with firmware version 1.00b31, updated and tested with 1.01b09.

For my testing I applied a "load" using iperf. Power measurements taken with a Kill-a-Watt. I used the web GUI to disable the WiFi radio.




Router Status Power Usage
Idle (Wifi on) 1.6W
Load LAN-WAN (Wifi on) 2.0W
Load WLAN-WAN (Wifi on) 2.0W
Load WLAN-LAN and LAN-WAN (Wifi on) 2.2W
Idle (Wifi off) 1.1W
Load LAN-WAN (Wifi off) 1.6W



Routing

Iperf testing shows that this router is limited only by its 100 Mbps WAN port. Using two client and two server processes I was able to sustain just under symmetrical 100 Mbps speeds between LAN to WAN(~94.3 Mbps, just under 190 Mbps bi-directional). Refreshing Steam servers multiple times while playing Team Fortress 2 showed no impact and no issue with browsing on a different system. Ping times remained low throughout this as well. I measured the max simultaneous connections at 3973 - so this is likely around 4096 total connections. Overall this router offered impressive performance for its low-end price point.


Wireless

Wireless coverage is average for a low-cost, single-antenna device. Performance is acceptable - iperf testing showed real world throughput of around 38 Mbps at a distance of a few feet - Windows showed a connection speed of 130 Mbps. Separating myself by about 2 stories I had much poorer signal, but could still browse the web and stream video without issue. 40 MHz channel width testing was not possible due to the crowded 2.4 MHz spectrum in my location. Wireless performance was certainly acceptable.


GUI

The Web GUI is fast, simple, and intuitive. All the usual features found in modern routers are present. One very neat feature is the ability to capture packets from either the WAN and LAN interfaces. When you stop a capture, the packets can be downloaded in a standard Wireshark .pcap file. I'm not sure what the limit is as to how long you can capture for, but this was a pretty neat feature for such a cheap device. The normally common feature of a Guest wireless network was not present.


Other

Device is light, but has rubber feet to keep it sliding around. 5 year warranty is admirable, but I hope I never have to use it. Through all the testing/loading the max temperature reached was around 92F at the top of the enclosure measured by an infrared thermoeter (~77F ambient). Normal operating temp was much lower at around 80F. I never had to reboot or power-off the router during testing


Conclusion

Highly recommend for the light user or someone not needing the latest and greatest WiFi coverage. Fantastic bang-for-your-buck at the price point I paid. At a normal price of around $25 there are likely better options out there.

Tuesday, November 5, 2013

Intro

So after wrestling with the concept for a few months I've committed to finally starting a blog. I have obviously ended up using Blogger vs Wordpress after weighing the pros and cons. The future chance of simple monetizing is a plus along with some of the less Wordpress'y junk. I've also decided to use my real name since my end hope will be to (hopefully) build some professional credibility.

Primary focus of this will likely be all things technology with a focus on IT, InfoSec, engineering, hardware and anything else I find interesting.

Here we go.