• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Second Core Running Slower Than First?

IsenMike

Member
Every now and then when I run Orthos on my E6600, the first core runs through the tests much faster than the second core. For example, I have currently been running a "Blend" test for about ten minutes. CPU #0 is already into Test 7. CPU #1, on the other hand, is still working on Test 1.

Is this a sign of instability with my overclock? A faulty CPU? Or something else entirely?

Edit: If you read a few posts down you'll notice that the second core actually was not so much running the tests slower than the first as it was halting altogether. About an hour later, there was still no progress on CPU #1, despite the fact that the task manager reported full CPU load on both cores.
 
Affinity is set for both cores. Processor load is 100%, also over both cores.

It's now been running for over 20 minutes and the second core still hasn't finished Test 1. Now I'm starting to think it's no so much "slower" as it is "busted." It'll go back to normal if I reboot, but I'm trying to figure out what's causing this.
 
There?s nothing wrong with that. If it were unstable you wouldn?t pass Orthos and the second core would simply fail.

Due to the constraints of the FSB model as in it?s not fully duplex, I believe the first core takes precedence to each execution and transfer over the FSB, therefore the second core takes longer to transfer and verify the checksum for each test.

 
Intel Thermal Analysis Tool is also reading up to a 4 degree difference (59/55) between the two cores. Usually there's never more than 2 degrees difference when they're both under load.
 
Originally posted by: RichUK
There?s nothing wrong with that. If it were unstable you wouldn?t pass Orthos and the second core would simply fail.

Due to the constraints of the FSB model as in it?s not fully duplex, I believe the first core takes precedence to each execution and transfer over the FSB, therefore the second core takes longer to transfer and verify the checksum for each test.

I usually see the first core finish tests a bit quicker, but to this extreme? 30 minutes in, and CPU #0 has finished 19 tests. CPU #1 still has not finished the very first test.
 
There?s definitely an issue if orthos reports the second core halting on any of the tests for this period of time.

Have you tried reverting back to stock settings and testing again?

What does task manager report when orthos is running? Do both cores show as fully loaded?

Also, try setting the affinity to the second core only, just to see if you can test the cores individually.
 
Originally posted by: RichUK
There?s definitely an issue if orthos reports the second core halting on any of the tests for this period of time.

Have you tried reverting back to stock settings and testing again?

What does task manager report when orthos is running? Do both cores show as fully loaded?

Reverting back to stock wouldn't prove much since it's not a consistent problem. It happens maybe once every week or so, and if I rebooted right now without changing any settings it would go away. Short of changing the settings and waiting a few weeks to see if the problem returns, I'm not really sure how to test for it.

It's not happening so often that I'm extremely anxious to get rid of the problem; I was more just curious if anyone else had seen anything similar and might know what it could signify.

Task manager says that both cores are running under full load.

(Orthos has now been running for 54 minutes, and Test 1 on CPU #1 still hasn't finished. At this point I think it's safe to say that it probably isn't going to finish at all.)
 
Originally posted by: RichUK
Also, try setting the affinity to the second core only, just to see if you can test the cores individually.

I stopped the test, turned off affinity for CPU #0 in the task manager, and started the test again. Six minutes later and it hasn't made any progress on Test 1. Just gives me "WARNING: Affinity Mask: Process: 0x2 Sys: 0x3" every few seconds.
 
I personally wouldn?t worry about it then, if it only happens once in a while

There may just be an error with the Orthos program itself that you are personally experiencing. However, that doesn?t quite explain the difference in temperatures as per your previous explanation.

Perhaps someone else can chime in and explain if they have had this occur to them too.
 
Originally posted by: IsenMike
Originally posted by: RichUK
Also, try setting the affinity to the second core only, just to see if you can test the cores individually.

I stopped the test, turned off affinity for CPU #0 in the task manager, and started the test again. Six minutes later and it hasn't made any progress on Test 1. Just gives me "WARNING: Affinity Mask: Process: 0x2 Sys: 0x3" every few seconds.

You?d need to download an older version of 'Stress prime 2004', one without the Orthos multi threaded support, so you can run the app without it trying to use both cores.

EDIT: Just tried it on mine, and in actual fact it works fine. It keeps coming up with the error messages you mentioned, but it has carried on with the tests and is now on test 3, which is running off of core 1 (with core 0 affinity disabled in task manager).
 
Originally posted by: RichUK
I personally wouldn?t worry about it then, if it only happens once in a while

There may just be an error with the Orthos program itself that you are personally experiencing. However, that doesn?t quite explain the difference in temperatures as per your previous explanation.

Perhaps someone else can chime in and explain if they have had this occur to them too.

It's definitely more than just Orthos. The reason I thought to test with Orthos was that I experienced a sudden performance drop in the middle of playing a game. I thought maybe some background program was crashing, but task manager wasn't showing anything else taking up CPU time, so I ran Orthos to see if it was a stability issue.
 
Well..Your computer doesn't just run Orthos (or Prime95) ONLY while they're running. There are dozens of OS-related threads running at any given moment and those minuscule operations (still probably hundreds of operations per second? Not sure) add up. What about drivers and background apps? NV desktop manager, Anti-virus, firewall, desktop-search, messengers, and what not. In other words, there are still tons of stuff that eat up CPU cycles even when your system look to be idling. An instance of Prime95 running faster than another is absolutely normal. It's especially visible if you're doing anything half CPU intensive work while those instances are running. One core will end up spending more time on other stuff than the other core and that's what you're observing. Trying running Super Pi on one core (by setting affinity in Task Manager) while running dual Prime. You'll see one instance instantly pause while Super Pi is running.
 
Originally posted by: lopri
Well..Your computer doesn't just run Orthos (or Prime95) ONLY while they're running. There are dozens of OS-related threads running at any given moment and those minuscule operations (still probably hundreds of operations per second? Not sure) add up. What about drivers and background apps? NV desktop manager, Anti-virus, firewall, desktop-search, messengers, and what not. In other words, there are still tons of stuff that eat up CPU cycles even when your system look to be idling. An instance of Prime95 running faster than another is absolutely normal. It's especially visible if you're doing anything half CPU intensive work while those instances are running. One core will end up spending more time on other stuff than the other core and that's what you're observing. Trying running Super Pi on one core (by setting affinity in Task Manager) while running dual Prime. You'll see one instance instantly pause while Super Pi is running.

As I said above, I would expect to see some difference between the two cores. But in this case, Orthos ran for about an hour. CPU #0 made it through a couple dozen tests. CPU #1 never finished the first. According to the task manager there wasn't anything taking up nearly enough CPU time to account for something that extreme. Also, it reported both CPUs under full load while running the test, and under basically no load once I stopped the test. So I can't think that the core was simply busy doing something else the entire time.
 
i don't have a dual core cpu but i have an idea:

try running orthos or prime95 on core1 only and see what happens. maybe the shared l2 cache is being all used up by core0 ?

just an uneducated guess.
 
Back
Top