What settings are used in the UBCD version?Is it Small FFT, Large FFT or Blend?

The Prime95 in UBCD is run with the default setting. That is, Blend.

If you want to configure Prime95 before you start, you can run this in your command line:

Code:

/opt/mprime/mprime27 -m -w/tmp/torture-test

The mprime wrapper script will create a temp directory every time you run a torture test. So you can use any working directory besides "/tmp/torture-test".

zerowalker wrote:

Cause it would be nice to be able to choose.

Good idea. I might add that feature in the future.

zerowalker wrote:

As running from DOS (or what it´s called) is much better than inside an OS, as the OS itself takes cycles and ram.

Your argument here doesn't make sense. First, Prime95 doesn't support DOS at all! Second, DOS is an OS, which takes cycles and ram too. You should refer to a self-bootable program instead, but unfortunately few people will develop stress-testing programs for self-booting.

And well what i meant was, i am pretty sure that loading up Windows 7 or similar will Surely take a lot more cycles to keep it up, than DOS.It probably won´t matter so much in the end, but it´s still Better, as more cycles are going to the test.

P95 seems to just start running, I suppose in default mode which is blend.I'd like it to either start with my predefined settings ("In-place large FFTs", all cores, not submitting results) or to ask me (as if typed /opt/mprime/mprime27).

Is this possible and what do I need to add to the custom.cfg file?

EDIT: I found out this page and the key is using -ubcdargs, so the last line should beAPPEND noapic ubcdcmd=mprime27 ubcdargs='-m'and it will bring up the setup dialog.

Now I'm off to actually using this and see how it goes. I wonder if the eventual errors are displayed like in the Windows GUI... would be nice if they were logged somewhere too.

EDIT2:Tried this on a real machine (i5-750) and got a whole lot of kernel panics and errors before even getting to the actual stress test. Sometimes it would work, but mostly not.

EDIT: I found out this page and the key is using -ubcdargs, so the last line should beAPPEND noapic ubcdcmd=mprime27 ubcdargs='-m'and it will bring up the setup dialog.

The next version of CPUstress image (v2.5.2) will support the torture test options without ubcdargs='-m'. I implemented the setup dialog in the wrapper script. If you are interested you can try it here (unpack the replace the old version in the UBCD).

Or just look at the screenshot

ubcdhelpplease wrote:

Now I'm off to actually using this and see how it goes. I wonder if the eventual errors are displayed like in the Windows GUI... would be nice if they were logged somewhere too.

Try finding the results.txt in /tmp/torture-test/torture.* for any mprime log message.

ubcdhelpplease wrote:

Tried this on a real machine (i5-750) and got a whole lot of kernel panics and errors before even getting to the actual stress test. Sometimes it would work, but mostly not.

If you want to report a kernel panic, please state what panic message you see. Taking a screenshot with your camera and uploading here helps.

Try finding the results.txt in /tmp/torture-test/torture.* for any mprime log message.

That file would be stored in RAM for as long as the program is running, right?I'd be more interested in a log file that is permanently saved (to the bootable USB). Especially seeing how on error you might get a kernel panic/automatic restart/freeze.

There's also a blackening of the screen after 10 minutes, which seems unnecessary at best (it doesn't actually turn the screen off) and could make you miss some info on the screen.

I'll see if I can find some more info on the kernel panics and errors. I suspect that some of those could be related to an unstable overclock, but I can't say for sure yet.And if they are, it seems that the UBCD/Linux version of mprime stresses the system significantly more than the Windows version (Prime95 with GUI). Would you say this is the case?

Try finding the results.txt in /tmp/torture-test/torture.* for any mprime log message.

That file would be stored in RAM for as long as the program is running, right?I'd be more interested in a log file that is permanently saved (to the bootable USB). Especially seeing how on error you might get a kernel panic/automatic restart/freeze.

Yes, the file is stored in RAM, and it's there until you restart the computer.I have no plan to add hard drive support in CPUstress image because it will make the kernel unnecessary complex, and there is a hard disk stress test in Stress that is not going to work unless automatic mounting is implemented as well. Enabling hard disk test can also bring a risk of crashing your existing file system. I won't let users do that anyway.

