Message boards :
Number crunching :
Best app for a Xeon X5650 cpu in Linux
Message board moderation
Previous · 1 · 2
Author | Message |
---|---|
Keith Myers Send message Joined: 29 Apr 01 Posts: 13164 Credit: 1,160,866,277 RAC: 1,873 |
Probably a question for one of the old-timers like Richard Haselgrove or Rob Smith. They understand and know all the underpinnings of BOINC. Interesting. So how far back in revisions does that MB app go. No version level listed in the stderr.txt output. It does have a strange name and I noticed that. Didn't make the connection that it isn't a current MB app. It has to be one that is formatted to understand MB8 though of course. How did it end up in the repository? I only thought that BOINC versions are in the repository. Seti@Home classic workunits:20,676 CPU time:74,226 hours A proud member of the OFA (Old Farts Association) |
Jim-R. Send message Joined: 7 Feb 06 Posts: 1494 Credit: 194,148 RAC: 0 |
I happened to recall installing that app from the repository so I went and looked it up. It's name in the repository is 'boinc-app-seti-graphics' and version 8.00~svn3701-1. And thanks for the tip on the process app. I've used 'task manager' to try to track it down but the only thing I've been able to find out with that is that each wu I'm crunching takes a total of 4% of the cpu. I could not get it to glitch while monitoring with task manager in the foreground, but as soon as I pulled Firefox back up to type here it glitched again! This might seem to lead to Firefox itself, but I run the exact same version of Firefox with the exact same addons on every computer I have and this does not happen on the others. And it seems to happen any time I have a program open and actively waiting for keyboard input. (Just used Thunderbird to reply to an email and it froze.) I'm going to let things run as they are until tonight then shut it down and change over to the optimized app. then we can see if the stderr.txt returns to normal (it should) and I'll check while it's down to see if my freezes are due to BOINC itself. (As I mentioned, I have paused all SETI crunching and it didn't go away so it's not SETI itself.) Jim Some people plan their life out and look back at the wealth they've had. Others live life day by day and look back at the wealth of experiences and enjoyment they've had. |
Keith Myers Send message Joined: 29 Apr 01 Posts: 13164 Credit: 1,160,866,277 RAC: 1,873 |
Just Googled your app version. This is what it has to say. Note that this package has been primarily created for users of architectures for which SETI@home does not provide its application. If your architecture is x86 or AMD64 the BOINC client automatically downloads the latest SETI@home application if you participate in this project. There is no need to install this package then, except for it to take all technical hurdles from you to have your very custom SETI patch or new compiler flags evaluated. The configuration of BOINC to find the local SETI binary is all performed by the package. So it looks like it pulled the BOINC nightly tarball from the time the package was put into the repository. Also see it marked as unstable. Notice the last line where it says it will do the configuration with your custom SETI patch and new compiler flags. The custom compiler flags are probably what prints out the strange stderr.txt output. Seti@Home classic workunits:20,676 CPU time:74,226 hours A proud member of the OFA (Old Farts Association) |
Jim-R. Send message Joined: 7 Feb 06 Posts: 1494 Credit: 194,148 RAC: 0 |
Ok, that seems to clear that up. I just came in for dinner and have to go back out on another call in a few minutes but that app will be gone tonight when I change over to the SSE4.2 optimized app, so hopefully, after tonight there will be no more weird entries! hehe. Jim Some people plan their life out and look back at the wealth they've had. Others live life day by day and look back at the wealth of experiences and enjoyment they've had. |
Juha Send message Joined: 7 Mar 04 Posts: 388 Credit: 1,857,738 RAC: 0 |
The custom compiler flags are probably what prints out the strange stderr.txt output. Well, no. They take the revision this or that and apply some patches on top of it. One of the patches adds the messages. The compiler flags are for when there is a brand new compiler and you want to know if enabling SSE7 would make the app go any faster. |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.