SPARC Solaris Einstein@Home?

[AF>ALSACE>EDLS] Phil68
[AF>ALSACE>EDLS...
Joined: 30 Dec 05
Posts: 32
Credit: 39,832
RAC: 0

sorry.... i think my problems

Message 15757 in response to message 15756

sorry.... i think my problems are not related to einstein (and albert :-) ), or not only :-), but with the boinc-client...
today, einstein started first, all alone and without seti....
the second WU stays at 0%.... but at this time the first is still working...
the seti WU cames later, and is still at 0% ....
as seti was alone on the machine, there were no problems with 2 WU working at the same time, each on his processor....
bit now with 2 projects and two processors, the boinc-client seams to have a problem....
any idea ?

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,330
Credit: 251,450,334
RAC: 36,229

RE: RE: But the

Message 15758 in response to message 15756

Quote:
Quote:
But the performance looks rather poor:

As it is visible on the above result page, the processing is clearly to slow compared to usual PC systems.
Not two complete CPU days, but comes near --- do you took any optimization measures at all? What compiler do you used to build the client? gcc 3.0, 3.3, 3.4, 4.0, Sun Studio 8,9,10,11? There are different possibilities to get the client faster, on SPARC-Solaris sometimes the program may run even faster with -O2 than -O3 with gcc...

I am aware of the rather poor performance and am working on optimizations. I was happy to get something working at all. The App has been compiled with gcc-3.3 on a Solaris7 system, for now with -O3. I'm investigating and expect to improve the performance significantly.

BM

BM

Stefan Urbat
Stefan Urbat
Joined: 9 Feb 05
Posts: 16
Credit: 147,672
RAC: 0

RE: I am aware of the

Message 15759 in response to message 15758

Quote:


I am aware of the rather poor performance and am working on optimizations. I was happy to get something working at all. The App has been compiled with gcc-3.3 on a Solaris7 system, for now with -O3. I'm investigating and expect to improve the performance significantly.

BM

Okay, than for me all is clear now. I propose usage of gcc 4.0.2 with -ftree-vectorize and maybe the VIS extension (which would limit usage to UltraSPARC systems and higher, what makes sense in matters of acceptable performance) -mvis. I can't recommend usage of the Sun Studio compiler (though 11 is free to be used), because that would require BOINC too to be compiled with it; gcc libs can't be used in Sun compiler builds. The last time I tried BOINC to compile with a Sun compiler it looked rather difficult to get through.

Anyway, the application seems to work flawless so far for me, so optimization can be started without unnecessary concerns. The second machine has also finished work for now.

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,330
Credit: 251,450,334
RAC: 36,229

RE: RE: I am aware of

Message 15760 in response to message 15759

Quote:
Quote:


I am aware of the rather poor performance and am working on optimizations. I was happy to get something working at all. The App has been compiled with gcc-3.3 on a Solaris7 system, for now with -O3. I'm investigating and expect to improve the performance significantly.

BM

Okay, than for me all is clear now. I propose usage of gcc 4.0.2 with -ftree-vectorize and maybe the VIS extension (which would limit usage to UltraSPARC systems and higher, what makes sense in matters of acceptable performance) -mvis.

AFAIK the -ftree-vectorize doesn't make sense without the extensions (i.e. is ignored). Also it doesn't help much with our code, at least the 4.0.1 on x86 didn't recognize our loops as being vectorizable.

Quote:
I can't recommend usage of the Sun Studio compiler (though 11 is free to be used), because that would require BOINC too to be compiled with it; gcc libs can't be used in Sun compiler builds. The last time I tried BOINC to compile with a Sun compiler it looked rather difficult to get through.

Hasn't gotten easier yet...

BM

BM

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,330
Credit: 251,450,334
RAC: 36,229

RE: AFAIK the

Message 15761 in response to message 15760

Quote:
AFAIK the -ftree-vectorize doesn't make sense without the extensions (i.e. is ignored). Also it doesn't help much with our code, at least the 4.0.1 on x86 didn't recognize our loops as being vectorizable.


Sorry, must have been gcc 4.0.2.

BM

BM

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,330
Credit: 251,450,334
RAC: 36,229

RE: bit now with 2 projects

Message 15762 in response to message 15757

Quote:
bit now with 2 projects and two processors, the boinc-client seams to have a problem....
any idea ?

Hm, I'm tempted to suggest a newer client, but I'm aware there is no such available from BOINC for download - you'll either have to roll your own or look for other friendly crunchers who did that for you...

What happens if you set your preferences to "use no more than 1 CPU"?

BM

BM

[AF>ALSACE>EDLS] Phil68
[AF>ALSACE>EDLS...
Joined: 30 Dec 05
Posts: 32
Credit: 39,832
RAC: 0

RE: What happens if you set

Message 15763 in response to message 15762

Quote:

What happens if you set your preferences to "use no more than 1 CPU"?

BM


i have tied that... but it doesn't change anything, or i don't see the changes :-) because it works now with 2 threads on 1 CPU (i restarted the boinc)...
but, what i see, if i let all running without doing anything, is that the WU are computed, even if i don't see the progress in the %... as if the results weren't up to date... and after a long time (in hours) it's ok....
with seti, the % is always actualised....

and if i look the client_state.xml....
seti has
0.859962
19119.950000
and albert has
0.000000
2089.770000
is that fraction_done normal ???? ....

4Z8t5f7VjyRJQLuVHyPjG4DGfBfv
4Z8t5f7VjyRJQLu...
Joined: 23 Feb 05
Posts: 22
Credit: 9,833,596
RAC: 33,556

I got another problem with

I got another problem with the new app.
I'm using boinc 4.42 (I know I should upgrade, but I'm too lasy and had no problems till now.)

I'm running both SETI and albert on the Solaris boxes.
Problem here is, the app does not really stop, if boinc asks the app to do so.
as well I tried to kill the app normal and it was still running.
kill -9 worked.

Any idea?
Thanks

Achim

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,330
Credit: 251,450,334
RAC: 36,229

RE: I got another problem

Message 15765 in response to message 15764

Quote:

I got another problem with the new app.
I'm using boinc 4.42 (I know I should upgrade, but I'm too lasy and had no problems till now.)

I'm running both SETI and albert on the Solaris boxes.
Problem here is, the app does not really stop, if boinc asks the app to do so.
as well I tried to kill the app normal and it was still running.
kill -9 worked.

Any idea?
Thanks

Achim

What version of Solaris are you running this on? Are the patches up-to-date?

Anybody else seen this?

It might be a problem with the Core Client, or a with shared library (pthreads?).

BM

BM

Stefan Urbat
Stefan Urbat
Joined: 9 Feb 05
Posts: 16
Credit: 147,672
RAC: 0

RE: Anybody else seen

Message 15766 in response to message 15765

Quote:

Anybody else seen this?

It might be a problem with the Core Client, or a with shared library (pthreads?).

BM

I have not exactly seen this one, but one of both machines I let test the albert 4.36 app had yesterday some mick encountered (Solaris 9, nearly current patch state), I think --- unrealistic values for a work unit, as reported by someone else earlier in this thread. But due to the long validation times and low speed of that one I can't tell any details for the moment. The other machine got already four results validated (Solaris 10, relatively current patch state).

Comment viewing options

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