Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Success: 2006 Mac Pro upgraded - 2 x Xeon 5355 Quad-cores!

I used one of those screwdrivers that takes ¼" hex bits. It's 190 mm long and I remember it being plenty long enough. I reckon you'd get away with 150 mm. Also, it's 9.5 mm in diameter and I remember thinking that if it were any larger, then it wouldn't fit down the channel in the side of the heat-sink.
 
instead of buying an expensive super-long screwdriver, do what I did. I used a regular interchangeable head screwdriver like this:

814906.jpg


and a magnetic bit holder like this to add more length:

mag_drill_bit_holder_200_07.jpg


works perfectly.
 
bozz2006 said:
instead of buying an expensive super-long screwdriver, do what I did. I used a regular interchangeable head screwdriver like this:
Click to expand...

For some reason I thought I read somewhere that normal screwdrivers like that were too wide. I've already got one of those so that's one less thing needed. :)
 
x5130 VS x5355 XBench comparisons

Hi,

I'm going to find and install x5355 into my Mac Pro 1,1 anyway so this request won't really influence that decision. In the meantime, I am curious as to what the increase will be according to XBench.

Yes I know XBench isn't the best way to compare, but it's quick, easy and gives a snapshot of how fast the machine is.

With that in mind, here are my XBench resullts using x5130 CPUS. Can someone who has done the upgrade to a pair of x5355 post their XBench results too please?

CPU Test 187.86
GCD Loop 313.51 16.53 Mops/sec
Floating Point Basic 153.29 3.64 Gflop/sec
vecLib FFT 122.10 4.03 Gflop/sec
Floating Point Library 295.10 51.39 Mops/sec
Thread Test 472.45
Computation 425.58 8.62 Mops/sec, 4 threads
Lock Contention 530.92 22.84 Mlocks/sec, 4 threads
Memory Test 153.46
System 174.71
Allocate 378.12 1.39 Malloc/sec
Fill 144.69 7034.99 MB/sec
Copy 131.32 2712.42 MB/sec
Stream 136.82
Copy 132.72 2741.38 MB/sec
Scale 131.88 2724.57 MB/sec
Add 142.90 3044.18 MB/sec
Triad 140.44 3004.34 MB/sec
Quartz Graphics Test 233.34
Line 175.55 11.69 Klines/sec [50% alpha]
Rectangle 234.44 69.99 Krects/sec [50% alpha]
Circle 198.63 16.19 Kcircles/sec [50% alpha]
Bezier 209.51 5.28 Kbeziers/sec [50% alpha]
Text 602.93 37.72 Kchars/sec
OpenGL Graphics Test 223.67
Spinning Squares 223.67 283.74 frames/sec
User Interface Test 309.07

Much appreciated.
 
OK, I have tried mixing one x5365 (4x3.0) and one original 5150 (2x2.66) - it does not work and MacPro won't even start. One CPU in CPUB socket works just fine so I have covered CPUA socket with a piece of antistatic film and placed its heatsink back over the empty socket. I think removing unused heatsink is a bad idea because it disrupts the airflow through an active one as airflow follows the path of least resistance (=hole.)

So far I have migrated from two dual core 2.66 to one quad core 3GHz. Speed has increased and temperatures have dropped across the board.
While at it I have found a cable at the bottom of the memory cage that had one of its wires' insulation stripped by sharp edge of the cage (during factory assembly) and making contact with the metal case [fixed now] :eek:

So overall I am very happy having moved from 2 x 5150 -> 1 x 5365.

Now I need to chase another X5365 but no pressure now.

Good side of such upgrade path is that you can buy one 5365 and then sell a pair of 5150s while looking for another 5365 (if you want full monty) and enjoy upgrade in stages...

Temperatures shown under continuous full load (4 thread CPUTest / glucas.) Notice how cool all memory modules "A" are now - as they are in the slipstream of inactive CPU.
 

Attachments

  • 1x5365.png
    1x5365.png
    95.6 KB · Views: 317
Congrats Ibodnar to your successfull upgrade. There must be very few Mac Pros out there with your config and it is better than the original. Well done.
 
I am still trying to find a way of loading correct microcode data into a CPU. Here is the way to check if your CPU has been loaded with any microcode data during EFI initialisation.

