Wow, that new client rev is making a nice little dent in my crunching rate, reducing it by about 55% on the xeon boxes...
I do note one system (a P4 3000) crashed hard imediately on being remotely restarted, some time after updating to the new code, I have yet to look at the box and see the actual cause. At this time, I am reporting it strictly as potential anecdotal evidence. None of the other 30 or so indentically configured systems to it had any problem, nor did the other 60 in the cluster. It may have simply been hardware failure. I'll get the box looked at, rebooted, and if it proves to be a software issue, I'll post an update. It may prove to be kernel too, as it was kinda old (2.4.27).
Here are some times for my dual boot system comparing Win to Linux.
...
Windows - 42,066 & 42,264 giving an average of 11:41:06 per result
Linux - 49,833 & 50,580 giving an average of 13:56:47 per result
...
So, in my particular case, comparing test version to test version, the linux client is now taking 20% longer than the windows client. MUCH better than it used to be, but still a very noticable difference.
The speed increase from the previous version of the linux application is certainly welcome but it's dissapointing to see that it's still significantly slower than the Windows application on the same hardware. :(
BOINC 4.43 with option -return_results_immediately
attached projects:
CPDN
orbit (not startet)
LHC (out of work)
Einstein
resource share 100 and 180 minutes runtime for each project
I attached to Einstein, it downloads two WU's, crunched them, upload them, but doesn't download new a WU, so only CPDN continue running.
Then i started the boincmgr and reseted Einstein, it was downloaded again with two WU's and started crunching.
After 2 hours, the CPU usage drops down to 0%, but the Einstein application was still loaded and had the status "running".
So i quit boinc and restart it, Einstein starts again and begins crunching, but now it starts always with priority 0 instead of 19.
Boinc taking most of cpu cycles, E@H is taking less. Normally E@H takes most cycles, when running, and boinc almost none.
Boinc 4.43, E@H 4.81, S@H 4.02 on a Mandriva 2005LE system, all patches and updates applied. Time share 50/50 between E@H and S@H.
Getting odd top, ps aux, and kpm (KDE process manager) results for boinc and E@H on two systems, one AMD the other a PIII. Have seen the following twice on the AMD system and once on the PIII over the last several days. S@H has been down during this period, boinc keeps trying to access but defers communication so E@H is getting all the processing time ;-)
Odd Behavior
TOP
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5209 me 25 0 6656 1964 1176 R 79.0 1.6 399:53.45 boinc
5215 me 34 19 18132 4268 1288 S 4.0 3.4 759:03.52 einstein_4.81_i
PS AUX
me 5209 36.3 1.5 8576 1908 ? R Aug28 513:12 ./boinc
me 5215 54.2 2.2 18132 2776 ? SNl Aug28 764:47 einstein_4.81_i
Normal Behavior (after killing and restarting boinc)
TOP
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27459 me 34 19 18132 5356 1608 S 98.2 4.3 1:14.39 einstein_4.81_i
(./boinc doesn't show in this view, CPU is normally near 0.0)
PS AUX
me 27458 0.0 1.2 2724 1572 ? S 10:07 0:00 ./boinc
me 27459 90.0 4.2 18132 5356 ? SNl 10:07 7:09 einstein_4.81_i
KPM shows similar but have saved in image format so won't attach. Any idea whats going on?
Now I'm running BOINC 4.72 and it doesn't happened again.
Howdy Desti
Does sound similar, also had the 8wu downloads that didn't show up on the AMD machine. Will try 4.72 after S@H comes back up. Didn't see problem before the extended S@H outage during last week.
I put up a new App (0.15), available from our usual Beta Test Page.
It allows to manually override the CPU detection and force it to use generic code (problems have been reported witch certain PIII Coppermine CPUs).
It also features later BOINC code, incorporating the fix to the signal handling (suspend/resume etc) we devleoped for MacOS, so it might hep with problems in that area, too.
RE: How do we switch back?
)
Yep. Actually it should be enough to delete the app_info.xml file. Make sure you stop the client before doing this.
BM
BM
RE: RE: How do we switch
)
works great for me! thx
Wow, that new client rev is
)
Wow, that new client rev is making a nice little dent in my crunching rate, reducing it by about 55% on the xeon boxes...
I do note one system (a P4 3000) crashed hard imediately on being remotely restarted, some time after updating to the new code, I have yet to look at the box and see the actual cause. At this time, I am reporting it strictly as potential anecdotal evidence. None of the other 30 or so indentically configured systems to it had any problem, nor did the other 60 in the cluster. It may have simply been hardware failure. I'll get the box looked at, rebooted, and if it proves to be a software issue, I'll post an update. It may prove to be kernel too, as it was kinda old (2.4.27).
Eric
RE: Here are some times for
)
The speed increase from the previous version of the linux application is certainly welcome but it's dissapointing to see that it's still significantly slower than the Windows application on the same hardware. :(
I have some strange problems
)
I have some strange problems on one of my PCs with Einstein 4.81
System: http://einsteinathome.org/host/392766
BOINC 4.43 with option -return_results_immediately
attached projects:
CPDN
orbit (not startet)
LHC (out of work)
Einstein
resource share 100 and 180 minutes runtime for each project
I attached to Einstein, it downloads two WU's, crunched them, upload them, but doesn't download new a WU, so only CPDN continue running.
Then i started the boincmgr and reseted Einstein, it was downloaded again with two WU's and started crunching.
After 2 hours, the CPU usage drops down to 0%, but the Einstein application was still loaded and had the status "running".
So i quit boinc and restart it, Einstein starts again and begins crunching, but now it starts always with priority 0 instead of 19.
Boinc taking most of cpu
)
Boinc taking most of cpu cycles, E@H is taking less. Normally E@H takes most cycles, when running, and boinc almost none.
Boinc 4.43, E@H 4.81, S@H 4.02 on a Mandriva 2005LE system, all patches and updates applied. Time share 50/50 between E@H and S@H.
Getting odd top, ps aux, and kpm (KDE process manager) results for boinc and E@H on two systems, one AMD the other a PIII. Have seen the following twice on the AMD system and once on the PIII over the last several days. S@H has been down during this period, boinc keeps trying to access but defers communication so E@H is getting all the processing time ;-)
Odd Behavior
TOP
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5209 me 25 0 6656 1964 1176 R 79.0 1.6 399:53.45 boinc
5215 me 34 19 18132 4268 1288 S 4.0 3.4 759:03.52 einstein_4.81_i
PS AUX
me 5209 36.3 1.5 8576 1908 ? R Aug28 513:12 ./boinc
me 5215 54.2 2.2 18132 2776 ? SNl Aug28 764:47 einstein_4.81_i
Normal Behavior (after killing and restarting boinc)
TOP
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27459 me 34 19 18132 5356 1608 S 98.2 4.3 1:14.39 einstein_4.81_i
(./boinc doesn't show in this view, CPU is normally near 0.0)
PS AUX
me 27458 0.0 1.2 2724 1572 ? S 10:07 0:00 ./boinc
me 27459 90.0 4.2 18132 5356 ? SNl 10:07 7:09 einstein_4.81_i
KPM shows similar but have saved in image format so won't attach. Any idea whats going on?
Sounds like the same as here:
)
Sounds like the same as here: http://einsteinathome.org/node/189758.
Now I'm running BOINC 4.72 and it doesn't happened again.
RE: Sounds like the same as
)
Howdy Desti
Does sound similar, also had the 8wu downloads that didn't show up on the AMD machine. Will try 4.72 after S@H comes back up. Didn't see problem before the extended S@H outage during last week.
I put up a new App (0.15),
)
I put up a new App (0.15), available from our usual Beta Test Page.
It allows to manually override the CPU detection and force it to use generic code (problems have been reported witch certain PIII Coppermine CPUs).
It also features later BOINC code, incorporating the fix to the signal handling (suspend/resume etc) we devleoped for MacOS, so it might hep with problems in that area, too.
Happy testing!
BM
BM
OK, may I ask, how to set the
)
OK, may I ask, how to set the CPU manually?
I tried this on p3 machine, but it's slower than 4.81...
(I don't use GUI, so...)