| Author |
Message |
TravisVolunteer moderator Project administrator Project developer Project tester Project scientist Send message
Joined: 30 Aug 07 Posts: 1976 Credit: 26,480 RAC: 0
|
|
Please post any problems with the 32 bit linux app here.
____________
|
|
|
|
|
|
any idea of when it will actually be available? |
|
|
TravisVolunteer moderator Project administrator Project developer Project tester Project scientist Send message
Joined: 30 Aug 07 Posts: 1976 Credit: 26,480 RAC: 0
|
any idea of when it will actually be available?
We need to get a 32 bit linux machine to compile it on... I thought Dave had one but it's not looking like it. If anyone wants to compile the latest code for it and send us the binary we can make it available that way as well.
(update) I'm going to see if our linux system will let us compile 32 bit binaries, if so we can probably make it available today.
____________
|
|
|
|
|
|
still no news? |
|
|
TravisVolunteer moderator Project administrator Project developer Project tester Project scientist Send message
Joined: 30 Aug 07 Posts: 1976 Credit: 26,480 RAC: 0
|
still no news?
Not yet, neither of us have access to a 32 bit linux machine.
____________
|
|
|
TravisVolunteer moderator Project administrator Project developer Project tester Project scientist Send message
Joined: 30 Aug 07 Posts: 1976 Credit: 26,480 RAC: 0
|
still no news?
Not yet, neither of us have access to a 32 bit linux machine.
____________
|
|
|
TravisVolunteer moderator Project administrator Project developer Project tester Project scientist Send message
Joined: 30 Aug 07 Posts: 1976 Credit: 26,480 RAC: 0
|
|
Update to this -- We got some pre-compiled 32 bit linux boinc libraries, so we can just link our app to those and hopefully things should be peachy-keen. Hopefully have a 32bit linux app out tonight or tomorrow.
____________
|
|
|
|
|
|
i'm testing it right now -- so far, no problem. |
|
|
|
|
|
Got some nm_test25s and the 04 linux 32bit client.
Still have the checkpointing problem, client crashes on a restart.
[edit]Otherwise its finished a work unit correctly.[/edit] |
|
|
|
|
|
Errm, wrong thread... *grin*
____________
Lovely greetings, Cori
|
|
|
|
|
|
Just did my first new WU: nm_test11_75_1227466845_2 (app 0.4)
No problems - valid.
Although the stderr out doesn't look 'clean':
<core_client_version>6.2.12</core_client_version>
<![CDATA[
<stderr_txt>
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1227985432.136000
Skipping: /computation_deadline
Unrecognized XML in GLOBAL_PREFS::parse_override: mod_time
Skipping: /mod_time
Unrecognized XML in GLOBAL_PREFS::parse_override: max_ncpus_pct
Skipping: 100.000000
Skipping: /max_ncpus_pct
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
</stderr_txt>
]]>
Creditwise it's exactly the same as milksop's app on my Q9550.
(2x crunch-time -->> 2x the credit)
____________
mic.
|
|
|
|
|
|
i just had some nm_test10 with following result:
Outcome Client error
Client state Downloading
Exit status -186 (0xffffffffffffff46)
<core_client_version>6.2.18</core_client_version>
<![CDATA[
<message>
WU download error: couldn't get input files:
<file_xfer_error>
<file_name>stars.txt</file_name>
<error_code>-224</error_code>
<error_message>file not found</error_message>
</file_xfer_error>
</message>
]]>
nm_test25 were fine.
edit: nm_test25 were fine but with same stdout as post above |
|
|
|
|
|
Got about 70 WUs, really quick: 00:11 instead of 04:53.
Seem to work fine but stderr out complains a bit:
stderr out
<core_client_version>5.10.45</core_client_version>
<![CDATA[
<stderr_txt>
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
</stderr_txt>
]]>
Edit: oops..3 failed:
<core_client_version>5.10.45</core_client_version>
<![CDATA[
<message>
WU download error: couldn't get input files:
<file_xfer_error>
<file_name>astronomy_parameters_nm_test24.txt</file_name>
<error_code>-119</error_code>
<error_message>MD5 check failed</error_message>
</file_xfer_error>
</message>
]]>
Not with nm_test25 or nm_test26 though, they seem fine. |
|
|
|
|
|
Ok Travis, I have downloaded your new stock app to see how it is going, mainly as you are going to cease the 1.22 Op app anyway and I could not get work.
They run quite a bit longer than the Milksop 1.22 op app.
(I have had to be very quick to get the results, even then I only got a couple then they were gone).
The 'test' WU's run about twice as long as the Milksop app but the 'stripe' WU's run heaps longer and vary between different stripe versions (79; 86 etc).
Also the run time between Windows and Linux is still quite a bit different to each other on the same WU type. Windows is much faster, this was the case on the original stock app, Milksop's app and now your new app (v0.04).
AMD Opteron 285 Linux FC6....'stripe79_1' WU...3,652 sec, Op App..389 sec
AMD Opteron 285 Windows XP...'stripe79_1' WU...2,837 sec, Op App..351 sec
As you can see run times on near identical machines is slower with Linux.
(I have noticed some variation in the run times of 'stripe79' WU's, so maybe it is not as consistent as the previous work units).
The 'test' apps on my Linux machine run for about 910 sec on 'test26' and 920 sec on 'test27'.
On my Intel P4 2.53 the 'test25' work units run for about 1,269 sec, not much slower than my Opteron, which user to be twice as quick at doing a WU.
Maybe I need to learn how to compile source code on Linux ???
With the longer Work Units I have not had too much problem with the 8 WU limit per CPU.
Thanks Travis and Dave for all your hard work on this.
EDIT:-- Have just read another post (post is '20 work unit limit') about the difference in 'stripe79' and 'stripe79_1' and why they are not the same length.
____________
|
|
|
|
|
|
Just had one error out after 35 minutes.
Task ID 56879889
Name nm_stripe79_1_13099_1228123065_0
Workunit 57100851
Created 1 Dec 2008 9:17:50 UTC
Sent 1 Dec 2008 9:28:30 UTC
Received 1 Dec 2008 11:21:52 UTC
Server state Over
Outcome Client error
Client state Compute error
Exit status 255 (0xff)
Computer ID 36872
Report deadline 4 Dec 2008 9:28:30 UTC
CPU time 2143.636117
stderr out
<core_client_version>6.4.1</core_client_version>
<![CDATA[
<message>
process exited with code 255 (0xff, -1)
</message>
<stderr_txt>
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1228379223.600000
Skipping: /computation_deadline
Unrecognized XML in GLOBAL_PREFS::parse_override: mod_time
Skipping: /mod_time
Unrecognized XML in GLOBAL_PREFS::parse_override: max_ncpus_pct
Skipping: 100.000000
Skipping: /max_ncpus_pct
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1228379223.600000
Skipping: /computation_deadline
Unrecognized XML in GLOBAL_PREFS::parse_override: mod_time
Skipping: /mod_time
Unrecognized XML in GLOBAL_PREFS::parse_override: max_ncpus_pct
Skipping: 100.000000
Skipping: /max_ncpus_pct
Error reading into stream_integrals
</stderr_txt>
]]>
Validate state Invalid
Claimed credit 5.05409120118583
Granted credit 0
application version 0.04
This was after detaching/reattaching to get the stock app.
____________
Kathryn :o)
The BOINC FAQ Service
The Unofficial BOINC Wiki
The Trac System
More BOINC information than you can shake a stick of RAM at. |
|
|
|
|
|
Thanks Conan! I was going to run my windoz down and check #'s on Linux but I guess since you've already done it I'll stick with Windoz!
____________
A clear conscience is usually the sign of a bad memory
|
|
|
|
|
|
And what with linux machines with gcc libs older than 4.2.0?
cheers
mindc |
|
|
TravisVolunteer moderator Project administrator Project developer Project tester Project scientist Send message
Joined: 30 Aug 07 Posts: 1976 Credit: 26,480 RAC: 0
|
Just had one error out after 35 minutes.
Task ID 56879889
Name nm_stripe79_1_13099_1228123065_0
Workunit 57100851
Created 1 Dec 2008 9:17:50 UTC
Sent 1 Dec 2008 9:28:30 UTC
Received 1 Dec 2008 11:21:52 UTC
Server state Over
Outcome Client error
Client state Compute error
Exit status 255 (0xff)
Computer ID 36872
Report deadline 4 Dec 2008 9:28:30 UTC
CPU time 2143.636117
stderr out
<core_client_version>6.4.1</core_client_version>
<![CDATA[
<message>
process exited with code 255 (0xff, -1)
</message>
<stderr_txt>
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1228379223.600000
Skipping: /computation_deadline
Unrecognized XML in GLOBAL_PREFS::parse_override: mod_time
Skipping: /mod_time
Unrecognized XML in GLOBAL_PREFS::parse_override: max_ncpus_pct
Skipping: 100.000000
Skipping: /max_ncpus_pct
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
APP: error writing checkpoint (closing checkpoint file) 0
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1228379223.600000
Skipping: /computation_deadline
Unrecognized XML in GLOBAL_PREFS::parse_override: mod_time
Skipping: /mod_time
Unrecognized XML in GLOBAL_PREFS::parse_override: max_ncpus_pct
Skipping: 100.000000
Skipping: /max_ncpus_pct
Error reading into stream_integrals
</stderr_txt>
]]>
Validate state Invalid
Claimed credit 5.05409120118583
Granted credit 0
application version 0.04
This was after detaching/reattaching to get the stock app.
There's an issue with checkpointing v0.4 and lower, this should be fixed with version 0.6
____________
|
|
|
|
|
AMD Opteron 285 Linux FC6....'stripe79_1' WU...3,652 sec, Op App..389 sec
AMD Opteron 285 Windows XP...'stripe79_1' WU...2,837 sec, Op App..351 sec
As you can see run times on near identical machines is slower with Linux.
It might be because Linux manages power differently from Windows, running BOINC applications at a slow CPU frequency in order to save energy. See more details here.
HTH
____________
|
|
|
|
|
And what with linux machines with gcc libs older than 4.2.0?
Is it too much to ask that the application be linked with the GCC option -static-libgcc in order to avoid this issue?
TIA
____________
|
|
|
TravisVolunteer moderator Project administrator Project developer Project tester Project scientist Send message
Joined: 30 Aug 07 Posts: 1976 Credit: 26,480 RAC: 0
|
And what with linux machines with gcc libs older than 4.2.0?
Is it too much to ask that the application be linked with the GCC option -static-libgcc in order to avoid this issue?
TIA
I'll give it a shot. Although I'm not sure why you wouldn't want to update your gcc.... :P
I think the problem is for whatever library reason people in the past had asked for a dynamically linked linux app... not quite sure if we can have it both ways. lol.
____________
|
|
|
|
|
I'll give it a shot. Although I'm not sure why you wouldn't want to update your gcc.... :P
Simply because they're production systems for which I don't have root access.
Thanks.
____________
|
|
|
|
|
|
I am getting computation errors on all work units since the .4 and now the .6 release. I am running (attempting to) an older version of Linux (Red Hat 7.3) with a 2.4.32 kernel update. I am unable to alter any OS or kernel system levels as this is are production systems. Is there hope that this will be resolved or should I be looking for another BOINC project? |
|
|
|
|
|
Just having a quick look at your error messages and you seem to be missing a file "libstdc++.so.6". You do have one system running 2.4.18bigmen Linux and this one seems to doing work units ok, so it might be something with the other Linux version.
____________
|
|
|
|
|
Just having a quick look at your error messages and you seem to be missing a file "libstdc++.so.6". You do have one system running 2.4.18bigmen Linux and this one seems to doing work units ok, so it might be something with the other Linux version.
Uh... If he's missing libstdc++.so, he won't be able to run any programs written in C++ and dynamically linked, which is impossible. More than likely, this is a problem with that the MilkyWay app is dynamically linked when it should statically linked. Travis?
____________
|
|
|
|
|
Uh... If he's missing libstdc++.so, he won't be able to run any programs written in C++ and dynamically linked, which is impossible. More than likely, this is a problem with that the MilkyWay app is dynamically linked when it should statically linked. Travis?
Actually, more than likely he has an older version of the library, probably libstdc++.so.5.
Here's how to link that library statically: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=488&nowrap=true#6784.
HTH
____________
|
|
|
TravisVolunteer moderator Project administrator Project developer Project tester Project scientist Send message
Joined: 30 Aug 07 Posts: 1976 Credit: 26,480 RAC: 0
|
Just having a quick look at your error messages and you seem to be missing a file "libstdc++.so.6". You do have one system running 2.4.18bigmen Linux and this one seems to doing work units ok, so it might be something with the other Linux version.
Uh... If he's missing libstdc++.so, he won't be able to run any programs written in C++ and dynamically linked, which is impossible. More than likely, this is a problem with that the MilkyWay app is dynamically linked when it should statically linked. Travis?
Maybe that's the problem. Should there be any problems with the linux app if i link everything statically?
____________
|
|
|
|
|
Maybe that's the problem. Should there be any problems with the linux app if i link everything statically?
Hardly, but instead of such a brute-force approach, it's not that difficult to link only selected libraries statically.
HTH
____________
|
|
|
TravisVolunteer moderator Project administrator Project developer Project tester Project scientist Send message
Joined: 30 Aug 07 Posts: 1976 Credit: 26,480 RAC: 0
|
Uh... If he's missing libstdc++.so, he won't be able to run any programs written in C++ and dynamically linked, which is impossible. More than likely, this is a problem with that the MilkyWay app is dynamically linked when it should statically linked. Travis?
Actually, more than likely he has an older version of the library, probably libstdc++.so.5.
Here's how to link that library statically: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=488&nowrap=true#6784.
HTH
The new version of the linux binaries should have llibstdc and libstdc++ linked statically as per the above instructions (i hope). Let me know how they work out.
____________
|
|
|
|
|
The new version of the linux binaries should have llibstdc and libstdc++ linked statically as per the above instructions (i hope). Let me know how they work out.
No dice:
$ ldd ~/milkyway_0.7_*
milkyway_0.7_i686-pc-linux-gnu:
linux-gate.so.1 => (0xffffe000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x5556d000)
libm.so.6 => /lib/tls/libm.so.6 (0x55661000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x55683000)
libc.so.6 => /lib/tls/libc.so.6 (0x55694000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x557ae000)
/lib/ld-linux.so.2 (0x55555000)
milkyway_0.7_x86_64-pc-linux-gnu:
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b2f8cbb7000)
libm.so.6 => /lib64/tls/libm.so.6 (0x00002b2f8cdb4000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002b2f8cf0c000)
libc.so.6 => /lib64/tls/libc.so.6 (0x00002b2f8d020000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b2f8d248000)
/lib64/ld-linux-x86-64.so.2 (0x00002b2f8caa0000)
As you can see, libstdc++, libc and libgcc are still being dynamically linked.
Since you're having some trouble, try static linking by specifying the GCC option -static then.
HTH
____________
|
|
|
TravisVolunteer moderator Project administrator Project developer Project tester Project scientist Send message
Joined: 30 Aug 07 Posts: 1976 Credit: 26,480 RAC: 0
|
|
This is what i have the makefile doing right now:
g++ -L/usr/local/lib -O2 -msse2 -ftree-vectorize -funroll-loops -DGMLE_BOINC -g -O -I/software/boinc-6.3.14-0/pkg/include/boinc -Wl -static -static-libgcc -Wl,-Bstatic `gcc -print-file-name=libstdc++.a` -Wl,-Bdynamic -o milkyway_0.7_x86_64-pc-linux-gnu ../astronomy/boinc_astronomy.o ../astronomy/atSurveyGeometry.o ../astronomy/numericalIntegration.o ../astronomy/parameters.o ../astronomy/probability.o ../astronomy/stCoords.o ../astronomy/stCnum.o ../astronomy/stMath.o ../astronomy/stVector.o ../astronomy/star_points.o ../astronomy/evaluation_optimized.o ../astronomy/evaluation_state.o ../searches/search_parameters.o ../util/io_util.o ../util/settings.o -lm -lboinc_api -lboinc -pthread
then im getting:
ldd milkyway_0.7_x86_64-pc-linux-gnu
/usr/bin/ldd: line 116: ./milkyway_0.7_x86_64-pc-linux-gnu: No such file or directory
when i try and compile with gcc, i get a whooooooole lot of errors. any suggestions?
____________
|
|
|
|
|
This is what i have the makefile doing right now:
g++ -L/usr/local/lib -O2 -msse2 -ftree-vectorize -funroll-loops -DGMLE_BOINC -g -O -I/software/boinc-6.3.14-0/pkg/include/boinc -Wl -static -static-libgcc -Wl,-Bstatic `gcc -print-file-name=libstdc++.a` -Wl,-Bdynamic -o milkyway_0.7_x86_64-pc-linux-gnu ../astronomy/boinc_astronomy.o ../astronomy/atSurveyGeometry.o ../astronomy/numericalIntegration.o ../astronomy/parameters.o ../astronomy/probability.o ../astronomy/stCoords.o ../astronomy/stCnum.o ../astronomy/stMath.o ../astronomy/stVector.o ../astronomy/star_points.o ../astronomy/evaluation_optimized.o ../astronomy/evaluation_state.o ../searches/search_parameters.o ../util/io_util.o ../util/settings.o -lm -lboinc_api -lboinc -pthread
then im getting:
ldd milkyway_0.7_x86_64-pc-linux-gnu
/usr/bin/ldd: line 116: ./milkyway_0.7_x86_64-pc-linux-gnu: No such file or directory
when i try and compile with gcc, i get a whooooooole lot of errors. any suggestions?
try
g++ -L/usr/local/lib -O2 -msse2 -ftree-vectorize -funroll-loops -DGMLE_BOINC -g -O -I/software/boinc-6.3.14-0/pkg/include/boinc -static -o milkyway_0.7_x86_64-pc-linux-gnu ../astronomy/boinc_astronomy.o ../astronomy/atSurveyGeometry.o ../astronomy/numericalIntegration.o ../astronomy/parameters.o ../astronomy/probability.o ../astronomy/stCoords.o ../astronomy/stCnum.o ../astronomy/stMath.o ../astronomy/stVector.o ../astronomy/star_points.o ../astronomy/evaluation_optimized.o ../astronomy/evaluation_state.o ../searches/search_parameters.o ../util/io_util.o ../util/settings.o -lm -lboinc_api -lboinc -pthread
____________
Join BOINC United now! |
|
|
|
|
|
- you must remove the lone -O or it will turn off the optimizations you wanted from -O2.
- you don't need -Wl -static before -static-libgcc.
- move -Wl,-Bstatic `gcc -print-file-name=libstdc++.a` -Wl,-Bdynamic to right before -lm or at the end of the command-line.
IOW:
g++ -L/usr/local/lib -O2 -msse2 -ftree-vectorize -funroll-loops -DGMLE_BOINC -g -I/software/boinc-6.3.14-0/pkg/include/boinc -static-libgcc -o milkyway_0.7_x86_64-pc-linux-gnu ../astronomy/boinc_astronomy.o ../astronomy/atSurveyGeometry.o ../astronomy/numericalIntegration.o ../astronomy/parameters.o ../astronomy/probability.o ../astronomy/stCoords.o ../astronomy/stCnum.o ../astronomy/stMath.o ../astronomy/stVector.o ../astronomy/star_points.o ../astronomy/evaluation_optimized.o ../astronomy/evaluation_state.o ../searches/search_parameters.o ../util/io_util.o ../util/settings.o -Wl,-Bstatic `gcc -print-file-name=libstdc++.a` -Wl,-Bdynamic -lm -lboinc_api -lboinc -pthread
Or:
g++ -L/usr/local/lib -O2 -msse2 -ftree-vectorize -funroll-loops -DGMLE_BOINC -g -I/software/boinc-6.3.14-0/pkg/include/boinc -static-libgcc -o milkyway_0.7_x86_64-pc-linux-gnu ../astronomy/boinc_astronomy.o ../astronomy/atSurveyGeometry.o ../astronomy/numericalIntegration.o ../astronomy/parameters.o ../astronomy/probability.o ../astronomy/stCoords.o ../astronomy/stCnum.o ../astronomy/stMath.o ../astronomy/stVector.o ../astronomy/star_points.o ../astronomy/evaluation_optimized.o ../astronomy/evaluation_state.o ../searches/search_parameters.o ../util/io_util.o ../util/settings.o -lm -lboinc_api -lboinc -pthread -Wl,-Bstatic `gcc -print-file-name=libstdc++.a` -Wl,-Bdynamic
HTH
____________
|
|
|
|
|
- you must remove the lone -O or it will turn off the optimizations you wanted from -O2.
- you don't need -Wl -static before -static-libgcc.
- move -Wl,-Bstatic `gcc -print-file-name=libstdc++.a` -Wl,-Bdynamic to right before -lm or at the end of the command-line.
I should add that you don't -msse2 either. That's because for 32 bits it's innefective without -mfpmath=sse, which you don't want to use unless you don't care about losing those systems with a Pentium III or an Athlon XP.
Finally, -msse2 is implied for 64 bits, as well as -mfpmath=sse. However, since all x86-64 systems are required to have SSE2, you can also enable -ftree-vectorize (which is implied in -O3 for GCC 4.3 and later) when building the application for such systems.
HTH
____________
|
|
|
|
|
... which you don't want to use unless you don't care about losing those systems with a Pentium III or an Athlon XP.
I got some statistics about this based on POEM's volunteer Linux systems: 13% support only SSE1, 70% support up to SSE2 and 17% support up to SSE3.
More details here.
HTH
____________
|
|
|
TravisVolunteer moderator Project administrator Project developer Project tester Project scientist Send message
Joined: 30 Aug 07 Posts: 1976 Credit: 26,480 RAC: 0
|
... which you don't want to use unless you don't care about losing those systems with a Pentium III or an Athlon XP.
I got some statistics about this based on POEM's volunteer Linux systems: 13% support only SSE1, 70% support up to SSE2 and 17% support up to SSE3.
More details here.
HTH
I think since it's a stock app, it should be as widely available as possible. The code is open source so people can download and compile it if they want the extra performance from those options.
____________
|
|
|
|
|
|
It doesn't seem to be much difference between 64-32bits now, took the trouble installing a 64 bit system and it's maybe only a minute faster on a Q6600. |
|
|
|
|
|
hi,
i've had a few like this:
Task ID 57282354
Name nm_stripe79_r7_97614_1228621541_0
Workunit 57473467
Created 7 Dec 2008 3:45:44 UTC
Sent 7 Dec 2008 3:54:29 UTC
Received 7 Dec 2008 8:40:23 UTC
Server state Over
Outcome Client error
Client state Compute error
Exit status 193 (0xc1)
Computer ID 40346
Report deadline 10 Dec 2008 3:54:29 UTC
CPU time 121.175572
stderr out
<core_client_version>6.4.3</core_client_version>
<![CDATA[
<message>
process exited with code 193 (0xc1, -63)
</message>
<stderr_txt>
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1228880368.136000
Skipping: /computation_deadline
Unrecognized XML in GLOBAL_PREFS::parse_override: mod_time
Skipping: /mod_time
Unrecognized XML in GLOBAL_PREFS::parse_override: max_ncpus_pct
Skipping: 100.000000
Skipping: /max_ncpus_pct
SIGSEGV: segmentation violation
Stack trace (8 frames):
milkyway_0.7_i686-pc-linux-gnu[0x805def5]
[0xb8037400]
milkyway_0.7_i686-pc-linux-gnu[0x8057640]
milkyway_0.7_i686-pc-linux-gnu[0x8057beb]
milkyway_0.7_i686-pc-linux-gnu(__gxx_personality_v0+0x24b)[0x804a893]
milkyway_0.7_i686-pc-linux-gnu(__gxx_personality_v0+0x345)[0x804a98d]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7d8a685]
milkyway_0.7_i686-pc-linux-gnu(__gxx_personality_v0+0xb9)[0x804a701]
Exiting...
</stderr_txt>
]]>
Validate state Invalid
Claimed credit 0.837180701858857
Granted credit 0
application version 0.07
of course i just switched back to kubuntu from debian and installed boinc 6.4.3, so that may have an impact. |
|
|
|
|
|
Running well for me.
Fedora 9 on an Intel Core Duo laptop with some random alpha build of BOINC. I really need to update...
____________
Kathryn :o)
The BOINC FAQ Service
The Unofficial BOINC Wiki
The Trac System
More BOINC information than you can shake a stick of RAM at. |
|
|
|
|
hi,
i've had a few like this:
Task ID 57282354
Name nm_stripe79_r7_97614_1228621541_0
Workunit 57473467
Created 7 Dec 2008 3:45:44 UTC
Sent 7 Dec 2008 3:54:29 UTC
Received 7 Dec 2008 8:40:23 UTC
Server state Over
Outcome Client error
Client state Compute error
Exit status 193 (0xc1)
Computer ID 40346
Report deadline 10 Dec 2008 3:54:29 UTC
CPU time 121.175572
stderr out
<core_client_version>6.4.3</core_client_version>
<![CDATA[
<message>
process exited with code 193 (0xc1, -63)
</message>
<stderr_txt>
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1228880368.136000
Skipping: /computation_deadline
Unrecognized XML in GLOBAL_PREFS::parse_override: mod_time
Skipping: /mod_time
Unrecognized XML in GLOBAL_PREFS::parse_override: max_ncpus_pct
Skipping: 100.000000
Skipping: /max_ncpus_pct
SIGSEGV: segmentation violation
Stack trace (8 frames):
milkyway_0.7_i686-pc-linux-gnu[0x805def5]
[0xb8037400]
milkyway_0.7_i686-pc-linux-gnu[0x8057640]
milkyway_0.7_i686-pc-linux-gnu[0x8057beb]
milkyway_0.7_i686-pc-linux-gnu(__gxx_personality_v0+0x24b)[0x804a893]
milkyway_0.7_i686-pc-linux-gnu(__gxx_personality_v0+0x345)[0x804a98d]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7d8a685]
milkyway_0.7_i686-pc-linux-gnu(__gxx_personality_v0+0xb9)[0x804a701]
Exiting...
</stderr_txt>
]]>
Validate state Invalid
Claimed credit 0.837180701858857
Granted credit 0
application version 0.07
of course i just switched back to kubuntu from debian and installed boinc 6.4.3, so that may have an impact.
I've run 0.4, 0.6 and 0.7 with Mandrivel with no probs. |
|
|
|
|
|
Got 8 of these errors today when network connection was capped and boinc is sending a Sheduler request, same thing happened 2-3 days ago, process gets killed when trying to connect. Boinc 6.2.15
Task ID 57511334
Name nm_stripe86_r8_29498_1228841620_0
Workunit 57695184
Created 9 Dec 2008 16:53:48 UTC
Sent 9 Dec 2008 17:08:01 UTC
Received 9 Dec 2008 22:39:12 UTC
Server state Over
Outcome Client error
Client state Compute error
Exit status 11 (0xb)
Computer ID 18333
Report deadline 12 Dec 2008 17:08:01 UTC
CPU time 216.566076
stderr out
<core_client_version>6.2.15</core_client_version>
<![CDATA[
<message>
process got signal 11
</message>
<stderr_txt>
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1228666081.000000
Skipping: /computation_deadline
Unrecognized XML in GLOBAL_PREFS::parse_override: mod_time
Skipping: /mod_time
Unrecognized XML in GLOBAL_PREFS::parse_override: max_ncpus_pct
Skipping: 100.000000
Skipping: /max_ncpus_pct
</stderr_txt>
]]>
Validate state Invalid
Claimed credit 1.27301137603241
Granted credit 0
application version 0.07
Looked like this in the commandline on 4 of the ones:
08-Dec-2008 22:03:29 [Milkyway@home] Temporarily failed upload of nm_stripe86_r7_23373_1228836170_0_0: connect() failed
08-Dec-2008 22:03:29 [Milkyway@home] Backing off 1 min 0 sec on upload of nm_stripe86_r7_23373_1228836170_0_0
08-Dec-2008 22:04:51 [Milkyway@home] Sending scheduler request: To report completed tasks. Requesting 1752190 seconds of work, reporting 3 completed tasks
08-Dec-2008 22:04:51 [Milkyway@home] Started upload of nm_stripe86_r7_23373_1228836170_0_0
08-Dec-2008 22:04:51 [Milkyway@home] Computation for task nm_stripe79_r8_23663_1228836645_0 finished
08-Dec-2008 22:04:51 [Milkyway@home] Output file nm_stripe79_r8_23663_1228836645_0_0 for task nm_stripe79_r8_23663_1228836645_0 absent
08-Dec-2008 22:04:51 [Milkyway@home] Starting nm_stripe79_r7_29506_1228842124_0
08-Dec-2008 22:04:51 [Milkyway@home] Starting task nm_stripe79_r7_29506_1228842124_0 using milkyway version 7
08-Dec-2008 22:04:52 [Milkyway@home] Computation for task nm_stripe82_r7_23691_1228836646_0 finished
08-Dec-2008 22:04:52 [Milkyway@home] Output file nm_stripe82_r7_23691_1228836646_0_0 for task nm_stripe82_r7_23691_1228836646_0 absent
08-Dec-2008 22:04:52 [Milkyway@home] Starting nm_stripe79_r7_29522_1228842125_0
08-Dec-2008 22:04:52 [Milkyway@home] Starting task nm_stripe79_r7_29522_1228842125_0 using milkyway version 7
08-Dec-2008 22:04:53 [Milkyway@home] Temporarily failed upload of nm_stripe86_r7_23373_1228836170_0_0: connect() failed
08-Dec-2008 22:04:53 [Milkyway@home] Backing off 1 min 0 sec on upload of nm_stripe86_r7_23373_1228836170_0_0
08-Dec-2008 22:04:53 [Milkyway@home] Computation for task nm_stripe79_r8_23634_1228836644_0 finished
08-Dec-2008 22:04:53 [Milkyway@home] Output file nm_stripe79_r8_23634_1228836644_0_0 for task nm_stripe79_r8_23634_1228836644_0 absent
08-Dec-2008 22:04:53 [Milkyway@home] Starting nm_stripe86_r7_29345_1228841617_0
08-Dec-2008 22:04:53 [Milkyway@home] Starting task nm_stripe86_r7_29345_1228841617_0 using milkyway version 7
08-Dec-2008 22:04:54 [Milkyway@home] Computation for task nm_stripe82_r8_23760_1228836648_0 finished
08-Dec-2008 22:04:54 [Milkyway@home] Output file nm_stripe82_r8_23760_1228836648_0_0 for task nm_stripe82_r8_23760_1228836648_0 absent
08-Dec-2008 22:04:54 [Milkyway@home] Starting nm_stripe86_r8_29446_1228841619_0
08-Dec-2008 22:04:54 [Milkyway@home] Starting task nm_stripe86_r8_29446_1228841619_0 using milkyway version 7
08-Dec-2008 22:04:56 [Milkyway@home] Scheduler request failed: Couldn't connect to server
Have some old boincies in storage, 5.2.13 was nice :) |
|
|
|
|
|
Some WUs run extremely long time, I have aborted this one after over 18 hours:
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=57580672
[edit]I use official application[/edit] |
|
|
|
|
Some WUs run extremely long time, I have aborted this one after over 18 hours:
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=57580672
Yup, same here, I have three nm_stripe_79_fr1 running for over four hours and only 45% done.
Well I don't mind if they are long, the longer the better..
|
|
|
|
|
Some WUs run extremely long time, I have aborted this one after over 18 hours:
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=57580672
Yup, same here, I have three nm_stripe_79_fr1 running for over four hours and only 45% done.
Well I don't mind if they are long, the longer the better..
Those are broken.
Look here: Bad set of WUs !
____________
mic.
|
|
|
|
|
|
Just curious (and this has probably been stated before, maybe even by me in a thread I can't find), why does my Linux Opteron 285 machine take over 10 minutes longer to process a MilkyWay work unit than my Windows Opteron 285 machine ???
On average my Windows machine takes around 2,600 seconds but my Linux box takes around 3,300 seconds.
They are the same specifications bar different hard drives.
Is it just a compiling thing, as in a compiler more suited to Linux might change things ??
____________
|
|
|
|
|
Just curious (and this has probably been stated before, maybe even by me in a thread I can't find), why does my Linux Opteron 285 machine take over 10 minutes longer to process a MilkyWay work unit than my Windows Opteron 285 machine ???
On average my Windows machine takes around 2,600 seconds but my Linux box takes around 3,300 seconds.
They are the same specifications bar different hard drives.
Is it just a compiling thing, as in a compiler more suited to Linux might change things ??
True, different compilers, different results. But most importantly, Linux keeps the CPU at the lowest frequency when just running low-priority BOINC applications, whereas Windows throws the CPU at the highest frequency for them too. See more details here.
HTH
____________
|
|
|
|
|
|
Thanks Augustine, I will try and check this out.
EDIT: I am unable to find any folder or file relating to power that has any reference to 'Powersave'. So I am not sure if it exists with Fedora Core 3 or 6.
Throttling is not supported on the FC3 machine as far as I can tell.
(The computer having the slower run times runs Fedora Core 6, still another Opteron 285).
____________
|
|
|
|
|
|
SUSE linux (2.6.5-7.191-smp), BOINC v.5.10.45
still get an error:
20/12/2008 14:52:50|Milkyway@home|Starting nm_stripe86_fr1_242469_1229776663_0
20/12/2008 14:52:50|Milkyway@home|Starting task nm_stripe86_fr1_242469_1229776663_0 using milkyway version 7
20/12/2008 14:52:54|Milkyway@home|Computation for task nm_stripe86_fr1_242469_1229776663_0 finished
20/12/2008 14:52:54|Milkyway@home|Output file nm_stripe86_fr1_242469_1229776663_0_0 for task nm_stripe86_fr1_242469_1229776663_0 absent
<core_client_version>5.10.45</core_client_version>
<![CDATA[
<message>
process exited with code 127 (0x7f, -129)
</message>
<stderr_txt>
milkyway_0.7_i686-pc-linux-gnu: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
</stderr_txt>
]]> |
|
|
|
|
True, different compilers, different results. But most importantly, Linux keeps the CPU at the lowest frequency when just running low-priority BOINC applications, whereas Windows throws the CPU at the highest frequency for them too. See more details here.
HTH
No I don't believe in that |
|
|
|
|
No I don't believe in that
What do you mean? It's either true or it isn't - I don't know which and I don't feel like checking, but there is no magic here. |
|
|
|
|
No I don't believe in that
What do you mean? It's either true or it isn't - I don't know which and I don't feel like checking, but there is no magic here.
My Linux boxen have always run at full speed for many years and there is no throttling at all. |
|
|
|
|
My Linux boxen have always run at full speed for many years and there is no throttling at all.
Your "boxen" have up-to-date processors and kernel, so you should be able to type "powersave -r" from the command-line when the system is idle to check the effective CPU frequency.
Most current standard Linux set ups come with default power management that's more sophisticated than old throttling.
HTH
____________
|
|
|
|
|
My Linux boxen have always run at full speed for many years and there is no throttling at all.
Your "boxen" have up-to-date processors and kernel, so you should be able to type "powersave -r" from the command-line when the system is idle to check the effective CPU frequency.
Most current standard Linux set ups come with default power management that's more sophisticated than old throttling.
HTH
If an idle box can save power that's nice
Tested Fedora and Ubuntu renicing the app to 0 and there is no difference in runtimes
|
|
|