If you want hard disk support, you can simply run mprime in a Linux distribution you have, or run it in a Live DVD.

ubcdhelpplease wrote:

There's also a blackening of the screen after 10 minutes, which seems unnecessary at best (it doesn't actually turn the screen off) and could make you miss some info on the screen.

It can be turned off with parameter consoleblank=0. I'm not sure if I should make it the default or not.

ubcdhelpplease wrote:

And if they are, it seems that the UBCD/Linux version of mprime stresses the system significantly more than the Windows version (Prime95 with GUI). Would you say this is the case?

I cannot tell whether this is true, but it might depend on which kind of test you are running.

Yeah, you make a good point, it's better to keep this simple and without disk support.

Thanks for consoleblank=0, it works fine and IMO it should definitely be there by default. So for anyone stumbling upon this thread, I found that this works as a simple custom entry for quick testing with P95:

Regarding the errors and kernel panics, I found that at least some (if not all) are in fact related to hardware, specifically too low core CPU voltage.But they mostly happen when loading Linux, which is something I didn't expect. I don't mean just the Linux used here, but even more so for loading something like Lubuntu (live CD/USB). It needs at least 0.05 more V than Windows to load. UBCD mprime can start with less, but still needs more than Windows.It seems that booting up Linux is a better stress test than Prime. EDIT: Apparently Linux has issues with some motherboards' implementations of 21x multiplier, which sometimes works through "turbo boost"...

Trying to get to the bottom of those kernel panics, I found out what was causing them:Linux (in most recent implementations, at least) simply ignores the BIOS settings regarding C-states, so if you have disabled those in BIOS, they will be enabled by the OS:http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=migr-5091901Obviously this can mean bad things, especially for some overclocked systems. Here's a related discussion with some practical implications.

Adding intel_idle.max_cstate=0 to the custom Prime config (next to consoleblank=0) makes it usable for me, but this is crazy.Is there an easy way to add this to UBCD in general or to specific bootable distros?

Anyway, don't want to get too offtopic.The bottom line is that Mprime in UBCD/Stress works fine as far as I can tell, but you need to get around some Linux peculiarities (which might not affect all systems, though).

Trying to get to the bottom of those kernel panics, I found out what was causing them:Linux (in most recent implementations, at least) simply ignores the BIOS settings regarding C-states, so if you have disabled those in BIOS, they will be enabled by the OS:http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=migr-5091901Obviously this can mean bad things, especially for some overclocked systems. Here's a related discussion with some practical implications.

Thank you for the info. Actually when I maintain this boot image I have never tried any of the overclocking possibilities. My Google search result show that there are several problem reports regarding C-states and the intel_idle driver. Now if no one objects, I'll remove this driver completely (at compile time) in the next version. (Please wait for kernel 3.16.3, because I have my own policy not to provide two CPUstress kernel builds for the same Linux kernel release.)

ubcdhelpplease wrote:

When I ran my custom mprime test (from a couple of posts back) I couldn't find any files or folders under /torture-test (even after a worker hit an error and stopped running).

Are you trying CPUstress image v2.5.2? The new version no longer puts the config files and log under /tmp/torture-test, but rather /opt/mprime/28/ .And sometime mprime doesn't generate any log file after a test, due to mprime's design. If that's the case, there's nothing I could do.

EDIT: fix a typo.

Last edited by Explorer09 on Thu Jan 29, 2015 4:44 am, edited 1 time in total.

In this case results.txt is at /opt/mprime/ (and I managed to open it ).

Glad that you found it.

ubcdhelpplease wrote:

I'm looking forward to the inclusion of a newer version of mprime (28), though it seems to behave a bit differently when I ran it in Windows, so it might be good to keep 27 there as well.

UBCD 5.3.2 is released recently so you can try it. And no, I won't include three versions of mprime without a definite reason. Mprime binary is a big one. Each of them takes about 800kB when it's UPX-compressed in the image. (It would be about 30MB when decompressed in the memory.)

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum