Intel Burn Test + Prime95 = Error?

[aigomorla]

Meh.. okey i was wrong..

OP if it means anything i cant get ANY of my systems to run both programs at the same time.

So i have the same problem as you do.

However in all my years building and overclocking, my machines rank as one of the most stable on the forum.

So the call is yours.

Run the tests 1 by 1, and she will pass everything.
Even throw it on WCG and F@H all my results are valid.
She's on 24/7 and only reboots on windows updates.

Throw both tests on, and i BSOD and reboot.

Windows 7 12GB DDR3, eVGA Classified.

 

[n7]

Why in the world are you running both at the same time?!

I'm sorry, but there is no way they are designed to work that way.

 

[aigomorla]

Why in the world are you running both at the same time?!

I'm sorry, but there is no way they are designed to work that way.

*sigh*...

Help... i need help... LOL...

 

[n7]

*sigh*...

Help n7... LOL...

I'm with you on this one.

I don't care if it works for some people, there is no way IBT/LinX can optimally work with P95 at the same time, regardless of how perfectly the OS handles the load of them both.

That's not to say there isn't some instability due to something else, which is more likely...

 

[aigomorla]

yeah i was also sure its because of how IBT was made. :\

But i did tell the public, show me a screenie on anything, and i'll apologize and shut up.

 

[daw123]

i'll elaborate on this later. goodnight.

Is that the standard STI you have as your wallpaper or the Type-25?
http://www.type-25.co.uk/engine.asp#2

 

[VirtualLarry]

yeah i was also sure its because of how IBT was made. :\

But i did tell the public, show me a screenie on anything, and i'll apologize and shut up.

To be fair, my screenshot was of OCCT and Prime95, not IBT and Prime95. There still might be some issues there, but my bet is on IBT being buggy in general when selecting 100% of RAM. I've never gotten it to run sucessfully on 100% of RAM on a 32-bit OS like XP.

 

[aigomorla]

but hyperlite did show it.

Guys, the best way to crush my ego is via screen shot.

After that i will admit im wrong and back down.

I am human after all.

 

[Voo]

Sounds more like a bug in IBT or Prime but anything else. After all the way the OS schedules processes so you won't run into any problems just by running two extremely demanding processes at the same time - iirc Windows uses RR for processes of the same priority so both will get their timeslice and not more or less.

The same goes for memory.. if a program can't allocate enough, that should be handled properly and not just result in a crash.


There are limitations by the OS like the maximum number of threads, handles and so on, but neither should be a problem.


So could someone explain to me, where the inherent technical problems lie? Yeah it may be useless to run both programs at the same time and what not, but I'm more interested in the technical reasons - after all you can't learn enough..

 

[Brunnis]

So could someone explain to me, where the inherent technical problems lie? Yeah it may be useless to run both programs at the same time and what not, but I'm more interested in the technical reasons - after all you can't learn enough..

Simply put, there aren't really any technical problems. At least none that will cause calculation errors. Those errors are either caused by bad software (as you said) or hardware. It's kind of surprising to be reading a thread on Anandtech where some people believe that miscalculations are expected when running a few programs that load up the CPU to 100%. Fortunately, for all of us, it doesn't work that way.

As for the problem at hand, it seems Intel Burn Test (or Linpack) is buggy somehow. It's quite well known that Intel Burn Test errors out at some settings. For example, running 64-bit, Very High, 8 threads on my Core-i7 860 always errors out no matter what clocks I use. The simple fix is to manually set Intel Burn Test to use 16 threads.

Below is a test that ran while I was writing this response. Prime95 running 8 threads (In-place large FFTs) and Intel Burn Test running 16 threads (using 4GB RAM). As you can see, Intel Burn Test has not failed even after the third pass. Windows seems to schedule much more CPU time to Intel Burn Test, so Prime95 almost grinds to a halt. However, as expected, everything still runs without any errors.

 

[Hyperlite]

Simply put, there aren't really any technical problems. At least none that will cause calculation errors. Those errors are either caused by bad software (as you said) or hardware. It's kind of surprising to be reading a thread on Anandtech where some people believe that miscalculations are expected when running a few programs that load up the CPU to 100%. Fortunately, for all of us, it doesn't work that way.

