How to Choose a Replacement Socket 1155 Motherboard

In another what I assume is a soon-to-be-deleted superuser question, due to the affectations of the moderator squad there, a user asked:

"I have a socket 1155 motherboard (P67 chipset with i5-2400) that died. What do I need to consider for a replacement?"

Here's my answer (extended a little here to try and cover all bases), in case it helps anyone else going through the same process:

The i5-2400 will work with pretty much any socket 1155 motherboard, so you can look at the boards that were released with SandyBridge CPUs — for example, H61, H67, Z68 — as well as those that were released for IvyBridge CPUs, such as B75, H77, Z77.

Most board manufacturers have a CPU compatibility list for each board, so if you find a particular board, you should be able to confirm by searching for the make/model.

Given that they're not made any more, finding a "good" replacement might be tricky. As long as the motherboard has all the ports and sockets you need, it should do the job. In the general case, some of the factors that should be considered:

• What sized case do you have? Physical size is imperative: An ATX motherboard won't fit in a micro-ATX sized case, for example. A board that is otherwise suitable must fit the case, otherwise it is pointless to consider it.
• Number of and/or combination of PCI and PCIe slots required. All current motherboards have at least one PCIe x16 slot for a graphics card, and keep in mind that most graphics card take up at least two slots.
• Number of RAM slots required. Some low-end boards only have 2 RAM slots — if you have more sticks than that it might mean you either have to reduce your amount of RAM, or buy a new kit with larger size per stick.
• Number of SATA ports. Most drives (hard drives, DVDs, and SSDs) around in the socket 1155 timeframe used SATA as the connector type. Make sure the motherboard has enough SATA ports for all your drives.
• Number of USB ports required. In addition the ports on the motherboard, consider what USB ports your case has. Any USB 3 ports will most likely require a USB 3 header on the motherboard, which are physically different sizes to USB 2 headers.
• Number and type of onboard graphics ports. If not using a dedicated GPU, consider what types of onboard graphics connectors you need.
• Number of fan headers. Required for case fans
• Chipset matching to avoid confusing your operating system. You may want to attempt to match the existing board — by chipset and/or manufacturer — in order to reduce the risk of your operating system from "rejecting" the change.
• Overclocking support. If overclocking with a 'K' CPU, choose a 'Z' chipset

Most DDR3 RAM will work with any board, but you can also try and confirm RAM compatibility either with the motherboard or RAM manufacturer's compatibility lists.

The i5-2400 which has limited overclocking potential is a little easier to source a replacement that for an overclockable 'K' CPU. In the latter case, the Z68 or Z77 boards are the best choice as they support overclocking.

2nd hand is most likely a cost-effective option if you can find one. Some socket 1155 boards are still available at online stores, so you could check Newegg, Amazon, and similar places. Alternatively, you could call a few local computers stores to see if by chance they've got old stock.

As an example of the process: here's a listing for the Gigabyte B75M-D3H at Amazon. The CPU support list shows that the i5-2400 is supported. It has 4 RAM slots, and after the GPU is in will have a PCI and PCIe slot free. It is only micro-ATX sized, so should fit all but the smallest cases.

When replacing, if you change the make and model of the board, you may have difficulty booting your OS with the updated board. This depends what OS you're using, and how different the replacement board is as far as drivers go. Windows traditionally hates hardware being replaced, and may refuse to boot; if you were using, say, Linux it would most likely just work. So keep that in mind that some recovery — or worst-case, a reinstall — of the OS might be required. Finding an exact model motherboard should avoid this issue; finding a similar chipset should reduce the risk of boot issues (but licensing issues may still need to be dealt with).

During the replacement process, after removing the heatsink, clean existing thermal paste from the CPU and heatsink using isopropyl alcohol. Reapply fresh paste before putting the cooler back on the CPU when it's installed in the new motherboard.

_{(As an aside, confirming that a motherboard fault is the problem — and not something else like a dead power supply — is a worthwhile activity to go through first).}

Build Log Followup: Another Gigabyte G1 Gaming