Open Applications->Utilities->Terminal and type
Code: 
sysctl -a | grep cpu\\.
Here is my result for X5365 SLAED in MacPro1,1:
Code: 
kern.exec: unknown type returned
machdep.cpu.thread_count: 4
machdep.cpu.core_count: 4
machdep.cpu.address_bits.virtual: 48
machdep.cpu.address_bits.physical: 38
machdep.cpu.tlb.data_large: 32
machdep.cpu.tlb.inst_large: 8
machdep.cpu.tlb.data_small: 256
machdep.cpu.tlb.inst_small: 128
machdep.cpu.cache.size: 4096
machdep.cpu.cache.L2_associativity: 8
machdep.cpu.cache.linesize: 64
machdep.cpu.arch_perf.fixed_width: 40
machdep.cpu.arch_perf.fixed_number: 3
machdep.cpu.arch_perf.events: 0
machdep.cpu.arch_perf.events_number: 7
machdep.cpu.arch_perf.width: 40
machdep.cpu.arch_perf.number: 2
machdep.cpu.arch_perf.version: 2
machdep.cpu.thermal.ACNT_MCNT: 1
machdep.cpu.thermal.thresholds: 2
machdep.cpu.thermal.dynamic_acceleration: 0
machdep.cpu.thermal.sensor: 1
machdep.cpu.mwait.sub_Cstates: 8736
machdep.cpu.mwait.extensions: 3
machdep.cpu.mwait.linesize_max: 64
machdep.cpu.mwait.linesize_min: 64
[COLOR="Red"][B]machdep.cpu.microcode_version: 0[/B][/COLOR]
machdep.cpu.cores_per_package: 4
machdep.cpu.logical_per_package: 4
machdep.cpu.extfeatures: XD EM64T
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM SSE3 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM
machdep.cpu.brand: 0
machdep.cpu.signature: 1787
machdep.cpu.extfeature_bits: 537919488 1
machdep.cpu.feature_bits: -1075053569 320445
machdep.cpu.stepping: 11
machdep.cpu.extfamily: 0
machdep.cpu.extmodel: 0
machdep.cpu.model: 15
machdep.cpu.family: 6
machdep.cpu.brand_string: Intel(R) Xeon(R) CPU           X5365  @ 3.00GHz
machdep.cpu.vendor: GenuineIntel
Microcode version is 0 after CPU is powered on but would reflect update version after successful update. As I said before, it shows zero here because 2006-2008 MacPro EFI does not have update data for later processors - even when Apple released EFI updates for them. Intel publishes microcode updates quite often (few times a year for each CPU model) but has never opened information about what problems each microcode revision fixes but there are a lot of speculations and these updates are apparently strongly recommended for 51xx and 53xx Xeons. Running un-initialised CPU means that otherwise avoidable errata cannot be ruled out as a reason of any system crash.

Linux systems allow to upload microcode data into the processor. I wander if OS X security model allows for similar utility to be written? Microcode does not have to be done in EFI but OS must allow this kind of operation.

Leo
 
Congrats!
I'm following this thread almost from the start and i was thinking about 2x X5355 upgrade, but it's hard to find them for a good price (as you all know).

I also have MP 1.1 with 2x 5150, and i have opportunity to buy one X5365.
I'm wondering is it possible to use 1 CPU config in everyday work (before i will get the second one)? It's my main machine, so it's good to know that before upgrade like this ;)
Can you post any Geekbench score after upgrade to 1x X5365?
Thanks in advance.
 
Geekbench test is about 6000 and before upgrade it was about 5200.
Cinebench has also increased proportionally. Apart from the speed increase I can't see much difference from previous 2x2.66 configuration.
 

Attachments

  • Geek.png
    Geek.png
    77.4 KB · Views: 165
When you do drop in the second processor, watch your temps. I upgraded my 2ghz quad to a 2.33 octo (sold it later) and my temps jumped 10 to 15 degrees. Had to bump up the fans. Would have kept it if there was a way to change the efi to 64 bit. Currently happy with my 2.8 mac pro.
 
Temperatures seem to be OK. SMC does a good job keeping them at bay. It speeds up fans to either keep RAM modules below 80ºC (for memory intensive tasks like CPUTest) or CPU case below 65ºC (for CPU intensive ones like Handbrake.) I have looked through X5365 datasheet and this is within spec.

In fact, my fan speeds have dropped after the upgrade and I am very glad to see my Northbridge running at 63ºC. I am not sure I really need second X5365 at all. I only do video compression once a month or so. Given the fact that I have bought X5365 on eBay for $100 shipped (with BuyItNow) :eek: this is not a bad reshuffle.
 
Microcode update

OK, I must be the only one concerned about this. But I will document my progress anyway...

I have downloaded current Intel update file and found that most recent microcode version for X5365/SLAED X5355/SLAEG stepping G0 (CPUID 0x6FB) is version 0xB9 released on November 5th 2009.

Having researched OS X security model I have discovered that user space application cannot access CPU wrmsr instruction required to initiate the update process. It just causes segmentation fault. So I have created a simple proof-of-concept kernel extension (.kext) that loads manually, updates the CPU and exits. I have to run (load/unload to kernel) it a few (=4) times for the new microcode to "stick". Maybe this is related to the number of cores even though I was under the impression that update is required only once per physical CPU. Anyway, it works if implemented properly. Also, when Mac goes to sleep its CPUs power down and get reset so proper microcode KEXT needs to reinit the upload after each wake up.