As for the problem at hand, it seems Intel Burn Test (or Linpack) is buggy somehow. It's quite well known that Intel Burn Test errors out at some settings. For example, running 64-bit, Very High, 8 threads on my Core-i7 860 always errors out no matter what clocks I use. The simple fix is to manually set Intel Burn Test to use 16 threads.

Below is a test that ran while I was writing this response. Prime95 running 8 threads (In-place large FFTs) and Intel Burn Test running 16 threads (using 4GB RAM). As you can see, Intel Burn Test has not failed even after the third pass. Windows seems to schedule much more CPU time to Intel Burn Test, so Prime95 almost grinds to a halt. However, as expected, everything still runs without any errors.

that's what i found too. IBT definitely, somehow, manages to get priority. It finished two runs and orthos hadn't even started the task on the second core until like 10 minutes in.

 

[JACKDRUID]

I'm with Aigo on this one.

I would guess one application would time out, if it doesn't acquire required resource for an extended amount of time, therefore result in error.

 

[Brunnis]

I'm with Aigo on this one.

I would guess one application would time out, if it doesn't acquire required resource for an extended amount of time, therefore result in error.

Again, it doesn't work like that. Unless the program is specifically written to time out and throw a calculation error (<--- why wouldn't it say that it timed out, in that case?), it will just slow to a crawl.

Given working software, a calculation error should otherwise only happen if the hardware is malfunctioning.

 

[JACKDRUID]

Again, it doesn't work like that. Unless the program is specifically written to time out and throw a calculation error (<--- why wouldn't it say that it timed out, in that case?), it will just slow to a crawl.

Given working software, a calculation error should otherwise only happen if the hardware is malfunctioning.

almost all applications ever written have some kind of time out mechnism in them. its very possible that a part of the calculation never get processed and the calculation simply timed out (thinking its not possible to take so long to do a calculation) and return incorrect result.

even the windows process thread has a timeout mechnism in them.

 

[Voo]

almost all applications ever written have some kind of time out mechnism in them. its very possible that a part of the calculation never get processed and the calculation simply timed out (thinking its not possible to take so long to do a calculation) and return incorrect result.

even the windows process thread has a timeout mechnism in them.

There's a big difference between threads and processes.

If a process does not have CPU time it can't compute anything or get a timeout, that's just impossible. Realtimesystems have some kind of deadline, but that's uninteresting for most user programs and works different.