Continuing on from last week's post, while I wanted to track down an MSI GTX970 to try it out, local suppliers were completely out of stock of that card. And then MSY had a 10% off Gigabyte products sale, so...long story short I got a Gigabyte GTX970 G1 Gaming.

The GTX970 G1 Gaming

Couple of points of note for anyone thinking of getting one:

• The specs say the length is 312mm, but I think this includes both the frame and perhaps a little leeway. I measured 298mm from the inside of the frame to the end, so it might fit in cases where the specs say it shouldn't. Viewer discretion advised.
• Requires 1x8-pin and 1x6-pin power connectors.
• I've run it with the Power-Mate Lite for over a week — on the i7-4790K (stock) system the maximum power draw was 316W while gaming.

On the Windows side there were no issues of note compared to the last one I installed, but on Linux it was a different story.

I had a Kubuntu 14.04 install on the same machine with Windows 8.1, which was working perfectly with Intel graphics. After plugging in the GTX970, the Linux install refused to boot. Using "text" or "text nomodeset" override options in grub showed it was hanging at random places during the boot process. Even a live distro off USB failed to get a display. While running off onboard I installed the nvidia-current drivers, which didn't help.

The solution turned out to be installing the latest xorg-edger drivers. The process is described in this forum post by Kade7596, but the brief summary is:

sudo add-apt-repository ppa:xorg-edgers/ppa
sudo apt-get update
sudo apt-get install nvidia-346

Normally I would run "nvidia-xconfig" after installing the drivers, but the 346 drivers don't seem to include this application any more. Since I'd already run it using the older drivers from the Ubuntu nvidia-current target, I had a default xorg.conf written. Not sure if it was necessary.

After installing nvidia-346 the GTX970 now works.

In closing, the G1 Gaming also glows in the dark...

Build Log Addendum: Gigabyte GTX970 G1 Gaming

Update on last week's build log: managed to pick up a Gigabyte GTX970 G1 Gaming for the machine.

The Gigabyte GTX970 G1 Gaming

Installing the card went without issue. It proved to be a nice, quiet card after installing the nVidia drivers (fans were noisy at first boot -- probably as expected -- until the proper driver was installed).

Interestingly, despite the Fractal Design Arc Midi R2 specs saying it only has 290mm clearance for GPUs with the HDD cage installed, the Gigabyte GTX970 just fit (was a squeeze, but I could get it in). So obviously there is some leeway in Fractal Design's specs for this case.

Completed build. This is without the HDD cage -- I left it out in the end for better airflow

To test it out I ran through Unigine Heaven again. At 1920x1080 Ultra 0xAA, it scored 2627 (average FPS: 104.3, min FPS: 29.3, max FPS: 205.3). At Ultra 8xAA, it scored 1786 (average FPS: 70.9, min FPS: 8.8, max FPS: 137.6). A little better than the 10 FPS average of the onboard graphics.

Running through Hitman: Absolution in-game benchmark (random game I had available on Steam) it scored Average FPS: 60.2, Min FPS: 50.5, Max FPS: 72.0.

Fixing nVidia Graphics Tearing on LinuxMint Cinnamon

So, after installing an nVidia GTX 650TI a while back, I put up with tearing in pretty much all applications because it was easy to install and get going.

But eventually I got sick of it and tried to fix it. After trying about every fix I could find, I jumped to a different distro (from Xubuntu 12.10 to Mint 15) in the hope that might have some effect. It didn't, but I re-tried a fix I thought I'd already tried, and found it eliminated the tearing 100%.

The fix is to add this to the /etc/environment file:

CLUTTER_PAINT=disable-clipped-redraws:disable-culling
CLUTTER_VBLANK=True

This is using the nVidia proprietary driver 304.88. Hope to confirm on other Xubuntu systems whether this fix also works.

Update 20 June 2013:

Unfortunately, the fix only seems to work in Mint/Cinnamon. Title updated to reflect this.

Asus GTX 650TI on Linux

So after suffering through the (self-inflicted) pain of trying to run an AMD GPU under Linux, I bought an nVidia-based GTX 650ti to try out next.

Asus GTX 650ti

The 650ti doesn't have the best reputation for value (with performance that is similar if not worse than the much cheaper HD7770), but it seemed to go okay in reviews and is realistically already overkill for anything I'm going to use it for.

