2006-04-11 19:44:08.2175 [normal]: Start of BOINC application 'albert_4.55_i686-pc-linux-gnu'.
2006-04-11 19:44:08.2617 [normal]: Started search at lalDebugLevel = 0
2006-04-11 19:44:10.1300 [normal]: Checkpoint-file 'Fstat.out.ckp' not found.
2006-04-11 19:44:10.1302 [normal]: No usable checkpoint found, starting from beginning.
Detected CPU type 1
2006-04-11 19:44:10.1325 [CRITICAL]: APP DEBUG: Application caught signal 11.
2006-04-11 19:44:10.1325 [CRITICAL]: Stack trace of LAL functions in worker thread:
2006-04-11 19:44:10.1325 [CRITICAL]: TestLALDemod at line 44 of file /home/bema/einsteinathome/CFS/EaH_build_release_albert_4.55/extra_sources/lalapps-CVS/src/pulsar/FDS_isolated/CFSLALDemod_ndp_vect.c
2006-04-11 19:44:10.1326 [CRITICAL]: At lowest level status code = 0, description: NO LAL ERROR REGISTERED
2006-04-11 19:44:10.1326 [CRITICAL]: Obtained 8 stack frames for this thread.
2006-04-11 19:44:10.1326 [CRITICAL]: Use gdb command: 'info line *0xADDRESS' to print corresponding line numbers.
albert_4.55_i686-pc-linux-gnu(sighandler+0x95)[0x808abcd]
/lib/libpthread.so.0[0x4005312b]
/lib/libc.so.6[0x40088d68]
albert_4.55_i686-pc-linux-gnu(boincmain+0xc8c)[0x807f8cc]
albert_4.55_i686-pc-linux-gnu(worker+0x67)[0x808a6b3]
../../projects/einstein.phys.uwm.edu/albert_4.55_i686-pc-linux-gnu.so(_Z6foobarPv+0x22)[0x401ca6ea]
/lib/libpthread.so.0[0x400501b0]
/lib/libc.so.6(__clone+0x3a)[0x4012ae4a]
hawkeye@marge:~/BOINC/projects/einstein.phys.uwm.edu> uname -a
Linux marge 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown
Well I'm back in XP for the moment, to crunch those WUs in BOINC there. I am impressed with the speedup in Linux but have to say that there is still work to be done. I run a dual-boot here, so can make direct comparisons.
XP with AVG antivirus and Zone-alarm running still out-crunches my Gentoo Linux side by almost a third.
Average figures in XP are around 2 hours and 2 - 5 minutes for the big WU.
Average figures for a heavily tweaked Gentoo Linux kernel and Fluxbox (a VERY light window manager) and using Einstein 4.55 are around 3 hours and 33 - 35 minutes for same WUs (yes I have sse2 and dma turned on along with other speedups in Gentoo).
Please note I am grateful for any speedup from Linux Einestein - but if I was after pure credits I'd stick with Windows XP client.
Gray
PS - graphics worked fine both in Linux and in Windows XP - nvidia 5500FX card
hawkeye@marge:~/BOINC/projects/einstein.phys.uwm.edu> uname -a
Linux marge 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown
This is SUSE 8.1 (out of the box) on PIV 1700.
Michael
Why don't you update your SuSE? You can download a 10.0 from SuSE.com. I am running albert 4.51 on an old Pentium II, SuSE 9.3, with a 45% speed increase on albert 4.40 and no problems. CPU type is 0.
Tullio http://en.opensuse.org/Download
On a very up-to-date install of SuSE 10.0 I had the following on the stderr_txt info for a result:
2006-04-11 00:49:56.8056 [CRITICAL]: APP DEBUG: Application caught signal 11.
2006-04-11 00:49:56.8057 [CRITICAL]: Stack trace of LAL functions in worker thread:
2006-04-11 00:49:56.8058 [CRITICAL]: getCheckpointCounters at line 3878 of file /home/bema/einsteinathome/CFS/EaH_build_release_albert_4.55/extra_sources/lalapps-CVS/src/pulsar/FDS_isolated/ComputeFStatistic.c
2006-04-11 00:49:56.8058 [CRITICAL]: At lowest level status code = 0, description: NO LAL ERROR REGISTERED
Caught SIGABRT in graphics thread
Due to the time of it's occurrance I suspect it was the result of hitting the "show graphics" button while testing the latest boinc alpha build. Of four tasks completed with v4.55 this is the only one for which I used the "show graphics" option and the only one reporting this error.
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
Douglas Adams (1952 - 2001)
I downloaded and compiled the truxoft client (tx36) from source, and found a couple of problems. I worked around all of them, but I wanted to make you aware of the problems.
I failed to find a usable mail address on your site - here my comments :
------------------------------------------------------
0.
I'm running a Debian GNU/Linux platform.
1.
The zip file expands to a boinc-5.3.12.tx35.src directory. Confusing, but harmless.
2.
The file truxoft_prefs.xml is missing from the source and the linux archives.
3.
After I got the boinc_core_release_5_3_12 form CVS and copied the tx36 files in the client/ and lib/ directories, I ran thru the compilation procedures for the boinc client.
I found two problems :
3.1
client/client_types.C failed to compiled because the function stricmp(*, *) is not defined.
I copied the function (very dumb, I know) from zip/zip/macos/source/helpers.c, into the client_types.C file, and that problem disappeared.
3.2
In client/cs_apps.C, CHAR was not defined and I changed the code to read:
.....
bool CLIENT_STATE::schedule_priority_projects() {
PROJECT *best_project = NULL; char *best_priority = NULL, *current_priority;
....
This solved the problem.
After these changes, I ran thru the configuration / compilation routine for the boinc client again, and found no more (compilation/linkage) errors. I assume the code will run fine, and I have started to use it on one of my systems.
------------------------------------------------------
Thanks for your very valuable efforts - I'll keep you informed if anyting bad happens in the next days.
fwiw: 4.55 is about 50% slower than 4.51 on both intel p4 & xeon, along with k6 and k8, including 1 dual-dual opteron 280. All fedora linux, > 2.6.15-xxx kernels IA32 mode (no 64 bit)
So far one of my farm has problems with both 4.51 and 4.55 catching signal 11. Its a P4 2Ghz running Damn Small Linux 2.0 (Dell Optiplex SX260) - following the instructions for running without graphics seems to have fixed the problem. As this is a headless system losing the graphics was no biggie.
So far, all my results computed with albert_455 excepted 24588564 were successfully validated.
The message that failed reports a problem with graphics (I tried to startup the graphics, but my boincmgr doesn't correctly support graphics).
Hi,
This is no client error (outcome=success), just the validator threw your result away, because he thought it wasn't exact enough.
I got such a "0" result too today and I think the app must be modified again.
cu,
Michael
:::NB:::
My machines running on 4.55 ALL return "0" because the application is not precise enough. I do get "no client error; outcome success" but results get binned cos the validator takes them to be crapped up.
"Jamessir Bensonmam - Strange was the name of his father"
:
your thoughts - the ways :: the knowledge - your space
:
This is no client error (outcome=success), just the validator threw your result away, because he thought it wasn't exact enough.
I got such a "0" result too today and I think the app must be modified again.
I think the reason if this problem the low-precision sin/cos lookup table.
I will suggest to Brend the usage of my interpolation algorithm.
It gives about ~2300000 times more accurate sin/cos values an the speed is about the same.
akosf, you ARE the man! So cool to have you sticking around. Thanks a million for all your hard work and contributions. You make this project rock!
:
your thoughts - the ways :: the knowledge - your space
:
I get: 5.2.8 process
)
I get:
5.2.8
process exited with code 22 (0x16)
2006-04-11 19:44:08.2175 [normal]: Start of BOINC application 'albert_4.55_i686-pc-linux-gnu'.
2006-04-11 19:44:08.2617 [normal]: Started search at lalDebugLevel = 0
2006-04-11 19:44:10.1300 [normal]: Checkpoint-file 'Fstat.out.ckp' not found.
2006-04-11 19:44:10.1302 [normal]: No usable checkpoint found, starting from beginning.
Detected CPU type 1
2006-04-11 19:44:10.1325 [CRITICAL]: APP DEBUG: Application caught signal 11.
2006-04-11 19:44:10.1325 [CRITICAL]: Stack trace of LAL functions in worker thread:
2006-04-11 19:44:10.1325 [CRITICAL]: TestLALDemod at line 44 of file /home/bema/einsteinathome/CFS/EaH_build_release_albert_4.55/extra_sources/lalapps-CVS/src/pulsar/FDS_isolated/CFSLALDemod_ndp_vect.c
2006-04-11 19:44:10.1326 [CRITICAL]: At lowest level status code = 0, description: NO LAL ERROR REGISTERED
2006-04-11 19:44:10.1326 [CRITICAL]: Obtained 8 stack frames for this thread.
2006-04-11 19:44:10.1326 [CRITICAL]: Use gdb command: 'info line *0xADDRESS' to print corresponding line numbers.
albert_4.55_i686-pc-linux-gnu(sighandler+0x95)[0x808abcd]
/lib/libpthread.so.0[0x4005312b]
/lib/libc.so.6[0x40088d68]
albert_4.55_i686-pc-linux-gnu(boincmain+0xc8c)[0x807f8cc]
albert_4.55_i686-pc-linux-gnu(worker+0x67)[0x808a6b3]
../../projects/einstein.phys.uwm.edu/albert_4.55_i686-pc-linux-gnu.so(_Z6foobarPv+0x22)[0x401ca6ea]
/lib/libpthread.so.0[0x400501b0]
/lib/libc.so.6(__clone+0x3a)[0x4012ae4a]
hawkeye@marge:~/BOINC/projects/einstein.phys.uwm.edu> uname -a
Linux marge 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown
This is SUSE 8.1 (out of the box) on PIV 1700.
Michael
Team Linux Users Everywhere
Hiya All Well I'm back in
)
Hiya All
Well I'm back in XP for the moment, to crunch those WUs in BOINC there. I am impressed with the speedup in Linux but have to say that there is still work to be done. I run a dual-boot here, so can make direct comparisons.
XP with AVG antivirus and Zone-alarm running still out-crunches my Gentoo Linux side by almost a third.
Average figures in XP are around 2 hours and 2 - 5 minutes for the big WU.
Average figures for a heavily tweaked Gentoo Linux kernel and Fluxbox (a VERY light window manager) and using Einstein 4.55 are around 3 hours and 33 - 35 minutes for same WUs (yes I have sse2 and dma turned on along with other speedups in Gentoo).
Please note I am grateful for any speedup from Linux Einestein - but if I was after pure credits I'd stick with Windows XP client.
Gray
PS - graphics worked fine both in Linux and in Windows XP - nvidia 5500FX card
RE: hawkeye@marge:~/BOINC/p
)
Why don't you update your SuSE? You can download a 10.0 from SuSE.com. I am running albert 4.51 on an old Pentium II, SuSE 9.3, with a 45% speed increase on albert 4.40 and no problems. CPU type is 0.
Tullio
http://en.opensuse.org/Download
On a very up-to-date install
)
On a very up-to-date install of SuSE 10.0 I had the following on the stderr_txt info for a result:
2006-04-11 00:49:56.8056 [CRITICAL]: APP DEBUG: Application caught signal 11.
2006-04-11 00:49:56.8057 [CRITICAL]: Stack trace of LAL functions in worker thread:
2006-04-11 00:49:56.8058 [CRITICAL]: getCheckpointCounters at line 3878 of file /home/bema/einsteinathome/CFS/EaH_build_release_albert_4.55/extra_sources/lalapps-CVS/src/pulsar/FDS_isolated/ComputeFStatistic.c
2006-04-11 00:49:56.8058 [CRITICAL]: At lowest level status code = 0, description: NO LAL ERROR REGISTERED
Caught SIGABRT in graphics thread
Due to the time of it's occurrance I suspect it was the result of hitting the "show graphics" button while testing the latest boinc alpha build. Of four tasks completed with v4.55 this is the only one for which I used the "show graphics" option and the only one reporting this error.
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
Douglas Adams (1952 - 2001)
To TruX @ TruXoft : I
)
To TruX @ TruXoft :
I downloaded and compiled the truxoft client (tx36) from source, and found a couple of problems. I worked around all of them, but I wanted to make you aware of the problems.
I failed to find a usable mail address on your site - here my comments :
------------------------------------------------------
0.
I'm running a Debian GNU/Linux platform.
1.
The zip file expands to a boinc-5.3.12.tx35.src directory. Confusing, but harmless.
2.
The file truxoft_prefs.xml is missing from the source and the linux archives.
3.
After I got the boinc_core_release_5_3_12 form CVS and copied the tx36 files in the client/ and lib/ directories, I ran thru the compilation procedures for the boinc client.
I found two problems :
3.1
client/client_types.C failed to compiled because the function stricmp(*, *) is not defined.
I copied the function (very dumb, I know) from zip/zip/macos/source/helpers.c, into the client_types.C file, and that problem disappeared.
3.2
In client/cs_apps.C, CHAR was not defined and I changed the code to read:
.....
bool CLIENT_STATE::schedule_priority_projects() {
PROJECT *best_project = NULL;
char *best_priority = NULL, *current_priority;
....
This solved the problem.
After these changes, I ran thru the configuration / compilation routine for the boinc client again, and found no more (compilation/linkage) errors. I assume the code will run fine, and I have started to use it on one of my systems.
------------------------------------------------------
Thanks for your very valuable efforts - I'll keep you informed if anyting bad happens in the next days.
Regards.
-rg-
I have also a little
)
I have also a little problem:
2006. ápr. 11., kedd, 20.37.13 CEST||Suspending computation and network activity - running CPU benchmarks
2006. ápr. 11., kedd, 20.37.13 CEST|Einstein@Home|Pausing result z1_0981.5__139_S4R2a_1 (removed from memory)
2006. ápr. 11., kedd, 20.37.14 CEST||Running CPU benchmarks
2006. ápr. 11., kedd, 20.37.23 CEST||Failed to stop applications; aborting CPU benchmarks
2006. ápr. 11., kedd, 20.37.24 CEST||Resuming computation and network activity
2006. ápr. 11., kedd, 20.37.24 CEST||request_reschedule_cpus: Resuming activities
2006. ápr. 11., kedd, 20.37.24 CEST||request_reschedule_cpus: process exited
2006. ápr. 11., kedd, 20.37.24 CEST|Einstein@Home|Restarting result z1_0981.5__139_S4R2a_1 using albert version 455
2006. ápr. 11., kedd, 20.37.25 CEST||ACTIVE_TASK_SET::check_app_exited(): pid 10016 not found
2006. ápr. 12., szerda, 05.58.41 CEST||request_reschedule_cpus: process exited
2006. ápr. 12., szerda, 05.58.41 CEST|Einstein@Home|Computation for result z1_0981.5__139_S4R2a_1 finished
Boinc couldn't stop teh client to do the benchmark. This machine:
http://einsteinathome.org/host/505092
fwiw: 4.55 is about 50%
)
fwiw: 4.55 is about 50% slower than 4.51 on both intel p4 & xeon, along with k6 and k8, including 1 dual-dual opteron 280. All fedora linux, > 2.6.15-xxx kernels IA32 mode (no 64 bit)
:Xcamel:
So far one of my farm has
)
So far one of my farm has problems with both 4.51 and 4.55 catching signal 11. Its a P4 2Ghz running Damn Small Linux 2.0 (Dell Optiplex SX260) - following the instructions for running without graphics seems to have fixed the problem. As this is a headless system losing the graphics was no biggie.
RE: RE: Hi ! So far, all
)
:::NB:::
My machines running on 4.55 ALL return "0" because the application is not precise enough. I do get "no client error; outcome success" but results get binned cos the validator takes them to be crapped up.
"Jamessir Bensonmam - Strange was the name of his father"
:
your thoughts - the ways :: the knowledge - your space
:
RE: RE: This is no client
)
akosf, you ARE the man! So cool to have you sticking around. Thanks a million for all your hard work and contributions. You make this project rock!
:
your thoughts - the ways :: the knowledge - your space
: