|
| News | Profile | Code | Photography | Looking Glass | Projects | System Statistics | Uncategorized |
Blog |
I'm finally sitting down to blog this, even though I'm being attacked by allergies, and losing the battle.
I recently upgraded my main workstation, destiny from an Intel Core 2 CPU to an Intel Core i7 CPU. Here are the specifications of the new (finished) upgrade:
The only things remaining from my previous setup are an SB Live! PCI card (still sticking with it - it's about 10 years old, now), Antec case, and LG HD-DVD/Blu-ray burner.
I ordered all the parts on March 17, and only got everything working on April 6. Yeah, it was a little bumpy. Let's see if I can recount the whole process.
March 17. I ordered the Intel DX58SO and Core i7-980X CPU from ZipZoomFly since they gave me a combination deal, and I was weary of Newegg shipping me a fake CPU. It didn't ship until the 24th of March, though.
I ordered the video card, ATSC tuner, memory, and SSD from Newegg on the same day.
My Newegg order arrived first, on the 23rd of March. Since I figured it wouldn't be a bad idea to try out some of the components, I threw the Gigabyte card into the current Core 2 system, replacing the cheap nVidia 7600 GS that I'd been using for the last three years. It fit nicely (took up two slots since it's fanless and has a huge heatsink). The HDMI and dual-link DVI-D output worked flawlessly, and Quake 4 seemed nice and smooth.
The next step was to take the current WD 160GB SATA disk and replace it with the new OCZ 256GiB SSD. I opened the package, and was greeted by a cheap box with no papers, manuals, warranty information, or anything. I also noticed that the QC date on the back of the SSD itself said 6.1.99. That can't be right, since SSDs of this size have only been around for the last year or so.
Anyway, I went to plug the drive into a spare SATA connector, when the plastic on the SATA connector on the drive broke! It snapped in such a way that the SATA cable refused to remain connected. Total crap. I sent it back to Newegg for a replacement.
The ATSC card worked fine, though. It's much smaller than my previous one (DViCO FusionHDTV5 RT Gold) and has two tuners. I use it with a pair of bunny ears to grab 8VSB signals from Charlotte. Works great!
The DX58SO motherboard and Core i7 CPU arrived from ZipZoomFly on the 31st of March. I put it all together, noting that the first RAM slots was black, compared to the rest, which were blue. The manual said that there were three channels, but channel A was shared between the first slot and the 2nd slot:
Installing memory in Channel A, DIMM 1 may result in less than optimal memory performance.
Well, that seemed annoying, but I kept all four of them in and installed the CPU. Strangely enough, the CPU heatsink and fan did not look like a standard stock Intel model. It looked more like a 3rd-party heatsink:
Even stranger, was the heatsink installation manual seemed to indicate that the fan on the heatsink should face the power supply. This made no sense whatsoever, so I faced the fan toward the front of the case, where it would blow air through the heatsink toward the rear. After checking online, this is what most people were doing, too. I finished installing everything (minus the SSD, it was still in Newegg RMA-land at the time). After connecting everything to my existing Thermaltake 550W power supply (more on this later), I pressed the power button!
Initially everything seemed to work. The first thing I did was upgrade the BIOS to 5112, since the 4xxx version that came with the board didn't officially support the 980X processor model. After rebooting after the BIOS upgrade I went back into the setup, loaded factory defaults by pressing F9 (remember this - it's important later on in the saga), set the SATA devices to AHCI, and disabled the onboard audio so I could use my SB Live! exclusively.
My Debian GNU/Linux (w/a custom 2.6.32 kernel) installation booted up just fine via a GRUB boot disk (for some reason I can't boot GRUB from the MBR on the disk on the new system and the old Core 2 system, which doesn't bother me too much since I try to never reboot) and X started up nice and fast. I started up some music, and did a couple small test encodes with HandBrake. The system seemed wicked-fast, and running properly!
About an hour into the testing (ie, playing) MPlayer crashed, and my music stopped. I forget the exact error I saw in the kernel log buffer, but it indicated that something had gone horribly wrong with sysfs. I thought that was really odd, but continued playing around. Quake 4 then started crashing, as did almost everything else. I then fired up 6-8 copies of burnP6 (part of the cpuburn package designed to stress-test certain chipsets and CPUs heavily) and the screen went completely blank. Something was obviously wrong.
I decided that maybe one of my memory sticks was bad. I decided to run memtest86, and see what was going on. Sure enough, tons of errors on what looked to be the 2nd chip, although I wasn't certain because I'm not sure how memory is interleaved lately:
I ran memtest86 a few more times and got very inconsistent results. Some times it would show errors immediately, other times it would run for 30 minutes with no problems. I decided to go through the fun process of trying every stick by itself to narrow down the problem. I plugged in one stick and fired up 6 copies of burnP6, HandBrake in an infinite loop, and both my VMs (to use up the 4GiB) running. It had been a long day, so I hit the sack.
The next morning I find the system still running fine! RAM stick #1 was obviously working. I put in RAM stick #2 and let it run through until the next morning - worked fine, too. Unfortunately, the last two sticks checked out, too (I got lazy and only let them go for 3-4 hours each).
I stuck two sticks in (I think I used the first two slots, so they both went in channel A) and the system started to POST, then shut off! It did this a few times, then presented me with a BIOS error saying something like "the system has detected multiple POST failures" and prompted me to enter the BIOS setup. I poked around at memory settings, but really didn't know what I was doing, so I left it at default - autodetect.
I hunted around online, finding posts on Intel's site about DX58SOs dying easily, confirmed compatibility with the G.SKILL RAM modules (F3-12800CL9S-4GBRL) and the DX58SO, but didn't really find anything solid about the issue. I then ran into a few posts about instability issues caused by not enough power. I forgot that I was now running a pretty beefy CPU with decked-out RAM and a power-hungry video card. I went to Best Buy and picked out a Corsair 850 watt power supply.
After installing the new power supply, the system literally took TWO minutes to POST. Unfortunately, it seemed even more unstable than it did with the old power supply! So I threw the Thermaltake back in - and it did the same thing!
At this point it certainly seemed like something non-RAM was bad. I guessed the motherboard, and RMAed it.
I got the new motherboard from ZipZoomFly the same day I got my SSD back from Newegg (April 6). Were the stars aligning for a stable system? Well, maybe.
I threw everything together, but this time didn't populate the "black" RAM slot that would cause unoptimal performance (I learned this was roughly 5%, but I figured it may add to instability, too). Another TWO minute POST - and I got kernel panics at bootup during the USB device detection. Well, looks like the motherboard is good, but something else is bad.
I searched the G.SKILL forums and other places, and found recommendations to maximize RAM performance and overclocking recommendations, which I didn't want to do - I just wanted the system to work fine with the defaults (or baseline, etc). I began poking all around in the BIOS. In the "save changes" menu, I saw two options:
Looking at these, I wondered what was custom defaults? Furthermore, I wondered what F9 actually did, since on the main screen that just said load defaults. After loading custom defaults, I noticed that not much had changed - actually I made a change to the onboard sound (enabled it), loaded custom defaults again, and it didn't change back. Odd. I don't know what made me do it, but I hit F9, then loaded custom defaults, then rebooted. Bam - everything worked - system was stable.
I ran a few benchmarks for a few hours, and it didn't budge.
Apparently the F9 key was actually an alias for optimal defaults, which was somehow overclocking the RAM in my system. Loading custom defaults on top of optimal defaults reset the RAM/CPU timings and clock speed back to normal. I found this strange, since with both defaults auto-detect was still enabled, but the greyed-out settings were notably different. Of course, none of these options were documented ANYWHERE in the manual. Thanks, Intel!
I installed the new SSD (which still had a QC date from 1999 - what the heck?), cloned the old WD 160GB to it, and was able to keep my old Debian installation.
I decided to not take the 5% memory hit, and returned the 4th stick of RAM to Newegg. Of course I think I'm going to get hit with the 15% restocking fee when they receive it, but worse things can happen.
To get the most out of the SSD, I disabled swap, and changed the journal mode on my ext3 filesystems to data=writeback. I suppose in a crash, I'll lose some data, but it won't be as bad as ext2.
As far as benchmarking, meh, since I don't have stuff like 3DMark on Linux, I can't really do it. Here are a couple of tests, though:
% glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 100567 frames in 5.0 seconds = 20113.289 FPS 100770 frames in 5.0 seconds = 20153.916 FPS 100703 frames in 5.0 seconds = 20140.479 FPS 100628 frames in 5.0 seconds = 20125.492 FPS % sudo hdparm -t /dev/sda [sudo] password for prox: /dev/sda: Timing buffered disk reads: 696 MB in 3.01 seconds = 231.59 MB/sec % sudo hdparm -T /dev/sda /dev/sda: Timing cached reads: 18130 MB in 2.00 seconds = 9073.65 MB/sec
I also ran a few encodes from a Blu-ray source to H.264 resized to 720p. HandBrake averaged around 45-50fps. It seemed to use all 12 threads, but only at 50-60% each. Not sure why that happened, but 45fps is fine with me!
I took a boatload of photos during the build process.
I've been getting better at Quake 4, recently, now that it's finally smooth at 2560x1600 w/2x FSAA. Maybe I'll setup a server on dax, again…
The Core 2 guts will eventually move into my Windows 7 box, isis. I suspect I will have to reinstall Windows 7, in the process!
Hi,
what have you done to get 12 threads running under debian. We tried a couple of stuff, but obviously the wrong things. We are still stuck with 8 "cpu"s.
Any hint appreciated
Henry
Hi Henry, I didn't do anything special to get 12 threads recognized by the operating system. All the default Debian kernels have support for 32 CPUs (IIRC), so that should be more than sufficient.
Hi Mark,
thanks for your quick response. Anyway, that is curious. I was also aware that linux has 32 cpu support, but we are running the new MSI X58A GD65 that obviously suffers and is not proper recognized. We tried Knoppix as well, showing only 8 kernels. Seems to be some limitation of the board. We will further investigate.
Thanks
Henry
Hi Mark, we solved the problem. The trick is the 64bit version from debian. You will find no 64bit Intel version, what was the reason for twiddling around with the 32bit version. After we use the 64bit version for amd(!), the system is performing as expected with 12 threads.
Intruder
New comments are currently disabled for this entry.
     |
This HTML for this page was generated in 0.001 seconds. |
If task manager screenshots will be displayed during the different multi-threaded benchmarks, it will be a great deal for me. Also games, so we can see how it utilizes the six cores and two threads per core.
http://www.cdmacellulars.com/