Thread timeouts on the other side have a completely different reason (e.g. he tried and can't get something usable) and are much easier to implement..


For Prime, IBT and co it's completly uninteresting how many CPU cycles they get, they just compute some numbers and compare them to known values.. if 100 or 10^6 computations per second, why bother?
If your theory was true, there would be some PCs where the programs would fail just because the PC was to slow (should I try prime on my ancient P3 with 333mhz?)

 

[JACKDRUID]

There's a big difference between threads and processes.

If a process does not have CPU time it can't compute anything or get a timeout, that's just impossible. Realtimesystems have some kind of deadline, but that's uninteresting for most user programs and works different.

Thread timeouts on the other side have a completely different reason (e.g. he tried and can't get something usable) and are much easier to implement..


For Prime, IBT and co it's completly uninteresting how many CPU cycles they get, they just compute some numbers and compare them to known values.. if 100 or 10^6 computations per second, why bother?
If your theory was true, there would be some PCs where the programs would fail just because the PC was to slow (should I try prime on my ancient P3 with 333mhz?)

well, some program may fail and return error messages if it deadlocks.

depends on the way Prime or IBT works, which I'm not sure.

But I would suppose... each of these programs create multiple threads to be assigned to each cores on the CPU. The program comes when IBT threads get priority and Prime gets low priority. each thread 1 computation.

the IBT threads are computed however IBT kept requesting/fetching new threads with HIGH priority. Prime threads gets processed rarely/if at all due to low priority, and eventually a few times out, perhaps due to OS deadlock prevention/mechnism.

its "unintersting" whether you do it on a new or an ancient P3 computer, its just in theory an OS is obligated to have timeout on a thread, to prevent deadlock. I don't know if i'm right or wrong, "interesting or unintersting"... However, the bare fact that each app run fine when executed seperately, and fail when executed together, points to a software issue rather than hardware.

 

[aigomorla]

the IBT threads are computed however IBT kept requesting/fetching new threads with HIGH priority. Prime threads gets processed rarely/if at all due to low priority, and eventually a few times out, perhaps due to OS deadlock prevention/mechnism.

That is my EXACT thinking...

I know the OS divides up load. Im not arguing with you guys on that.
Its that IBT always takes 1st.

The prime tries to calculate, it has a timeout on it.
When prime times out, it fails. :\

Thats what i thought would happen, and ive seen happening.

 

[Voo]

well, some program may fail and return error messages if it deadlocks.

The whole problem has nothing to do with a deadlock - so no OS or program would detect one.. because it doesn't exist.

The program could throw a error message if a thread takes too long to do something, but that's not the same as a deadlock and would be a rather silly implementation.
I do not have the source code for Prime or IBT, but I'd say chances are good that the main process starts the given number of threads and let them compute till he get's an error message from one of the threads (and the thread itself can't find out how many CPU cycles it get's - it could save the systemstarttime before a computation and check with the current time to see how much time it took, but I don't think anyone would implement something like that without a really good reason - and it would need an own thread to check it periodically and not just between some steps) and then tells them to stop.

I don't think anyone would implement something like that without a really good reason and I can't see one

I'm not sure how windows handles deadlock detection (for sure it does not prevent them.. make sure to inform me first if you solve the halting problem so I can be the first to congratulate you), but the detection alone is a complicated problem (just to find out if a directed circle is a DAG takes O(n^2) and resolving a deadlock after you found one isn't easy either - graph theory how I love you ~~). But would be extremely interesting if you had some information about that topic in modern OSes.


Oh but we already had the fact, that there isn't anything here which qualifies as a deadlock anyhow (coffman..) , so that's really not interesting here.


I agree it could be a software issue, because we all know that IBT is rather buggy, but I'd look for less esoteric reasons why it fails (buggy memory allocation, concurrency bugs - pick one^^)

 

[JACKDRUID]

it is exactly the same as a dead lock because both softwares asks for infinite amount of cpu time and memory threads and REFUSES to release any resources, thats how stress tests work.

I'm not sure how Windows detects deadlock if at all, however I'm pretty sure it has some sort of avoidance techniques such as ... time out on threads...

 

[theevilsharpie]

it is exactly the same as a dead lock because both softwares asks for infinite amount of cpu time and memory threads and REFUSES to release any resources, thats how stress tests work.

The app can request the resource, but the OS decides how much it will get. Unless you've set the scheduling priority for a process to realtime, the OS will interrupt when it's scheduled processing window is over.

 

[aigomorla]

The app can request the resource, but the OS decides how much it will get. Unless you've set the scheduling priority for a process to realtime, the OS will interrupt when it's scheduled processing window is over.

thats the thing... burn test wont let it be over.

Then its not called a Burn Test.

 

[theevilsharpie]

thats the thing... burn test wont let it be over.

It's not up to the burn test, it's up to the OS. If you were to run the test and then set it's CPU priority to low, any other process on the system would interrupt it whenever it needed CPU time.

Distributed computing applications like Folding@Home work on this very principle.

 

[aigomorla]

If you were to run the test and then set it's CPU priority to low,

then that's called allocating resources...

 

[theevilsharpie]

then that's called allocating resources...

For processor priorities below realtime, windows will automatically adjust the priority of a process up or down slightly to prevent a single process from starving other processes of CPU time.

Let's pretend we're running Prime95 and IBT at the same time. By default, they will both run at Normal priority. Since Windows will adjust the priority of both processes up or down to prevent either from completely monopolizing the processor, both Prime95 and IBT will end up with about 50% of available processing power. This should be enough for both programs to avoid any delays that would cause program execution to time out.

 

[Hyperlite]

For processor priorities below realtime, windows will automatically adjust the priority of a process up or down slightly to prevent a single process from starving other processes of CPU time.

Let's pretend we're running Prime95 and IBT at the same time. By default, they will both run at Normal priority. Since Windows will adjust the priority of both processes up or down to prevent either from completely monopolizing the processor, both Prime95 and IBT will end up with about 50% of available processing power. This should be enough for both programs to avoid any delays that would cause program execution to time out.

See the odd thing here is that isn't what happens in practice. Try it. IBT snuffs p95 out.