In box

I narrowed the choices down to an Asus version versus the MSI Power Edition. While I'd heard goods things about the MSI PE cards, in the end it came down to:

• DVI-D ports (compared to DVI-I).
• HDMI ports (compared to mini-HDMI. I have plenty of HDMI cables, but no mini ones).
• Low noise level and temperatures in reviews (though the MSI is similar here anyway).

Ports

Installation

Compared to the troubles I had with the AMD, getting the nVidia card up and running is a breeze. Admittedly, I cheated this time and went straight to the proprietary driver. The open-source driver (nouveau) worked fine straight after installing the card, and I'll probably keep an eye on it (it's apparently made some recent advances in capability). But, I was tired, and just wanted something to work, so I cheated.

Plugged in to motherboard

To see which drivers are installed, you can use:

$ sudo lspci -v

For more (or heaps more) information, you can use -vv or -vvv to the above command. Running with sudo gives you a bit of extra output as well.

Initially you'll see a line something like this in the VGA controller section:

Kernal modules: nouveau, nvidiafb

These are the open-source drivers installed automatically in recent kernels.

To install the proprietary drivers, you can use aptitude to look up the possible targets:

$ aptitude search nvidia

To get going, all you need is to do the following:

$ sudo apt-get install nvidia-current nvidia-settings
$ sudo nvidia-xconfig
$ sudo <reboot>

The xconfig command above writes a default file to /etc/X11/xorg.conf. If all installs correctly, repeating the lspci command above will now output something like:

Kernel modules: nvidia_current, nouveau, nvidiafb

Results

Everything worked without a hitch. Running nvidia-settings lets you set up dual monitors. After rebooting, for the first time the login screen was actually two separate screens, rather than mirrored.

There was no obvious increase in noise levels with the Asus card, which is nice.

It's definitely far from perfect though. There are some noticeable artifacts when watching HD video, for example, and some minor tearing while running the game Dungeon Defenders. But at the moment I'm going to take "everything's working and it was easy to set up" over "pixel perfect display". Maybe if it annoys me enough I'll investigate some more, but I'm happy to run as is for the time being.

Update 15/6/2013:

Some months later, I've still been unable to resolve the tearing issue. It also occurs when scrolling up or down in web pages as well as in games/video, and is frustrating beyond belief that such a trivial action causes screen tearing with vendor-provided drivers.

The issue occurs on multiple computers I've used, all with different hardware and distros, so I can only conclude that nVidia's driver is broken.

Update 3/7/2013:

Forgot to link to it, but I ended up fixing the tearing issue. Unfortunately, I found it only worked with Mint/Cinnamon rather than Xubuntu.

AMD HD7770 GPU in Linux

---

Update (Oct 2013): For anyone who stumbles across this, I've posted an update where I got the proprietary driver to work acceptably (but only on single screen).

---

After researching and asking around on forums about GPUs and Linux, I decided to get an AMD Gigabyte HD7770 1GB as an experiment. From what I could gather, AMD support in Linux was pretty bad, (or at least, more problematic than nVidia cards), so I went in with low expectations, willing to wear the difference of flogging it off secondhand if it didn't work out.

TL;DR: It wasn't all bad, but nothing "just works" (as was pointed out in forum responses). From my experience, I have to conclude that the AMD Linux drivers are effectively broken at the moment.

Rationale

Despite being warned away from AMD cards, the 7770 is an entry-level gaming card and not overly expensive. It was also overkill for the games I expect I would be trying to play (of which there isn't a huge selection on Linux yet anyway).

Since it wasn't too expensive ($119), I was willing to take the risk and try it out, partly for the chance to experiment, partly because AMD are reckoned to be good value for money in that price range, and partly because AMD at least supports an open source driver (for varying degrees of "supports").

Machine and OS Specs

Hooked into the i5 3470 system I built in December 2012, running LinuxMint 14 (Nadia) Cinnamon 64-bit.

On with what I found.

Card Installation

Quick and easy. Dropped right into the PCI-E slot without the firm coaxing that RAM and SATA cables usually need. I chose the second port because it looked like the USB 3.0 cable might get in the way of the card. After I put it in, I thought it probably wouldn't have been a problem, but I left it where it was.

Plug in the 6-pin power cable and away we go.

Note: If I'd got the slight less powerful 7570 (which I was considering) I wouldn't have needed the power, but I got a beefy PSU and it seemed a shame to not try out some of those cables sitting around in the bottom of the case).

