NEW: WINDOWS TEST APPLICATION FOR EINSTEIN@HOME

Chipper Q
Chipper Q
Joined: 20 Feb 05
Posts: 1,540
Credit: 708,571
RAC: 0

Using last WU from 0.03 and

Using last WU from 0.03 and first from 0.18 as benchmarks:
Ver. 0.03: ~ 45464 sec.
Ver. 0.18: ~ 45539 sec.
Difference: 75 sec., ~ 0.2 % increase in CPU time per WU.

The ver. 0.18 WU took 12:38:59 of CPU time with HP Media Center (P4_HT@ 3.2GHz, 840MHz FSB, float=1365, integer=2541 million ops/sec, under XP Pro SP2)

cmds
cmds
Joined: 1 Aug 05
Posts: 62
Credit: 348,073
RAC: 0

I read the results and

Message 13065 in response to message 13064

I read the results and think:

Version 0.18 will be code-optimized for P4!

All results of P4 will use less seconds more
All results of AMD will use 5-10 % more.

Maybe Bernd say us more about this phenomen.
http://einsteinathome.org/host/412120/tasks
Chris

*Die Signatur befindet sich aus technischen Gründen auf der Rückseite dieses Beitrages!*

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,118
Credit: 229,701,195
RAC: 40,333

1. The science code and

1. The science code and compilation flags of 0.03 and 0.18 are the same, so there should be no noticable difference in calculation times. If there is a difference at all, this should be in the range below about 3%, which is a normal variation between the workunits anyway. The App code differs only in the version of the BOINC library.

2. It's true that the current compilation flags favour the P4 a bit, as it seems to be the CPU most commonly used in this project.

3. Between the BOINC code the 4.79 App was build from and the one used in 0.03 and 0.18 one major change was the thread priority setting of the "worker" thread, which is even lower in the new code. Depending on what else is running on the machine (services, programs, even the BOINC Manager in certain versions) this influences the cruching time, and thus might be responsible for about 10% decrease. I have no other explanation for that, as the code didn't change (much), and the compiler and optimization flags used didn't change either. As there have been problems reported with the old priority setting (unresponsive computers, non-terminating screensavers) I would rather leave that as it is now.

BM

BM

AcidSlide
AcidSlide
Joined: 21 Jul 05
Posts: 14
Credit: 27,082
RAC: 0

Hi Bernd, I'm still

Hi Bernd,

I'm still getting WU error results after adjusting to 0.18 version. I think it is still the screensaver problem. I tested it first with the screensaver enabled. I'll do the following days test with it disabled.

After checking the results, there are more info on the results compared to my previous errors.

Here is the list of my results

Regards,
AcidSlide

jdashton
jdashton
Joined: 9 Sep 05
Posts: 5
Credit: 24,534
RAC: 0

Hello Bernd and

Hello Bernd and company,

I've tried the release-level E@H, and both the 0.03 and 0.18 beta versions. I'm still not getting the screensaver to display graphics, but the beta versions /do/ permit me to display the Show Graphics window, unlike the release version. This is running on Windows XP, SP1, on an IBM ThinkPad T40 using an ATI Mobility Radeon 9000 chip. The screensaver only displays a logo and % complete; no pretty constellation graphics.

One more thing: I'm also running the World Community Grid client. As a programmer I can't explain why that would keep the E@H screensaver from display constellations, but I thought I should mention it as being part of the environment.

jdashton
jdashton
Joined: 9 Sep 05
Posts: 5
Credit: 24,534
RAC: 0

I should add that the

Message 13069 in response to message 13068

I should add that the screensaver is still unresponsive to regular mouse and keyboard events. However, I have always been able to get out of the screensaver by Ctrl-Alt-Del, taking me to the WinXP authentication screen.

Michael Roycraft
Michael Roycraft
Joined: 10 Mar 05
Posts: 846
Credit: 157,718
RAC: 0

RE: RE: RE: Should the

Message 13070 in response to message 13060

Quote:
Quote:
Quote:
Should the .18 beta installation give a seamless transition from 4.79?

No, it won't. You are actually changing the platform, not only the App version.

BM

Migration to .18 beta smooooth, no hangups or errors so far, though WUs take 10% more time (20600 sec for .18 vs. 18700 sec for 4.79)! :( Athlon XP-M 2600+++ under Win XP Home sp2. No others have completed the new WU results that .18 beta has done for me so far, so validation remains to be seen.

Processed 10 WUs with .18, all of which have now validated. Running CC 4.37 under WinXP sp2 on Athlon Barton core, all WUs took between 20592-20767 sec, 10% longer than 4.79 app. Although I have an ATI Radeon 9600Pro vidcard, my 4.37 manager doesn't seem to have a button or provision for graphics or screensaver, or I would have tested that function, just to be more thorough. Having seen how the screensaver hobbles processing from my time with SetiClassic, I would not process with screensaver active anyway, even though by all accounts it is a nice one.

Since I had no serious hangs or lockups running the 4.79 app (and the ones I did have, I attribute to multitasking while severely overclocking), the reduced thread priority is not a concern for me, while the 10% time increase is. In order to maintain more productivity, I have reverted to the 4.79 app.

Sure would like to see the optimized-for-SSE2 (or SSE3) Win app when you have it done, though. I'd then have an excuse to build an Athlon64 rig. (grin)

microcraft

microcraft
"The arc of history is long, but it bends toward justice" - MLK

Rob
Rob
Joined: 26 Sep 05
Posts: 1
Credit: 4,064
RAC: 0

The Graphics often fall

The Graphics often fall behind the BIONIC Manager.

If this happens hitting the SHOW GRAPHICS key will do nothing.
it would be nice if the SHOW GRAPHICS key would bring the app
to the front if rhe app is already running.

Walt Gribben
Walt Gribben
Joined: 20 Feb 05
Posts: 219
Credit: 1,645,393
RAC: 0

RE: The Graphics often fall

Message 13072 in response to message 13071

Quote:

The Graphics often fall behind the BIONIC Manager.

If this happens hitting the SHOW GRAPHICS key will do nothing.
it would be nice if the SHOW GRAPHICS key would bring the app
to the front if rhe app is already running.

Its a Windows restriction. Click on the window to bring it on top of BOINC, after that it'll pop up on top like it should when you click the button. For that execution of the science app that is.

BOINC has the "input focus" when you click Show Graphics and Windows won't let another application switch it away with a new window. "Input focus" is where Windows sends user input - keyboard and mouse activity

When the graphics window appears, you can see it tried to "pop up on top" by watching the taskbar icon - when Windows fails the attempt it flashes the icon for a couple of seconds and then colors it yellow until you finally click on the window.

If you run a second instance of Boinc Manager and use that one to "show graphics", the graphics window will appear under the one you clicked but on top of the other one.

arturg
arturg
Joined: 29 Sep 05
Posts: 19
Credit: 47,396
RAC: 0

Einstein 0.18 did'nt fixed an

Einstein 0.18 did'nt fixed an unrecoverable error, which occurs when sreensaver runs on my AMD Sempron(tm) 2400+ with Windows XP Professional, SP 2, and NIVIDA Geforce FX 5200 under 7.8.0.1. driver.
Before, I had the same error on Einstein 4.79 with older graphic card driver.
Other projects L@H and S@H work properly.

Messages from screen:
1.Application error. Memory can't be written.
2.2005-10-02 09:59:41|Einstein@Home|Unrecoverable error for result l1_1317.0__1317.4_0.1_T09_S4lB_2 ( - exit code -1073741819 (0xc0000005)

Regards

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.