Originally Posted by DJ4g63t
This question might be borderline stupid but does having the correct Xeon microcode help at all with overclocking?
It should not be relevant for overclocking, at least if you set all the voltages and settings manually. But maybe something is detected wrong (a voltage or a strap setting you may not be able to change in BIOS) and that will result in a bad behavior like not running stable even at stock speed.
And it depends on how your mainboard handles an undetected CPU without or with outdated microcodes. I think the only thing to say is that the latest and correct microcodes will not hurt your overclock.
What I saw in your screenshots is that you are too missing all the features like SSE4.1 and VT-x. So I guess you use a BIOS without the latest microcodes.
Does somebody have a list for what the platform number for the microcodes stand for? For some CPU IDs there are hell of a lot of platform IDs.
For example the 10676 has platform 1, 4, 10, 40 and 80 and the 006FB has additional 8 and 20 in the microcode file I downloaded directly from intel.
I guess that platform is for the socket type, am I right? Like 775, 771 and mobile ones like Socket M or P or something like that.
And as far as modding Award BIOS files like the ones for GigaByte boards (EP35, EP45 aso.) goes ... there may be a problem if your original BIOS already has codes for your Xeon, but are outdated. With the methods posted at the beginning of this thread you just add new codes, but the old ones still remain in there.
I found that out using the latest BIOS I could find for my EP45-UD3P Rev 1.0 (1.1 also supported) F11d. That BIOS already had the Xeon codes in it, but they were outdated and I could boot but SSE4.1, VT-x and full EIST functionality was missing. Also some C-States were missing or wrong in BIOS, I guess ... didn't check on these.
So I added the updated codes and there was still no change, so I guess the BIOS maybe uses the first microcodes it finds that match.
That's why I went the hard way and used a HEX editor on the NCPUCODE.BIN (<- that's the part with the microcodes you extract with CBROM out of you BIOS). Then I went looking for the positions for the specific modules. Every module has a fixed size in kBytes like 2048 or 4096 or 8192 aso. So I took the updated modules and pasted them right over the old ones already in the NCPUCODE file. I double checked before I did that the start and end position in the HEX editor and checked the string for the correct CPUID like 7A 06 01 that stands for 1067A.
Regarding that discussion a week back about stress testing for stability with prime and other tools, I get what you are trying to say. As far as I understood from your posts you think it is best or at least not worth it to just get a quick and stable overclock result. And I agree with you that stressing the system with high voltages and temperatures may not be a good thing to do as it may degrade your CPU and other components like chipset, mainboard components like voltage regulators, capacitors and some more as well as the PSU. But having to stress the system for a few hours really shows if your system is stable. I don't question your method and I trust your statements that your system is stable, but to test the system under unusual high load proves it. Games and applications do stress the system quite different so it may seem stable for some games and programs and then you have a game or program that crashes or shows weird behavior. And I don't want that and then have to find out what causes the problem (sometimes at first it seems to be a software problem and you try differnt drivers and settings, test you memory, maybe even swap the PSU until you find out it's your assumed stable overclock).
I use Linpack LinX - that seems to stress the system more than prime and (what I think is important) has short idle / loading states between the runs. That's important to see if the power phases/voltage regulators/and maybe even the PSU are stable when the system switches between idle and load. That's when a lot of cheaper mainboards fail because of the spikes the voltage may hit (upwards AND downwards).
So anyway, you may advise people how to get their system stable quite fast, but recommending somebody to not use prime for stability testing is wrong. You may tell people that stressing the system with high voltages may not be good for their hardware so that they can decide for themselves if they do it or live with lower settings.
The P5LD2 boards use a 945P or G chipset which wasn't designed for the Core 2 CPUs. Some Rev 2 Boards support the first Core 2 Duo CPUs, but I guess because of the power regulators Quads would not work.
As you can see even some of the P965 or G965 chipset boards have problems.Edited by Bucho - 3/27/14 at 3:19am