I wish some kernel developer gave us some help here... Given the fact that Apple updates EFI microcode very rarely it might be useful to any Intel based Mac.
 
Modern processors are complicated digital circuits run by internal state machine controlled by microcode. It is impossible to extensively debug the processor until it is released as a silicon chip. E.g. list of currently discovered problems with 5300 series Xeons is a 54 page document (known knowns). By the time bugs are found it is impossible to change the silicon masks. This is where microcode update comes into play - it's a way to patch some of internal CPU operation by uploading a reversible update.

Intel never admits to what problems each new update fixes so I assume they don't make it into the above document (known unknowns?)

Typically BIOS or EFI uploads microcode into the CPU when system boots. Otherwise it can be updated by the OS. There was a scare in 2007 when serious bug was found affecting most Intel CPUs and even Microsoft released a system patch that would update microcode if BIOS fails to do so. They obviously did not want to be blamed for random system hangs. Apple updated EFI almost simultaneously on many Intel based Macs fixing "stability issues" which makes me think that it has something to do with Intel...

Now MacPro1,1 and MacPro2,1 do not have microcode data for many Xeons including X5365 and X5355. Running them unpatched is like ignoring all errata that has been found and fixed for the last 2-3 years.

Frequently asked questions
Q: What issues are fixed by the microcode reliability update?
A: The microcode reliability update fixes the following issues:
- possible Intel processor marginality
- potential source of unpredictable system behavior
- "stop 0x7E" error that may occur during startup on some systems that are running an older Pentium 5 CPU (This issue occurs only in the 32-bit version of Windows XP and in the x86-based version of Windows Server 2003.)

Q: How do you know if the system needs the microcode reliability update?
A: Although these issues are uncommon, you may receive a Stop error, or you may experience unpredictable system behavior.

Q: What errors occur?
A: You may receive a Stop error, or you may experience unpredictable system behavior.

Q: Which Intel processors are affected?
A: Although these issues are uncommon, the following Intel processors may be affected:
Mobile: Intel Core 2 Duo mobile processor.
Desktop: Intel Core 2 Duo desktop processor, Intel Core 2 Quad desktop processor, and Intel Core 2 Extreme processor.
Server: Intel Xeon processors 3000, 3200, 5100, and 5300 series.

Q: If you install the microcode reliability update, do you still require the latest BIOS update?
A: If you install the microcode reliability update, you do not require the latest BIOS update.

Q: Does the microcode reliability update have to be proactively installed?
A: Affected Intel processor users must use the microcode reliability update.
Click to expand...
 
lbodnar said:
I have downloaded current Intel update file and found that most recent microcode version for X5365/SLAED X5355/SLAEG stepping G0 (CPUID 0x6FB) is version 0xB9 released on November 5th 2009.

Having researched OS X security model I have discovered that user space application cannot access CPU wrmsr instruction required to initiate the update process. It just causes segmentation fault. So I have created a simple proof-of-concept kernel extension (.kext) that loads manually, updates the CPU and exits. I have to run (load/unload to kernel) it a few (=4) times for the new microcode to "stick". Maybe this is related to the number of cores even though I was under the impression that update is required only once per physical CPU. Anyway, it works if implemented properly. Also, when Mac goes to sleep its CPUs power down and get reset so proper microcode KEXT needs to reinit the upload after each wake up.

I wish some kernel developer gave us some help here... Given the fact that Apple updates EFI microcode very rarely it might be useful to any Intel based Mac.
Click to expand...

So with advanced kernel programming knowledge one could slip the latest micro code into the system without EFI modifications. Presumably this would not only fix the latest errata but also make the machine find the new CPUs in profiler?
 
gugucom said:
So with advanced kernel programming knowledge one could slip the latest micro code into the system without EFI modifications. Presumably this would not only fix the latest errata but also make the machine find the new CPUs in profiler?
Click to expand...
Yes, this would fix known CPU problems but hardly make it appear in the profiler as its CPUID and stepping would remain the same.
 
Some more interesting news. I have programmatically dropped CPU voltage a little bit and now the processor runs quite a bit cooler (but with computational performance unaffected.) Power dropped too and fans have slowed down. :)

To do that one needs to change the contents of IA32_PERF_CTL msr using e.g. reggie_se from CHUD tools.

Here is comparison between standard and reduced voltage operation with Handbrake running and all temperatures stabilised.
 

Attachments

  • Reduced_voltage_X5365.png
    Reduced_voltage_X5365.png
    89.9 KB · Views: 291
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back