I don't have problems so far after several finished WUs(XP 2600, XP 3000, A64 X2). Even a voltage drop yesterday, which made most hosts reboot, couldn't provocate an error.
But maybe this is really a new serious problem, so it might be better to wait with the distribution of the beta app.
Well, none of us got errors... as I said, the WU didn't crash no matter how hard I tried ;-) and validated okay. But of course this kind of extreme slowdown is a problem in itself. I was willing to see my problems as random error but now I'm not so sure... can't speak for the project devs, of course, but if Bikeman's result really turns out as bad as mine I would say it is starting to look significant... Well, off for some 5 hours of sleep ;-) I'll think about beta testing again afterwards. Good luck with your respective WUs :-)
Annika,
what I read from the stderr of the "slow" result is that it ran almost twice as fast after the reboot than before (given that you didn't change the checkpoint setting). Was that the result where the graphics window opened just the first time?
Bikeman,
did you open the graphics once with that result and maybe also experienced the window only opening the first time?
It might be that after bad initialisation the graphics thread eats up significant CPU time. In this case a restart of the App, issued by stopping or starting the client or suspending and resuming the Task with having "remove App from memory when suspended" set (and not opening the graphics afterwards) should fix it.
Bikeman, if that doesn't help, you might try a reboot?
Bikeman,
did you open the graphics once with that result and maybe also experienced the window only opening the first time?
I did open the gfx window but could close and re-open as often as I liked. Needless to say I kept gfx closed (host is managed remotely via VNC and runs w/o boinc_mgr most of the time anyway).
Quote:
It might be that after bad initialisation the graphics thread eats up significant CPU time. In this case a restart of the App, issued by stopping or starting the client or suspending and resuming the Task with having "remove App from memory when suspended" set (and not opening the graphics afterwards) should fix it.
Bikeman, if that doesn't help, you might try a reboot?
BM
Note there was some gfx-related warning message in my first WU's debug output, see top of thread.
The WU is now at approx 62% and I'll do the kill-restart-don't-touch-gfx thing. Let's see if this helps.
I won't be able to report the result before this evening tho, when I return from work, my DSL modem-router is misbehaving after a firmware update and keeps disconnecting :-(.
Yes Bernd, I also noticed it seemed to be quicker after the reboot; and yes, that was the result with the "graphics display only first time" problem. But I checked "top" a couple of times and I'm quite sure more than 98% of CPU time went to Einstein... okay, maybe that includes the graphics, too? Not sure how that would display.
Judging from tail -f stderr.txt, I'd say that the WU is now processing at one skypos every 2 - 2.5 seconds, which would be almost exactly twice as fast as before :-).
Amazing!
Bernd, I think you were hitting the nail on it's head!. As I said, final results should be in (very late) this evening.
Sounds as if that really was the problem :-) "twice as fast" sounds exactly like what happened on my WU. Would it be possible to disable graphics entirely for the time being so the users who don't read the message board won't try to run them?
Well, the Einstein@Home team has worked hard to make the BOINC graphics work under MacOS & Linux (it did work on Windows only when we started working with BOINC).
However it looks like the graphics mechanism with all the shared library linking etc. is causing more trouble than benefit (part of the SIABRT issue is one of them), so I'm thinking about switching to non-graphical Apps for the official Linux ones alltogether, and publish a graphical App for manual installation and probably with a rather limited range of systems it runs on for the people who really want to see it on Linux.
I don't have problems so far
)
I don't have problems so far after several finished WUs(XP 2600, XP 3000, A64 X2). Even a voltage drop yesterday, which made most hosts reboot, couldn't provocate an error.
But maybe this is really a new serious problem, so it might be better to wait with the distribution of the beta app.
cu,
Michael
RE: Either the wingman was
)
Their BOINC CC is 5.8.16, so the claim should be valid...
Well, none of us got
)
Well, none of us got errors... as I said, the WU didn't crash no matter how hard I tried ;-) and validated okay. But of course this kind of extreme slowdown is a problem in itself. I was willing to see my problems as random error but now I'm not so sure... can't speak for the project devs, of course, but if Bikeman's result really turns out as bad as mine I would say it is starting to look significant... Well, off for some 5 hours of sleep ;-) I'll think about beta testing again afterwards. Good luck with your respective WUs :-)
Annika, what I read from the
)
Annika,
what I read from the stderr of the "slow" result is that it ran almost twice as fast after the reboot than before (given that you didn't change the checkpoint setting). Was that the result where the graphics window opened just the first time?
Bikeman,
did you open the graphics once with that result and maybe also experienced the window only opening the first time?
It might be that after bad initialisation the graphics thread eats up significant CPU time. In this case a restart of the App, issued by stopping or starting the client or suspending and resuming the Task with having "remove App from memory when suspended" set (and not opening the graphics afterwards) should fix it.
Bikeman, if that doesn't help, you might try a reboot?
BM
BM
RE: Bikeman, did you open
)
I did open the gfx window but could close and re-open as often as I liked. Needless to say I kept gfx closed (host is managed remotely via VNC and runs w/o boinc_mgr most of the time anyway).
Note there was some gfx-related warning message in my first WU's debug output, see top of thread.
The WU is now at approx 62% and I'll do the kill-restart-don't-touch-gfx thing. Let's see if this helps.
I won't be able to report the result before this evening tho, when I return from work, my DSL modem-router is misbehaving after a firmware update and keeps disconnecting :-(.
CU
BRM
Yes Bernd, I also noticed it
)
Yes Bernd, I also noticed it seemed to be quicker after the reboot; and yes, that was the result with the "graphics display only first time" problem. But I checked "top" a couple of times and I'm quite sure more than 98% of CPU time went to Einstein... okay, maybe that includes the graphics, too? Not sure how that would display.
P.S.: Judging from tail -f
)
P.S.:
Judging from tail -f stderr.txt, I'd say that the WU is now processing at one skypos every 2 - 2.5 seconds, which would be almost exactly twice as fast as before :-).
Amazing!
Bernd, I think you were hitting the nail on it's head!. As I said, final results should be in (very late) this evening.
Cheers!
BRM
Sounds as if that really was
)
Sounds as if that really was the problem :-) "twice as fast" sounds exactly like what happened on my WU. Would it be possible to disable graphics entirely for the time being so the users who don't read the message board won't try to run them?
Well, the Einstein@Home team
)
Well, the Einstein@Home team has worked hard to make the BOINC graphics work under MacOS & Linux (it did work on Windows only when we started working with BOINC).
However it looks like the graphics mechanism with all the shared library linking etc. is causing more trouble than benefit (part of the SIABRT issue is one of them), so I'm thinking about switching to non-graphical Apps for the official Linux ones alltogether, and publish a graphical App for manual installation and probably with a rather limited range of systems it runs on for the people who really want to see it on Linux.
BM
BM
Sounds like a good idea to me
)
Sounds like a good idea to me :)