Is there a Solaris/SPARC application in the works?
Is there a Solaris/SPARC application in the works?
There are only some older statements:
http://einstein.phys.uwm.edu/forum_thread.php?id=55
http://einstein.phys.uwm.edu/forum_thread.php?id=662
http://einstein.phys.uwm.edu/forum_thread.php?id=2204
____________
Bernd MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
We had a voulunteer for doing the port, but I haven't heard of him for months now. Apparently he ran out of free time for that (like we all do...). Currently there is done quite some work on the code of BOINC as well as on the science code. Maybe we'll start another attempt when the codebase is more stable again. But the priority for new ports is rather low for now.
BM
____________
BM
very interested in SPARC Solaris client too
got like 50 Blades ready for it when it gets released.......
____________
Bernd MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
I just built a Solaris/SPARC version of the new Albert App, which seems to run well on Solaris 7 and 10 (and thus it should on 8 and 9, too). We plan to release it after some testing. Our SPARCs are somewhat slow, so this may take a while. Stay tuned.
BM
____________
BM
This sounds very good, txs.
yoyo
____________
Member of Germany largest distributed computing community
I have also 5 SPARC-Solaris systems at hand and would be glad, if I could use them for another BOINC project too (only SETI@home available so far, by binary and source code both). If you would dare to give us the source, we might try ourselves (for example on x86-Solaris, where a number of fast AMD64 systems are waiting...). More precise, they would do Einstein@home primarily, because it has a higher priority in my profile than SETI@home...
____________
Bruce AllenForum moderator
Project administrator
Project developer
Project scientist
Send message
Joined: Oct 15 04
Posts: 1094
Credit: 171,459,074
RAC: 493
The Solaris Einstein@Home app that Bernd built is now being distributed (command line version only; graphical version coming soon). Please use this thread to report success or problems.
Bruce
____________
Looks like the same issue as observed with SETI-BOINC: "Message from server: platform 'sparc-sun-solaris2.9' not found" --- I thought, you wanted to omit the annoying version number after solaris to prevent such problems, when I read the discussions on the BOINC-dev mailing-list? Is the same sparc-sun-solaris2.7 expected as by Berkeley anyway?
____________
Proposal for handling this Solaris version differences issue: either add a generic pattern in the MySQL database or manually add and link all variants from the supported one on (i.e. 2.7, 2.8, 2.9 and 2.10 and for the brave among us even 2.11 for the current (community/OpenSolaris) express versions, or just begin with 2.8 or the like). Otherwise I will try with the original 2.7 client.
____________
At least version 4.19 of the official BOINC sparc client exits with a SEGV on Solaris 9 --- I could try on Solaris 10 too (dtrace!) or analyze the core file, if one would be created. So I was forced to use the anonymous platform mechanism again, no good, when considering the beta state and likely updates for the albert application.
____________
Bernd MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
The stock clients all request sparc-sun-solaris2.7 platform, as they are built on a Sol7 so they should run on all systems from then on. If you compile your own client, you are advised to use --build=sparc-sun-solaris2.7 as additional configure option, so the client will report the same platform.
Due to an old build process (which has been improved since then) the old 4.19 links to shared libraries that are not present on all systems (to say the least), in particular libstdc++.so.3 and libgcc_s.so.1. If you have a gcc installed, you can create a symlink named libstdc++.so.3 to your version of libstdc++.so.
I am running the stock recommended 4.43 client without problems.
BM
____________
BM
The stock clients all request sparc-sun-solaris2.7 platform, as they are built on a Sol7 so they should run on all systems from then on. If you compile your own client, you are advised to use --build=sparc-sun-solaris2.7 as additional configure option, so the client will report the same platform.
Due to an old build process (which has been improved since then) the old 4.19 links to shared libraries that are not present on all systems (to say the least), in particular libstdc++.so.3 and libgcc_s.so.1. If you have a gcc installed, you can create a symlink named libstdc++.so.3 to your version of libstdc++.so.
I am running the stock recommended 4.43 client without problems.
BM
Indeed I had to softlink the libstdc++.so v3 to a current v6 and not tried the more recent client version 4.43 there, but on another machine running Solaris 10 albert v4.36 works so far smoothly (with the anonymous platform mechanism too). Your proposal makes sense, to force an older Solaris version; so far it didn't make a difference, because SETI@home is open source like BOINC and I used to compile both subsequently, so I need in this situation always the app_info.xml to run the self-compiled application.
____________
Hi...
I'm very happy to have one application for my solaris (other than seti)...
But at this time i have problems whit the computing... some WUs come with no time (and they stay with 0% in my BViewer...)...
is that a WU problem or a Application problem ?
____________
Bernd MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
Hi...
I'm very happy to have one application for my solaris (other than seti)...
But at this time i have problems whit the computing... some WUs come with no time (and they stay with 0% in my BViewer...)...
is that a WU problem or a Application problem ?
Which client are you using? I don't know about BViewer, but what do you get when you grep client_state.xml for "fraction_done" on the machine in question?
BM
____________
BM
Which client are you using? I don't know about BViewer, but what do you get when you grep client_state.xml for "fraction_done" on the machine in question?
BM
i have 2 processors and at this time 1 of them is occupied with seti...
is this application able to work with 2 WUs at the same time ?.......
my Version is -> BOINC client version 4.43 for sparc-sun-solaris2.7
after a kill and a restart from boinc-client.... the % is 0.0 but the CPU-Time is 05:07:20....
thanks
before kill
<active_task>
<project_master_url>http://einstein.phys.uwm.edu/</project_master_url>
<result_name>z1_0175.0__1078_S4R2a_0</result_name>
<active_task_state>1</active_task_state>
<app_version_num>436</app_version_num>
<slot>1</slot>
<scheduler_state>2</scheduler_state>
<checkpoint_cpu_time>18440.180000</checkpoint_cpu_time>
<fraction_done>0.776293</fraction_done>
<current_cpu_time>18463.590000</current_cpu_time>
<vm_bytes>0.000000</vm_bytes>
<rss_bytes>0.000000</rss_bytes>
</active_task>
<active_task>
<project_master_url>http://einstein.phys.uwm.edu/</project_master_url>
<result_name>z1_0175.0__1077_S4R2a_0</result_name>
<active_task_state>9</active_task_state>
<app_version_num>436</app_version_num>
<slot>2</slot>
<scheduler_state>1</scheduler_state>
<checkpoint_cpu_time>0.000000</checkpoint_cpu_time>
<fraction_done>0.000000</fraction_done>
<current_cpu_time>0.000000</current_cpu_time>
<vm_bytes>0.000000</vm_bytes>
<rss_bytes>0.000000</rss_bytes>
</active_task>
after restart
<active_task>
<project_master_url>http://einstein.phys.uwm.edu/</project_master_url>
<result_name>z1_0175.0__1077_S4R2a_0</result_name>
<active_task_state>0</active_task_state>
<app_version_num>436</app_version_num>
<slot>2</slot>
<scheduler_state>1</scheduler_state>
<checkpoint_cpu_time>0.000000</checkpoint_cpu_time>
<fraction_done>0.000000</fraction_done>
<current_cpu_time>0.000000</current_cpu_time>
<vm_bytes>0.000000</vm_bytes>
<rss_bytes>0.000000</rss_bytes>
</active_task>
<active_task>
<project_master_url>http://einstein.phys.uwm.edu/</project_master_url>
<result_name>z1_0175.0__1076_S4R2a_0</result_name>
<active_task_state>0</active_task_state>
<app_version_num>436</app_version_num>
<slot>3</slot>
<scheduler_state>1</scheduler_state>
<checkpoint_cpu_time>0.000000</checkpoint_cpu_time>
<fraction_done>0.000000</fraction_done>
<current_cpu_time>0.000000</current_cpu_time>
<vm_bytes>0.000000</vm_bytes>
<rss_bytes>0.000000</rss_bytes>
</active_task>
<active_task>
<project_master_url>http://einstein.phys.uwm.edu/</project_master_url>
<result_name>z1_0175.0__1075_S4R2a_0</result_name>
<active_task_state>9</active_task_state>
<app_version_num>436</app_version_num>
<slot>4</slot>
<scheduler_state>1</scheduler_state>
<checkpoint_cpu_time>0.000000</checkpoint_cpu_time>
<fraction_done>0.000000</fraction_done>
<current_cpu_time>0.000000</current_cpu_time>
<vm_bytes>0.000000</vm_bytes>
<rss_bytes>0.000000</rss_bytes>
</active_task>
____________
IMHO, it would make much more sense to have a native x86-64 client, volume-wise.
____________
IMHO, it would make much more sense to have a native x86-64 client, volume-wise.
It depends, but Solaris and Linux clients for x86_64 CPUs would be fine regarding performance, as I know from SETI@home. Can't beat heavy SMP SPARC systems on the other hand (even a 4 core system with AMD 275 Opterons is not able to top 32 or the like UltraSPARC III systems, for example).
____________
The first result seems to be cleanly completed on the fastest SPARC-Solaris system I have access too, though it is not visible on the website (log statement).
But the performance looks rather poor: on this 1062 MHz UltraSPARC IIIi CPU it took nearly exactly 100000 seconds, i.e. more than one day CPU time, to finish it. I would have expected values of 40000 seconds on this hardware taking into account the relations in resp. to SETI@home among different CPUs.
So there seems to be a lot of potential for optimization of the SPARC client, doesn't it? The other machine, launched earlier for Einstein@home, a mere 550 MHz UltraSPARC II CPU driven, will take about two CPU days to complete, it seems...
____________
Today i have 3 WUs on my Sun-machine.
I let the first one work alone, i have paused the 2 other and the SETI-ones....
This WU (z1_0175.0__1072_S4R2a_0) seams to be blocked now.... and i'm sure that if i restart the boinc-client, the WU will have 0 CPU-Time.....
<active_task>
<project_master_url>http://einstein.phys.uwm.edu/</project_master_url>
<result_name>z1_0175.0__1072_S4R2a_0</result_name>
<active_task_state>1</active_task_state>
<app_version_num>436</app_version_num>
<slot>1</slot>
<scheduler_state>2</scheduler_state>
<checkpoint_cpu_time>3606.320000</checkpoint_cpu_time>
<fraction_done>0.141345</fraction_done>
<current_cpu_time>3606.320000</current_cpu_time>
<vm_bytes>0.000000</vm_bytes>
<rss_bytes>0.000000</rss_bytes>
</active_task>
<active_task>
<project_master_url>http://einstein.phys.uwm.edu/</project_master_url>
<result_name>z1_0175.0__1071_S4R2a_0</result_name>
<active_task_state>9</active_task_state>
<app_version_num>436</app_version_num>
<slot>2</slot>
<scheduler_state>1</scheduler_state>
<checkpoint_cpu_time>0.000000</checkpoint_cpu_time>
<fraction_done>0.000000</fraction_done>
<current_cpu_time>0.000000</current_cpu_time>
<vm_bytes>0.000000</vm_bytes>
<rss_bytes>0.000000</rss_bytes>
</active_task>
<active_task>
<project_master_url>http://einstein.phys.uwm.edu/</project_master_url>
<result_name>z1_0175.0__1070_S4R2a_0</result_name>
<active_task_state>9</active_task_state>
<app_version_num>436</app_version_num>
<slot>3</slot>
<scheduler_state>1</scheduler_state>
<checkpoint_cpu_time>0.000000</checkpoint_cpu_time>
<fraction_done>0.000000</fraction_done>
<current_cpu_time>0.000000</current_cpu_time>
<vm_bytes>0.000000</vm_bytes>
<rss_bytes>0.000000</rss_bytes>
</active_task>
and after the kill of the boinc....
<active_task>
<project_master_url>http://einstein.phys.uwm.edu/</project_master_url>
<result_name>z1_0175.0__1072_S4R2a_0</result_name>
<active_task_state>1</active_task_state>
<app_version_num>436</app_version_num>
<slot>1</slot>
<scheduler_state>2</scheduler_state>
<checkpoint_cpu_time>3606.320000</checkpoint_cpu_time>
<fraction_done>0.000000</fraction_done>
<current_cpu_time>3606.320000</current_cpu_time>
<vm_bytes>0.000000</vm_bytes>
<rss_bytes>0.000000</rss_bytes>
</active_task>
and the work didn't go farther.... and after i canceld it.... here the results (as if it were completed)...
15004119 3706440 17 Jan 2006 0:51:59 UTC 17 Jan 2006 8:45:49 UTC Over Client error Computing 3,606.32 3.66 ---
____________
The first result seems to be cleanly completed on the fastest SPARC-Solaris system I have access too, though it is not visible on the website (log statement).
Meanwhile the first two results are completed there, as you can see here:
http://einstein.phys.uwm.edu/results.php?hostid=515255
But the performance looks rather poor: on this 1062 MHz UltraSPARC IIIi CPU it took nearly exactly 100000 seconds, i.e. more than one day CPU time, to finish the first one. I would have expected values of 40000 seconds on this hardware taking into account the relations in resp. to SETI@home among different CPUs.
As it is visible on the above result page, the processing is clearly to slow compared to usual PC systems.
So there seems to be a lot of potential for optimization of the SPARC client, doesn't it? The other machine, launched earlier for Einstein@home, a mere 550 MHz UltraSPARC II CPU driven, will take about two CPU days to complete the first run, it seems...
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...
____________
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 MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
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
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 MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
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.
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 MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
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 MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
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
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
<fraction_done>0.859962</fraction_done>
<current_cpu_time>19119.950000</current_cpu_time>
and albert has
<fraction_done>0.000000</fraction_done>
<current_cpu_time>2089.770000</current_cpu_time>
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.
Any idea?
Thanks
Achim
____________
Bernd MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
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
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).
____________
What version of Solaris are you running this on? Are the patches up-to-date?
It is a solaris 8 but from here I don't know th patch state.
BTW: I got it for 3 Servers all Solaris 8, but definitivly different patches.
I assume 1 did not have any patches since ages.
The other one should be quite recent.
It might be a problem with the Core Client, or a with shared library (pthreads?).
BM
Which thread libs do you suggest. I not sure which ones I'm using. (I'm not used to these, most programs I use are single thread, but I think I can remember we sovled a thread problem by using a differnet LD_LIBRARY_PATH).
Achim
____________
Which thread libs do you suggest. I not sure which ones I'm using. (I'm not used to these, most programs I use are single thread, but I think I can remember we sovled a thread problem by using a differnet LD_LIBRARY_PATH).
We added /usr/lib/lwp.
Don't know if this would help.
Achim
____________
i think the einstein will not be able to compute correctly more than 1 WU of 10 on my computer...
perhaps its my computer, perhaps my old solaris 7, perhaps the boinc-client, or perhaps albert itself... i don't know...
but as seti works perfectly, i think it could be the albert-software...
WU staying a 100% without calling back the server, WU that never start, no restart after a boinc-client restart....
my question, do you think there will be a new version of boinc or albert for solaris in the next times ?
does someone analyze the errors like:
2006-01-20 23:18:44.8890 [normal]: Start of BOINC application 'albert_4.36_sparc-sun-solaris2.7'.
2006-01-20 23:18:44.8924 [normal]: Started search at lalDebugLevel = 0
2006-01-20 23:18:45.7155 [normal]: Checkpoint-file 'Fstat.out.ckp' not found.
2006-01-20 23:18:45.7214 [normal]: No usable checkpoint found, starting from beginning.
2006-01-21 00:05:28.9333 [normal]: Fstat file reached MaxFileSizeKB ==> compactifying ... done.
2006-01-21 06:34:25.3902 [normal]: Search finished successfully.
i don't want to give up, and i don't want my computer for only searching ET.... but.... without some changes i will have to disable einstein... :-(
____________
i think the einstein will not be able to compute correctly more than 1 WU of 10 on my computer...
perhaps its my computer, perhaps my old solaris 7, perhaps the boinc-client, or perhaps albert itself... i don't know...
but as seti works perfectly, i think it could be the albert-software...
WU staying a 100% without calling back the server, WU that never start, no restart after a boinc-client restart....
my question, do you think there will be a new version of boinc or albert for solaris in the next times ?
does someone analyze the errors like:
2006-01-20 23:18:44.8890 [normal]: Start of BOINC application 'albert_4.36_sparc-sun-solaris2.7'.
2006-01-20 23:18:44.8924 [normal]: Started search at lalDebugLevel = 0
2006-01-20 23:18:45.7155 [normal]: Checkpoint-file 'Fstat.out.ckp' not found.
2006-01-20 23:18:45.7214 [normal]: No usable checkpoint found, starting from beginning.
2006-01-21 00:05:28.9333 [normal]: Fstat file reached MaxFileSizeKB ==> compactifying ... done.
2006-01-21 06:34:25.3902 [normal]: Search finished successfully.
i don't want to give up, and i don't want my computer for only searching ET.... but.... without some changes i will have to disable einstein... :-(
That is really strange --- either patch your system and/or use another BOINC client (newer one), before giving up, I guess. Both machines which I use currently (2 out of 5 available SPARC-Solaris systems), one running Solaris 9, and one Solaris 10, work just fine with albert 4.36, though slow (see below).
____________
[quoteThat is really strange --- either patch your system and/or use another BOINC client (newer one), before giving up, I guess. Both machines which I use currently (2 out of 5 available SPARC-Solaris systems), one running Solaris 9, and one Solaris 10, work just fine with albert 4.36, though slow (see below).[/quote]
thanks, but patch my system is quite impossible.....
where can i find a newer version ?
may actual client version is 4.43 for sparc-sun-solaris2.7
____________
today i tried a other version ( 4.62 )...
but i have an error like this one describe on the boinc pages....
If BOINC produces messages of the form
ld.so.1: boinc: fatal: libstdc++.so.3: open failed: No such file or
directory
then you probably have a newer version of libstdc++.so, and you may need to symbolically link the newer version to libstdc++.so.3
how can i do this "symbolic link" ???
____________
how can i do this "symbolic link" ???
i made this link...but the boinc client does now make a core..... nooooooo !!!!
____________
how can i do this "symbolic link" ???
i made this link...but the boinc client does now make a core..... nooooooo !!!!
If you have a pre-Solaris 10, your libstc++.so.x libs will reside in either /usr/local/lib (the 64 bit version in subdirectory sparcv9) resp. /opt/sfw/lib (again look for 64 bit version in subdirectory sparcv9). So just change into the respective directory and there create a softlink to the more current version:
if you have gcc 3.3.x or it's lib installed, version 5:
ln -s libstdc++.so.5 libstdc++.so.3
if you have gcc 3.4.x or it's lib installed, version 6:
ln -s libstdc++.so.6 libstdc++.so.3
Should usually work without complaints or mysterious errors, although it's some kind of fake, but the newer versions can cover the older.
But previously to do so check for two prerequisites:
1. do you have any g++ library at all on your system? The usual locations are as mentioned /opt/sfw/lib (from the software companion), /usr/local/lib (self compiled default location or by sunfreeware.com), /opt/csw/lib (from blastwave.org) or even (only Solaris 10) in /usr/sfw/lib. If not resort to one of those sites/CDs and install at least a libgcc in v3.2 or later (recommended 3.4.x or at least 3.3.x).
2. either extend or define at all your LD_LIBRARY_PATH previous to execution of the BOINC client or use crle to add your (open source) lib directory permanently (not recommended, and do only, if you know very well, what you're doing). For example:
LD_LIBRARY_PATH=/usr/local/lib:/opt/sfw/lib:/usr/lib:/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
(works in all shells but csh resp. tcsh, where you have to use set in front of the assignment of the variable and no export exists)
Afterwards you should be able to run the albert 4.36 app with the BOINC client you got.
____________
first of all, thank you very much for those explanations.... but i'm not an expert :-)
ln -s libstdc++.so.5 libstdc++.so.3
id did that... with the latest version i have /usr/local/lib/sparcv9/libstdc++.so.5.0.5
1. do you have any g++ library at all on your system? The usual locations are as mentioned /opt/sfw/lib (from the software companion), /usr/local/lib (self compiled default location or by sunfreeware.com), /opt/csw/lib (from blastwave.org) or even (only Solaris 10) in /usr/sfw/lib. If not resort to one of those sites/CDs and install at least a libgcc in v3.2 or later (recommended 3.4.x or at least 3.3.x).
i think there is something like that on my system....
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/sparcv9
2. either extend or define at all your LD_LIBRARY_PATH previous to execution of the BOINC client or use crle to add your (open source) lib directory permanently (not recommended, and do only, if you know very well, what you're doing). For example:
LD_LIBRARY_PATH=/usr/local/lib:/opt/sfw/lib:/usr/lib:/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
(works in all shells but csh resp. tcsh, where you have to use set in front of the assignment of the variable and no export exists)
i extended my LD_LIBRARY_PATH.... and than i had a new error....
ld.so.1: ./boinc: fatal: /usr/local/lib/sparcv9/libstdc++.so.3: wrong ELF class: ELFCLASS64
are the clients of boinc compiled for 32-bit libraries ?
if i try without de spracv9 sub-directories.... i have a core....
____________
Which thread libs do you suggest. I not sure which ones I'm using. (I'm not used to these, most programs I use are single thread, but I think I can remember we sovled a thread problem by using a differnet LD_LIBRARY_PATH).
We added /usr/lib/lwp.
Don't know if this would help.
Achim
For now it looks like this was the trick.
____________
We added /usr/lib/lwp.
Don't know if this would help.
Achim
ok, i added /usr/lib/lwp/sparcv9 and /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/sparcv9 to see if that make changes....
with my old version 4.43
i don't know if it was the problem.... but my albert seems to do his job now....
very very slow... but to the end :-)
the only thing is that it doesn't actualize the CLIENT-STATS.... it shows something to the 10%... and then nothing to the end... and my Boinc-Viewer doesn't show any movement on the WUs... but that is not so important....
now i'm waiting for a new and FASTER version :-)
thank you
____________
now i'm waiting for a new and FASTER version :-)
does someone know how i can say to the boinc-client or the albert that he must update his percentages / stats in the xml...... (is that related to break/check points ???) so that my boincviewer show me the cpu-times and percentages as seti is doing..... ???
____________
some more infos...... i have 2 WUS that seams once more not to go farther.... :-(
first the client_state.xml..... and the slots files.....
i don't know...perhaps could someone find here something wrong.... the checkpoints seam really not to work on my machine.....
Is that normal "Fstat file reached MaxFileSizeKB" ???
<active_task>
<project_master_url>http://einstein.phys.uwm.edu/</project_master_url>
<result_name>z1_0666.5__282_S4R2a_2</result_name>
<active_task_state>1</active_task_state>
<app_version_num>436</app_version_num>
<slot>1</slot>
<scheduler_state>2</scheduler_state>
<checkpoint_cpu_time>84342.990000</checkpoint_cpu_time>
<fraction_done>0.028841</fraction_done>
<current_cpu_time>84342.990000</current_cpu_time>
<vm_bytes>0.000000</vm_bytes>
<rss_bytes>0.000000</rss_bytes>
</active_task>
<active_task>
<project_master_url>http://einstein.phys.uwm.edu/</project_master_url>
<result_name>z1_0666.5__281_S4R2a_2</result_name>
<active_task_state>1</active_task_state>
<app_version_num>436</app_version_num>
<slot>0</slot>
<scheduler_state>2</scheduler_state>
<checkpoint_cpu_time>3085.580000</checkpoint_cpu_time>
<fraction_done>0.036817</fraction_done>
<current_cpu_time>3085.580000</current_cpu_time>
<vm_bytes>0.000000</vm_bytes>
<rss_bytes>0.000000</rss_bytes>
</active_task>
slots/0>lst
-rw-r--r-- 1 pp staff 402399 Oct 25 17:24 skygrid_0670_z_T06.dat
drwxr-xr-x 7 pp staff 512 Jan 16 09:01 ..
-rw-r--r-- 1 pp staff 70 Feb 7 00:43 sun
-rw-r--r-- 1 pp staff 3067 Feb 7 00:43 init_data.xml
-rw-r--r-- 1 pp staff 72 Feb 7 00:43 earth
-rw-r--r-- 1 pp staff 70 Feb 7 00:43 data.sft
-rw-r--r-- 1 pp staff 77 Feb 7 00:43 conf
-rw-r--r-- 1 pp staff 0 Feb 7 00:43 boinc_lockfile
-rw-r--r-- 1 pp staff 93 Feb 7 00:43 albert_4.36_sparc-sun-solaris2.7
-rw-r--r-- 1 pp staff 85 Feb 7 00:43 Fstat.out
-rw-r--r-- 1 pp staff 432 Feb 7 01:36 stderr.txt
-rw-r--r-- 1 pp staff 25 Feb 7 01:36 Fstat.out.ckp
drwxr-xr-x 2 pp staff 512 Feb 7 01:36 .
slots/0>more Fstat.out.ckp
818 33369450 668662
DONE
Fstat.out.ckp: END
slots/0>more stderr.txt
2006-02-07 00:43:32.9964 [normal]: Start of BOINC application 'albert_4.36_sparc-sun-solaris2.7'.
2006-02-07 00:43:33.0060 [normal]: Started search at lalDebugLevel = 0
2006-02-07 00:43:34.3525 [normal]: Checkpoint-file 'Fstat.out.ckp' not found.
2006-02-07 00:43:34.3667 [normal]: No usable checkpoint found, starting from beginning.
2006-02-07 01:36:04.8990 [normal]: Fstat file reached MaxFileSizeKB ==> compactifying ... done.
slots/1>lst
-rw-r--r-- 1 pp staff 402399 Oct 25 17:24 skygrid_0670_z_T06.dat
drwxr-xr-x 7 pp staff 512 Jan 16 09:01 ..
-rw-r--r-- 1 pp staff 70 Feb 6 00:30 sun
-rw-r--r-- 1 pp staff 72 Feb 6 00:30 earth
-rw-r--r-- 1 pp staff 70 Feb 6 00:30 data.sft
-rw-r--r-- 1 pp staff 77 Feb 6 00:30 conf
-rw-r--r-- 1 pp staff 93 Feb 6 00:30 albert_4.36_sparc-sun-solaris2.7
-rw-r--r-- 1 pp staff 85 Feb 6 00:30 Fstat.out
-rw-r--r-- 1 pp staff 0 Feb 7 00:24 boinc_finish_called
-rw-r--r-- 1 pp staff 3077 Feb 7 08:54 init_data.xml
-rw-r--r-- 1 pp staff 0 Feb 7 08:54 boinc_lockfile
-rw-r--r-- 1 pp staff 929 Feb 7 09:36 stderr.txt
-rw-r--r-- 1 pp staff 25 Feb 7 09:36 Fstat.out.ckp
drwxr-xr-x 2 pp staff 512 Feb 7 09:36 .
slots/1>more stderr.txt
2006-02-06 00:30:38.1595 [normal]: Start of BOINC application 'albert_4.36_sparc-sun-solaris2.7'.
2006-02-06 00:30:38.1624 [normal]: Started search at lalDebugLevel = 0
2006-02-06 00:30:38.9200 [normal]: Checkpoint-file 'Fstat.out.ckp' not found.
2006-02-06 00:30:38.9258 [normal]: No usable checkpoint found, starting from beginning.
2006-02-06 01:12:33.2474 [normal]: Fstat file reached MaxFileSizeKB ==> compactifying ... done.
2006-02-07 00:24:42.0435 [normal]: Search finished successfully.
2006-02-07 08:54:36.8763 [normal]: Start of BOINC application 'albert_4.36_sparc-sun-solaris2.7'.
2006-02-07 08:54:36.8791 [normal]: Started search at lalDebugLevel = 0
2006-02-07 08:54:38.4567 [normal]: Checkpoint-file 'Fstat.out.ckp' not found.
2006-02-07 08:54:38.4707 [normal]: No usable checkpoint found, starting from beginning.
2006-02-07 09:36:17.4816 [normal]: Fstat file reached MaxFileSizeKB ==> compactifying ... done.
slots/1>more Fstat.out.ckp
641 33437018 670670
DONE
____________
From looking at the stats data for this site, I see one sparcv8, two sparcv8plus+vis and the rest are sparcv9+vis or sparcv9plus+vis2. There were 95 'sparc's What would you think about just making the SPARC / Solaris client for the sparcv9 and above series. I think this is all the UltraSPARCs. I am personally running a SunBlade 100 with 2Gb RAM.
____________
I forgot to add that the client I installed and downloaded worked fine for me. If we want more SPARC Solaris users, it might be nice to get the word out to the SPARC Solaris users on Seti@home or get an anouncement on Boinc.
____________
I forgot to add that the client I installed and downloaded worked fine for me. If we want more SPARC Solaris users, it might be nice to get the word out to the SPARC Solaris users on Seti@home or get an anouncement on Boinc.
can i ask what version of the client it was ? and what for version of einstein ? and what of an OS version you have ? :-)
i'm sad because if it doesn't work better soon, i'll have no other choice than give up :-(
____________
Boinc -version gives 4.43 sparc-sun-solaris2.7
It looks like Albert 4.36 sparc-sun-solaris2.7
I am on Solaris 10. You should be able to see my computers because I don't have them hidden. Just click on my username link in the forum.
I looked over your posts and it seems like your client is working but what you say slow. I run my in a terminal window and just watch it there.
Do a 'uname -a' and a 'psrinfo -v' and post the results so we can see what your attempting to run on.
____________
How do you have your Boinc Viewer set up to connect to the Sun box? I tried to play with it but got nothing. What command line options do you have to do? Currently, I just run the Solaris SPARC client with 'run_client' and no options.
____________
How do you have your Boinc Viewer set up to connect to the Sun box? I tried to play with it but got nothing. What command line options do you have to do? Currently, I just run the Solaris SPARC client with 'run_client' and no options.
the option is "-allow_remote_gui_rpc" and you must have a key in the file "gui_rpc_auth.cfg" ...
Do a 'uname -a' and a 'psrinfo -v' and post the results so we can see what your attempting to run on.
pp@SUN-Fire ~/BOINC_4.43_2>uname -a
SunOS SUN-Fire 5.8 Generic_108528-29 sun4u sparc SUNW,Sun-Fire-V250
pp@SUN-Fire ~/BOINC_4.43_2>psrinfo -v
Status of processor 0 as of: 02/10/06 08:50:14
Processor has been on-line since 10/20/05 08:44:58.
The sparcv9 processor operates at 1280 MHz,
and has a sparcv9 floating point processor.
Status of processor 1 as of: 02/10/06 08:50:14
Processor has been on-line since 10/20/05 08:44:56.
The sparcv9 processor operates at 1280 MHz,
and has a sparcv9 floating point processor.
____________
I just looked at the SPARC/Solaris stats from Einstein today. This is what I am seeing. I am showing 99 clients with a p_model like "*sparcv*". Three are sparcv8 and the rest are sparcv9. If you don't mind excluding the v8 arch, the client could be targeted for ultrasparc in the compiler options. It seems targeting to Solaris 7 is a good choice as it runs on everything above.
Stefan, I see you make up some BOINC clients for Seti and BOINC itself. Have you got any enhancements in your work or seen any speedups? I see that you say the US III client may go for Niagara? From the Sun website, I don't think T1 processors support vis and they are marked as v9 only. I think there are two T2000 machines running on Seti@home according to there stats I downloaded. Solaris, from what I understand, has excellent compatibility up and down the line from versions 7 to 10. Do you see any differences in client targeted for Solaris 7 running on Solaris 10 compared to a targeted Solaris 10 running on Solaris 10? According to the docs for GCC 4.0.2, by default it creates a v7 target. I am guessing you use -mpu= v9 or ultrasparc or ultrasparc3 options.
I am guessing portability is most important to keep up with all the different possible clients. Sticking with just the command line versions, is there much difference between Windows, Mac OSX, Linux and Solaris?
____________
The SPARC/Solaris platform is just slow. I went through a lot of the workunits that were done on the machines and their processing time is way up there compared to other platforms. In the stats for Sparcs, not one is above 1000 in fpiops and Iops isn't much better, 2510 is tops with the top 10 percent in the 1500-1000 range.
____________
SPARC optimizations with GCC. I think this may help future development concerning Sparcs if it wasn't done already.
Article from OSNews.
SPARC Optimizations
____________
Bernd MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
SPARC optimizations with GCC. I think this may help future development concerning Sparcs if it wasn't done already.
Article from OSNews.
SPARC Optimizations
Thanks, this looks useful. However I just checked again - -mcpu=ultrasparc doesn't gain anything with the current code. I expect some speedup once I get the autovect feature of GCC 4 to recognize our loops as vectorizable and use vis, but this may take some time.
BM
____________
BM
SPARC optimizations with GCC. I think this may help future development concerning Sparcs if it wasn't done already.
Article from OSNews.
SPARC Optimizations
Thanks, this looks useful. However I just checked again - -mcpu=ultrasparc doesn't gain anything with the current code. I expect some speedup once I get the autovect feature of GCC 4 to recognize our loops as vectorizable and use vis, but this may take some time.
BM
Another thing to look at, just released by Sun is their own SPARC optimizing backend for GCC. It uses the GCC ABI, so it should work with other GCC-built apps (i.e. boinc).
http://cooltools.sunsource.net/gcc/index.html
Bernd MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
Another thing to look at, just released by Sun is their own SPARC optimizing backend for GCC. It uses the GCC ABI, so it should work with other GCC-built apps (i.e. boinc).
http://cooltools.sunsource.net/gcc/index.html
Thanks, this looks incredibly useful. However, this is only available for Solaris 9 and up.
I'm currently trying to compile the vector-code that's e.g. in the current Linux Beta Test App into a Solaris App that uses the VIS extension. However I have to use Suns linker and assembler, which forces me to compile _everything_ (all code and libraries used) in 64 Bit in order to properly link it together. Has anyone built a full 64-bit-enabled gcc (4.0.1 or newer) on Solaris 7?
BM
____________
BM
Bernd MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
A new App for Solaris SPARC is available. See this thread.
BM
____________
BM
Bernd MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,466,965
RAC: 31,272
I expect some speedup once I get the autovect feature of GCC 4 to recognize our loops as vectorizable and use vis, but this may take some time.
Hm. I just found out that VIS is integer only. Doesn't help for our purposes at all. Bad luck.
BM
____________
BM