Linux S5R2 App 4.21 available for Beta test
7 May 2007 9:23:25 UTC
Topic 13550
(moderation:
A Linux App (4.21) is available from our Beta Test page. It fixes one possible source of the "SIGABRT" problem. As this is actually a combination of problems, I'm not sure this fix covers all of them. Please test and report in this thread.
BM
BM
Linux S5R2 App 4.21 available for Beta test
)
The only difference relevant for the issue this App adresses is the Linux version (i.e. glibc), and possibly the graphics, not the hardware. A bleeding edge Linux distribution (e.g. from the Gentoo or Debian lines) and switching on graphics (*) should be the hardest test.
BM
(*) Actually running the graphics isn't necessary for testing, just the necessary libraries have to be installed to enable the graphics thread, which can be tested by switching on the graphics for a moment.
BM
RE: I had the graphics on
)
Thanks for spotting this. "Graphics only shows up first time" is an issue I have seen quite a while ago (rather years than months), it has to do with initialisation of the graphics libraries. Something changed in BOINC there since our S5R1 Apps, I'll look into it.
I think that most Linux instances are running rather unattended and not normally showing the graphics anyway, in particular as there isn't a BOINC screensaver for X11/Linux yet, so I'll not give this issue the highest priority right now. Is there any Linux user out there who normally enjoys the graphics?
BM
BM
Thanks. It looked only
)
Thanks. It looked only slightly slower on the machines I tested it so far. I had to use a slightly older version of gcc for this build (gcc-4.1.0 instead of gcc-4.1.2). If this App really fixes tes SIGABRT problem, this would be worth it, and it'll give me time to look into speeding up the code for the benefit of all platforms, beyond the 4.18 App.
BM
BM
I have looked into the times
)
I have looked into the times for two types of machines yet (AMD Opteron like #913062 (Debian Etch) and Core2Duo like #847720 (Fedora Core 5)) and can't see a difference in execution times between 4.18 and 4.21 for Tasks that claim the same credit, the same with ziegenmelkers host #922868.
BM
BM
RE: What distro are your
)
I was just editing it...
More likely than the Distro, but I'm still not sure. I'll try to build it with the same compiler, which is the only difference I can think of that could have a large impact on the runtime. Might take a bit, though.
BM
BM
Looks like the Beta App isn't
)
Looks like the Beta App isn't doing (much) worse than the 4.18 and it fixes the major source of the SIGABRT problem, which is the problem that wastes by far the most of computing time (and credit). I guess we'll make it official in the next hours (or latest tomorrow).
Annika, I don't have any clue yet what happens on your machine, but as I haven't seen a noticable slowdown on any other machine I got results from, I think that it's an issue limited to your machine. I'll start working on speeding up the App soon anyway.
When the 4.21 is official, I might post another version of the same code compiled with the compiler version I used previously - if I find the time to buid one before I have a code that is faster anyway.
BM
BM
RE: if a new version is
)
As long as the app_info.xml is present, your Client won't download a new App automatically, it will continue to use the 4.21.
To get back to the automatic update path you need to stop the client, remove the app_info.xml file and start the client again. If you do this while the official App has the same version number as the one you were using, the client should find the App already present on your system and don't download it, and the App will just continue from the checkpoint.
There are, however, some BOINC clients that have problems with this transition, because actually the platform changes (from anonymous to linux-x86). The safest way would be to set the project to "no new work", let the client finish all tasks it got, then stop the client, remove the app_info.xml, start the client again and set the project to "allow more work".
BM
BM
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
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
4.21 has (finally...) been
)
4.21 has (finally...) been made "official", thanks for help with testing it.
The slowdown from the graphics thread isn't nice, and I'll keep looking into the issue. But slowing down the calculation is much, much better than crashing, and in this sense this App is a lot better than the previous 4.18. Also too I'm more worried about the thousands of Linux installations that run unattended than about some people that play with the graphics, even more as the graphics slowdown problem seems to be limited to certain configurations (probably graphics library versions) - I've not noticed it on "my" machines, and Ziegenmelker apparently didn't on his, too (right?).
It looks like I need to convince some other E@H folks of my "optional graphics App" idea first, so a default non-graphical App might take a bit.
BM
BM