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 ?
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.
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.
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.
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.
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"?
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 ???? ....
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.
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?).
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).
sorry.... i think my problems
)
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 ?
RE: RE: But the
)
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
RE: I am aware of the
)
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.
RE: RE: I am aware of
)
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.
Hasn't gotten easier yet...
BM
BM
RE: AFAIK the
)
Sorry, must have been gcc 4.0.2.
BM
BM
RE: bit now with 2 projects
)
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
RE: What happens if you set
)
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 ???? ....
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
RE: I got another problem
)
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
RE: Anybody else seen
)
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).