With the GPU plugged in the on-board graphics is disabled. This is (I gather) expected behaviour.

Open Source AMD Video Driver

Single Screen

After plugging in the GPU and booting up, I didn't have have to do anything in particular. LinuxMint 14 has drivers installed by default to drive the GPU.

First test I plugged into the DVI port. It started up fine at full resolution.

A command you can use to see how the system has detected your GPU is:

    lscpi --nn | grep VGA

Mine displayed "[Radeon HD 7700 Series]"

Dual Screen

Then I added in the second monitor. If you've ever heard someone claim the dual-monitor support in Linux is limited, you can believe them.

Initially with both plugged in, only the HDMI monitor would work. The other monitor (plugged into the DVI, which was originally working), displays its "Current input timing not supported by monitor display" message.

I worked out how to get things going by using xrandr, a command-line tool that configures the displays.

By itself, executing xrandr outputs details about the detected displays. You need to know the "names" the system has given the monitors plugged into each port in order to control their output settings. In my case, the monitor plugged into the DVI port was "DVI-0", and the one plugged into the HDMI port "HDMI-0".

To make my main screen on the left and the second screen on the right, I used the following command:

    xrandr --output DVI-0 --auto --output HDMI-0 --auto --right-of DVI-0

This works, but leaves the taskbar on the right hand side screen (HDMI-0 in this case). To make the system use a particular screen as the "primary", use the following command:

    xrandr --output DVI-0 --preferred --auto --primary

This shifts the taskbar to the DVI-0 display.

Saving Dual Screen Setup -- Attempt 1

So, after using these commands to set up the displays as desired, I had to work out how to make the changes permanent. The "normal" way to do this (if that's the right word) is to put the configuration into the /etx/X11/xorg.conf file.

Using this answer, I adapted a minimal xorg.conf file and came up with this:

Section "Monitor"
  Identifier "First monitor"
  Option     "PreferredMode"   "1920x1200"
EndSection

Section "Monitor"
  Identifier "Second monitor"
  Option     "PreferredMode"   "1920x1080"
  Option     "RightOf"          "First monitor"
EndSection

Section "Device"
  Identifier  "Radeon HD 7700 Series"
  Driver      "radeon"
  Option      "DVI-0"   "First monitor"
  Option      "HDMI-0"   "Second monitor"
EndSection

Something went wrong when I ran it though. At least, the HDMI-0 monitor got a new name, and became "HDMI-3". So it didn't quite work.

Saving Dual Screen Setup -- Attempt 2

Next I thought I'd try and set things up with xrandr, then go into the Preferences/Display dialog and use the "Keep current configuration" option to save the setup.

This creates a monitors.xml file in ~/.config with the current settings. However, it only applies after you login. The HDMI screen, if plugged in, always seems to be considered the "primary".

Saving Dual Screen Setup -- Give Up

I tried a couple of other wild and fancy things that I found on various sites to set up dual screens, but in the end just gave up. No matter which way I plugged the monitors in, if the smaller 23" LCD was attached, it was the one that "lights up" for the splash screen. After login the 24" came to life, but not before.

I couldn't work out how to get both screens going at the system level, rather than the user level, so I gave up.

Open Source Driver Performance

First test was running a fullscreen 1080p video. It ran with lots of glitches and jaggies when playing. The CPU went up to 50-55 degrees on all cores -- was is actually processing in software?

Then I downloaded the Phoronix Test Suite. The suite package itself is reasonably small, but the full test suite takes over 5GB of download and can take a few hours. I managed to run a few of them, but none of them ran very well. For example, Nexuis looked like it was running at about 0.1 FPS.

It was clear that, unfortunately, the open source driver was not even close.

Proprietary AMD Video Driver

It seemed I could choose between the Catalyst driver from AMD's site, or one of the fglrx drivers that were listed in the software centre. I still haven't worked out what the difference between these two things is -- I think they're related in some way, but I'm not sure how.

So after looking at askubuntu.com/questions/142627, I did:

    sudo apt-get install fglrx-updates flgrx-amdcccle-updates

Bam! Upon reboot, the video was completely broken. I could see the motherboard post, and then nothing -- not even a prompt. The onboard video also wasn't working (at the time I didn't realise you have to unplug the GPU completely for the motherboard to activate the onboard video).

So, at a loss, I booted up and started typing blind the following steps:

• Reboot
• Ctrl-Alt-F1 (open a console, that wasn't visible at all)
• Enter username
• Enter password
• sudo apt-get -y remove --purge fglrx-updates
• Enter password again (for the sudo)
• <wait>
• sudo reboot

Fortunately, this fixed the problem. So I can't really recommend installing the fglrx-updates variant of the driver.

Next I tried installing the Linux Catalyst driver from AMD's website. This was version 12.11beta at the time (see upubuntu.com/2012/08/install-amd-catalyst-128-on-ubuntu.html for the steps I followed).

This driver seemed to work fine (it at least didn't black out my screen) but came with the "beta" watermark in the bottom right. To get rid of that, follow the instructions at askubuntu.com/a/216730.

Dual Screen -- Proprietary

Unfortunately, getting dual screens set up with the proprietary driver was, if anything, more difficult than with the open source driver.

I tried the following mechanisms:

• Steps at unixmen.com/howto-install-ati-driver-in-ubuntu
• Then superuser.com/questions/395927, but the Virtual 3820 caused tearing when the taskbar animated up
• Then I used arandr to get the 2nd display going
• Then I tried the amdcccle (admin) application to apply "Digital Monitor(2) -> Adjustments -> Scaling (0%)" This resulted in another refresh problem on the second monitor, where it would only update while the taskbar on the primary screen was animating during hover.

So I gave up on the dual screen idea in order to get some testing done for the driver. With the dodgy dual screen setup, running the test application fgl-glxgears got 500-600 FPS, but was very choppy.

Proprietary Driver Performance

To revert to a single screen, I entered the following at the command line:

    aticonfig --initial -f

Now running fgl-glxgears got around 2500-3000FPS. So, same driver but running with only a single screen instead of dual screen improved the performance of this benchmark application by 6x, and it no longer looked choppy. But this is a pretty simple little application, I wanted something with a bit more meat.

So I installed xonotic and ran it up fullscreen (1920x1200) with the highest settings I could set. Within the game is ran just fine (too fast for my old hands), but my old eyes couldn't discern any difference between the "default" versus the "high" settings, so I'm not sure if I did it right.

But, after running this (or, it seemed, any "fullscreen" game), the taskbar animation back in the desktop became choppy and caused tearing all over the screen.

Last Ditch

All this playing had taken a couple of weeks by this stage. I got recommended to run the sgfxi script at smxi.org (a "fix it all" graphics driver script). When I downloaded it and ran, it exited saying I needed to run it from outside X.

Which was fine, I thought, so I tried to Ctrl-Alt-F1 into a console. But I couldn't see the console, at all. I could see the X session, but none of the TTY console (1 through 6) were working.

Somewhere along the way I'd borked those. By this time I'd had enough "experimentation".

Blew away Mint. I'm now running Xubuntu with the onboard video. Anyone want to buy a barely used Gigabyte HD7770?

Conclusion

My experience has led me to conclude that both the open source and proprietary drivers for AMD GPUs on Linux are broken. The Intel drivers for the onboard video aren't without their quirks (for example, I find it really hard to configure the login screen to start on a specific monitor at a specific resolution, and setting up dual monitors is still a bit of a chore). But for the most part they work.

With the AMD proprietary drivers I had crashes, no screen at all for a while, and dual screen setup was diabolical. With the open source driver I had tearing and I wasn't quite sure it was actually using the GPU to do anything.

Hopefully I'll get an nVidia card at some point to get another perspective, but I'll be starting with pretty low expectations.