Posts by Christian Seti (user)

1) Questions and Answers : Macintosh : Running at boot behind login screen, problems with launchd (Message 727815) Posted 19 Mar 2008 by Christian Seti (user) Post: SOLVED! I was trying to do my own finangling to get a launchd script up and running. It turns out that Charlie Fenton's own "Make_BOINC_Service.sh" script works well and fixes this problem. I note two differences from my own invocation: one is the use of the switch "-daemon" in the command line version of the BOINC core client, and the other is a difference in the way redirection to the BOINC Data directory is facilitated if (as in our case), the core client and the data directory are separate. Follow the instructions in the "Make_BOINC_Service.sh" file. If only I had done that first! I can confirm that BOINC DOES run as a daemon, behind the login screen, under OS 10.5.2
2) Questions and Answers : Macintosh : Running at boot behind login screen, problems with launchd (Message 727808) Posted 19 Mar 2008 by Christian Seti (user) Post: Problem: Attempting to launch BOINC as a daemon (service) under Leopard using launchd causes an odd hang in the BOINC process. The fine print: Those of us interested in running BOINC on large numbers of Mac computers which spend a deal of time parked at the login screen will be familiar with instructions floating around out there to run BOINC as a service. Unfortunately, these instructions were based on Tiger. Here's some advice (and a question) for those hoping to do the same in Leopard. The advice for Tiger involves downloading the command line only version of BOINC for Macs and then placing a startup script in the /Library/StartupItems folder. This script would contain a line similar to: nohup /Library/BOINC/boinc -insecure -allow_remote_gui_rpc -dir /Library/Application\\ Support/BOINC\\ Data/ >> /Library/BOINC/boinc_run.log & All well and good. This has worked well for us and our Tiger based Lab Macs. The BOINC process starts at boot, and runs behind the login screen. Additionally, you may care to create login and logout scripts for your users to either renice or suspend/resume BOINC so as to minimise any user disruption. Although launchd was introduced and functional in Tiger, the /Library/StartupItems path to launching BOINC (which isn't launchd based) worked. If you try the same thing in Leopard, it won't work. Any script in this directory is ignored. It seems that launchd is now the only option for launching BOINC as a service in Leopard. I downloaded Lingon (google it, easy to find), which is a free GUI interface for launchd for Macs. I created a new user daemon to launch BOINC at boot (stored in /Library/LaunchDaemons), which basically pointed launchd to the same script I was using to launch BOINC under Tiger. Unfortunately, this isn't working for Leopard based Macs, at least not for me. The launchd script indeed invokes the 'boinc' command line process, but instead of this then spawning an instance of the setiathome process and then settling down act as a low-cpu-using managing process for BOINC while the setiathome process does the heavy lifting, 'boinc' itself takes up nearly 100% CPU, no setiathome process is spawned, and no work is done. Oddly, if I log in as root, kill the hanging "boinc" process and then run exactly the same script from a command line, then BOINC fires up just fine and spawns the setiathome process and all is well. Something about launchd invoking boinc is breaking it. When a user is actually logged in and the process is run, it works. If anyone can offer some help, I'd appreciate it.
3) Message boards : Number crunching : Why can't I maintain a cache of x-days worth of WUs? (Message 624648) Posted 23 Aug 2007 by Christian Seti (user) Post: Please tell us your "connect every 'x' days" setting, and your "extra days" setting. I did, in my original question. "Connect every '0' days" (which the explanatory text on the website suggests is 'being connected to the internet all the time', which they are, and "maintain work for an extra '10' days". To the replier "Alinator"- thanks for taking the time to reply. Despite being a sysadmin and SETI@Homer since the very week it all started, I got a bit lost in your explanation. You use the following abbreviations and I do not know what they mean: CC LF MB AP If I'm hearing you correctly, factors beyond those relating to there being plenty of workunits to send are having an effect (and I'm only doing SAH, not any other BOINC project, FWIW). OK. Would there be any benefit from increasing the "connect to the Internet" delay from 0 to 10 days? Am I correct in assuming this would allow the computers to keep a buffer of (up to) 20 days instead of 10? Or am I reading this wrong? Thanks again.
4) Message boards : Number crunching : Why can't I maintain a cache of x-days worth of WUs? (Message 624573) Posted 23 Aug 2007 by Christian Seti (user) Post: I run a 4 day cache & have only run out of work about 3 times in the last 5 or 6 years. How is this possible when outages of far longer than this have occurred over that time? I can see how the fact that workunits get processed by 2 or 3 users might hang up the allocation of credit, but it doesn't explain why, even when there is plenty of work to go around, if I look at the tasks tab of any of my clients, there are usually only a handful of workunits "in the pipe"- the one or two that are being processed and between 0-4 "extras" waiting. This is despite the fact that the computer would finish those off within only a day or two. Thus my question stands. If (a) there is plenty of work waiting to be sent (and again, I know this isn't always the case, but I confine my observation to when I know there is) and (b) I've asked my computers to maintain a buffer of ten days, why is there rarely that much work buffered at my end?
5) Message boards : Number crunching : Why can't I maintain a cache of x-days worth of WUs? (Message 624232) Posted 22 Aug 2007 by Christian Seti (user) Post: There's something wrong with the way BOINC is failing to maintain a cache of workunits on my network. My setup: 250 computers running BOINC (all version 5.10.xx). Some Windows, some Macs. This alone suggests that the problem is not something specific to a particular version or particular platform. I have my General Settings in the BOINC webmin to indicate my computers are connected all the time ("connect to the Internet every 0 days" in the General prefs) and "maintain work for an additional 10 days" (the largest the system will permit). Despite this, over a time such as we have had recently where workunit production has dropped behind demand significantly for about a week, my BOINC user has shown a big dip in RAC. (as seen as) Why would this be the case when, if the settings were working properly, I should have a ten day buffer of work to tide me over until workunit production picks up? In theory, even a total workunit drought of ten days should result in no dropoff in credit so long as each computer's cache of work was full to start with. These outages are sometimes unavoidable, but I am concerned I am missing something when the provided mechanism fails to maintain enough work at my end when there isn't enough to go around.
6) Message boards : Technical News : Stats Status (Apr 16 2007) (Message 548516) Posted 18 Apr 2007 by Christian Seti (user) Post: I think I've just answered my own question. The stats appearing on some pages are combined Boinc stats and not just the ones only for SETI@Home.
7) Message boards : Technical News : Stats Status (Apr 16 2007) (Message 548515) Posted 18 Apr 2007 by Christian Seti (user) Post: Is there any explanation as to why, on stats sites like boincsynergy there are some users whose daily stats ARE appearing and tabulated and the rest (including me) have been zero for nearly a week? I would have thought that the unavailability of the stats would have been a universal phenomenon, so why are some appearing and some not?
8) Questions and Answers : Macintosh : Universal Binary Version of BOINC? (Message 249345) Posted 17 Feb 2006 by Christian Seti (user) Post: This is straight from the horses mouth. Charlie Fenton is the developer of the Intel version of BOINC for Macs. I posted some questions on the official BOINC mailing list and he's responded comprehensively. Many, many thanks to Charlie. My comments and Charlie's responses are below, mixed together. Sorry if the breaks between my questions and his responses are not obvious, this is a direct cut and paste from his email to me. At 4:09 PM +1100 2/15/06, Nathan Zamprogno wrote: 1. Who is responsible for developing the Intel Specific or Universal binary of BOINC? Is there a version roadmap or timeline for even a beta release? I am currently testing fully working "universal binary" development builds of BOINC Manager, command-line BOINC client and the boinc_cmd command-line tool. All future releases of BOINC will include "universal binary" builds for the Macintosh. (Universal binaries contain both PowerPC and Intel executables in one file; the Macintosh OS automatically selects the appropriate one for that computer.) The BOINC team is working hard to get all the BOINC code ready for the next alpha test release; the issues which need to be resolved before this release are not specific to the Mac platform. The next version of BOINC needs to pass alpha test before we can fully release it. We will soon be recruiting alpha testers for the Macintosh platforms, both PowerPC and Intel. As Eric Korpela correctly wrote, SETI@home currently has a MacOS X/Intel binary (see http://setiathome.berkeley.edu/apps.php), but you'd need an intel aware BOINC client to run it. So far as I know there is no intel BOINC binary available for download. My tests show that the current PowerPC builds of both BOINC and the project applications run perfectly on Intel Macs under Apple's Rosetta emulation, though more slowly. My tests indicate that the PowerPC build of SETI@home takes about 3 times as long to run on an Intel Mac as does the Intel native build of SETI@home. A PowerPC build of SETI@home takes about 7.5 hours per work unit on a 2GHz dual-core Intel iMac, as opposed to about 2.5 hours for a native Intel build. At 4:09 PM +1100 2/15/06, Nathan Zamprogno wrote: 2. Obviously BOINCManager is a fully fledged double-clickable application, and thus will either need to be native to Intel or will run under Rosetta. But what about the command line only version of BOINC? Does code that executes from a command line fall into the "must be rewritten for Intel" basket? Is "Universal Binary-ness" only a feature needed in full OS-X programs with menus and windows? Will the current CLI version run as a background process and will it use Rosetta or run "natively" on Intel hardware? Nothing needs to be rewritten, only recompiled. This applies to all executables, both GUI and command-line. But all BOINC executables written for PowerPC Macs run correctly on Intel Macs using Apple's Rosetta emulation. What about CLI versions meant for Linux on Intel systems (that is, Wintel hardware). Would that work or crash? I have not tried this, but I am fairly certain they will not run. OS X is a UNIX system, not Linux. They are similar but not interchangeable. 3. Regardless of how BOINC is running, as Intel native or under Rosetta emulation, what about the code received from BOINC projects themselves? When I start up SETI@Home on a new BOINC client I note it downloads "setiathome 4.18" as well as a few workunits. Does this file contain platform specific code or optimisations or is it "universal" (meaning the same project code file is downloaded irrespective of platform it is run on, kind of like Java?) Do BOINC project writers need to change anything at their end so their projects will run on the "new" platform? The advantage of "universal binaries" is that you only need to have one copy of the application, and it will run on either PowerPC or Intel Macs, so users don't need to choose between two options. Since BOINC participants manually download BOINC from the web site, we will be providing BOINC in "universal binary" form. However, participants do not manually download project applications; this is done automatically by BOINC. So there would be no advantage to combining the Intel and PowerPC versions in a single "universal binary" file, but doing so would double the size of the download. So BOINC treats Intel Macs as a new, separate platform. BOINC previously directly supported four platforms: PowerPC Macs (powerpc-apple-darwin), Intel Linux (i686-pc-linux-gnu), Windows (windows-intelx86) and Solaris (sparc-sun-solaris2.7). We have now added a fifth platform for Intel Macs (i686-apple-darwin). At this time, only SETI@home has a project application available for the i686-apple-darwin platform, but we are working with the other projects which support the Mac powerpc-apple-darwin platform to help them build a native Intel version. As a temporary measure, projects can provide a copy of their PowerPC application under the new powerpc-apple-darwin platform. But it will run more slowly than a native Intel build, and screensaver graphics don't work when running a PowerPC project application with a native Intel build of BOINC Manager / BOINC screensaver. The screensaver graphics _do_ work properly on Intel Macs when running a PowerPC project application with PowerPC BOINC, or when running an Intel project application with Intel (universal binary) BOINC. If the current version of BOINC runs in Rosetta, I'm expecting the performance to be cripplingly slow, although advice from someone who's tried will be welcome. It's actually better than I had expected.
9) Questions and Answers : Macintosh : BOINC running on an Intel Mac? (Message 249344) Posted 17 Feb 2006 by Christian Seti (user) Post: This is straight from the horses mouth. Charlie Fenton is the developer of the Intel version of BOINC for Macs. I posted some questions on the official BOINC mailing list and he's responded comprehensively. Many, many thanks to Charlie. My comments and Charlie's responses are below, mixed together. Sorry if the breaks between my questions and his responses are not obvious, this is a direct cut and paste from his email to me. At 4:09 PM +1100 2/15/06, Nathan Zamprogno wrote: 1. Who is responsible for developing the Intel Specific or Universal binary of BOINC? Is there a version roadmap or timeline for even a beta release? I am currently testing fully working "universal binary" development builds of BOINC Manager, command-line BOINC client and the boinc_cmd command-line tool. All future releases of BOINC will include "universal binary" builds for the Macintosh. (Universal binaries contain both PowerPC and Intel executables in one file; the Macintosh OS automatically selects the appropriate one for that computer.) The BOINC team is working hard to get all the BOINC code ready for the next alpha test release; the issues which need to be resolved before this release are not specific to the Mac platform. The next version of BOINC needs to pass alpha test before we can fully release it. We will soon be recruiting alpha testers for the Macintosh platforms, both PowerPC and Intel. As Eric Korpela correctly wrote, SETI@home currently has a MacOS X/Intel binary (see http://setiathome.berkeley.edu/apps.php), but you'd need an intel aware BOINC client to run it. So far as I know there is no intel BOINC binary available for download. My tests show that the current PowerPC builds of both BOINC and the project applications run perfectly on Intel Macs under Apple's Rosetta emulation, though more slowly. My tests indicate that the PowerPC build of SETI@home takes about 3 times as long to run on an Intel Mac as does the Intel native build of SETI@home. A PowerPC build of SETI@home takes about 7.5 hours per work unit on a 2GHz dual-core Intel iMac, as opposed to about 2.5 hours for a native Intel build. At 4:09 PM +1100 2/15/06, Nathan Zamprogno wrote: 2. Obviously BOINCManager is a fully fledged double-clickable application, and thus will either need to be native to Intel or will run under Rosetta. But what about the command line only version of BOINC? Does code that executes from a command line fall into the "must be rewritten for Intel" basket? Is "Universal Binary-ness" only a feature needed in full OS-X programs with menus and windows? Will the current CLI version run as a background process and will it use Rosetta or run "natively" on Intel hardware? Nothing needs to be rewritten, only recompiled. This applies to all executables, both GUI and command-line. But all BOINC executables written for PowerPC Macs run correctly on Intel Macs using Apple's Rosetta emulation. What about CLI versions meant for Linux on Intel systems (that is, Wintel hardware). Would that work or crash? I have not tried this, but I am fairly certain they will not run. OS X is a UNIX system, not Linux. They are similar but not interchangeable. 3. Regardless of how BOINC is running, as Intel native or under Rosetta emulation, what about the code received from BOINC projects themselves? When I start up SETI@Home on a new BOINC client I note it downloads "setiathome 4.18" as well as a few workunits. Does this file contain platform specific code or optimisations or is it "universal" (meaning the same project code file is downloaded irrespective of platform it is run on, kind of like Java?) Do BOINC project writers need to change anything at their end so their projects will run on the "new" platform? The advantage of "universal binaries" is that you only need to have one copy of the application, and it will run on either PowerPC or Intel Macs, so users don't need to choose between two options. Since BOINC participants manually download BOINC from the web site, we will be providing BOINC in "universal binary" form. However, participants do not manually download project applications; this is done automatically by BOINC. So there would be no advantage to combining the Intel and PowerPC versions in a single "universal binary" file, but doing so would double the size of the download. So BOINC treats Intel Macs as a new, separate platform. BOINC previously directly supported four platforms: PowerPC Macs (powerpc-apple-darwin), Intel Linux (i686-pc-linux-gnu), Windows (windows-intelx86) and Solaris (sparc-sun-solaris2.7). We have now added a fifth platform for Intel Macs (i686-apple-darwin). At this time, only SETI@home has a project application available for the i686-apple-darwin platform, but we are working with the other projects which support the Mac powerpc-apple-darwin platform to help them build a native Intel version. As a temporary measure, projects can provide a copy of their PowerPC application under the new powerpc-apple-darwin platform. But it will run more slowly than a native Intel build, and screensaver graphics don't work when running a PowerPC project application with a native Intel build of BOINC Manager / BOINC screensaver. The screensaver graphics _do_ work properly on Intel Macs when running a PowerPC project application with PowerPC BOINC, or when running an Intel project application with Intel (universal binary) BOINC. If the current version of BOINC runs in Rosetta, I'm expecting the performance to be cripplingly slow, although advice from someone who's tried will be welcome. It's actually better than I had expected.
10) Questions and Answers : Macintosh : BOINC running on an Intel Mac? (Message 247915) Posted 14 Feb 2006 by Christian Seti (user) Post: A comment elsewhere prompts a need for clarification. Obviously BOINCManager is a fully fledged application and thus will either need to be native to Intel or will run under Rosetta. But what about the command line only version? I've got BOINC set up to run as a background process via the command line version. I've got some nifty scripting set up to engage it in the background at bootup (meaning it will even run behind the login screen). I only use BOINCManager when I need to check on the progress. So is the CLI version in need of "Intel-ification"? Is "Universal Binary-ness" only a feature needed in full OS-X programs with menus and windows? Will the current CLI version run as a background process and will it use Rosetta or run "natively"?
11) Questions and Answers : Macintosh : Universal Binary Version of BOINC? (Message 247912) Posted 14 Feb 2006 by Christian Seti (user) Post: This is covered on another thread. HERE.
12) Questions and Answers : Macintosh : Intel Mac Screensaver (Message 247911) Posted 14 Feb 2006 by Christian Seti (user) Post: This is covered on another thread. HERE.
13) Questions and Answers : Macintosh : BOINC running on an Intel Mac? (Message 247909) Posted 14 Feb 2006 by Christian Seti (user) Post: The link to the beta downloads at the BOINC site is very welcome but where would we find documentation laying out the version roadmap? There's still no answer as to if BOINC will be Universal Binary, or a separate installer for each Mac processor type, if the current BOINC will run under Rosetta at all (and even if it did I expect the performance to be crippling). SUrely someone, somewhere has charge over saying "BOINC will be Intel native as of version xx, expect a beta by yy". Can anyone help?
14) Questions and Answers : Macintosh : BOINC running on an Intel Mac? (Message 237209) Posted 25 Jan 2006 by Christian Seti (user) Post: I'd like to know where this information came from because there's no mention of an Intel-compatible beta on the Mac section of the download site. I would happily test a beta of the Intel-Mac client (command line only preferred, I run it as a background process). Where can I get it? Who's responsible? What is the time frame for release? Thanks.
15) Message boards : Number crunching : BOINC stats pages- non update of data. Which end is the problem at? (Message 211159) Posted 12 Dec 2005 by Christian Seti (user) Post: BOINC/SETI stats sites like www.boincsynergy.com and www.boincstats.com have not had their stats updated for over a week now, and counting. I haven't been able to work out if this problem is caused by the hiatus at the Berkeley end or by something else. Can anyone shed some light?
16) Message boards : Number crunching : Will outage mean returned WU's are post-deadline? (Message 158994) Posted 29 Aug 2005 by Christian Seti (user) Post: Hey, When SETI@Home comes back up, will this mean that nearly ALL the workunits (or a very substantial proportion of them) be returned after their notional dealine and therefore be worthless?
17) Message boards : Number crunching : Validation backlog: So do late returns get no credit then? (Message 152927) Posted 18 Aug 2005 by Christian Seti (user) Post: Referring to the August 18 technical news bulletin: "Such results can appear when a workunit had reached it's quorum number of returned results and is passed through validation, assimilation, file (both workunit and result) deletion and finally DB purging and then one or more results come in (perhaps they were slowed down by running intermittently on a laptop). The disassociated results are the bulk of what needs deleting." So if the backlog of results awaiting validation are these "orphaned" results that are received after they have already reached quorum, does this mean that no credit is going to be issued for them? It's not very fair. Why should someone get credit because they returned a workunit inside the deadline and not if they are late? Sure, only three results are needed for a quorum, but discriminating in my mind violates the spirit of BOINC whereby credit is a reflection of CPU work DONE, not work USED TO ESTABLISH QUORUM. If you "order" something and then say you don't want it when it's delivered, you still have to pay for it!
18) Message boards : Number crunching : Validator queue keeps growing...... (Message 152415) Posted 17 Aug 2005 by Christian Seti (user) Post: I also have watched with interest as the validator queue has grown but it's not as bad as it looks. If you go to your account info and click "results" you'll see that results returned have "pending" credit back to about the 6th of August (as at this time- 17th August). Results for workunits prior to the 6th seem to all have credit granted. That's only 11 days lag between a workunit being sent to you (not sent, processed and returned) and credit being granted for it. Not so bad. In the BOINC system there are bound to be small disparities between the rate at which WU's can be generated, returned, validated etc. We're just seeing one. Of course we don't want to see this queue grow forever, but the BOINC people will add more capacity for validation as the project grows. Hopefully soon.
19) Questions and Answers : Macintosh : No processing when "idle", but define "idle"! (Message 142521) Posted 25 Jul 2005 by Christian Seti (user) Post: When we set BOINC via its web preferences to perform no processing when the computer is "in use" or "not idle", can someone give me a definition of what this means? Does it fit the same definition of idleness that would trigger a screensaver? Does it apply to the command line/ background service version of BOINC? When BOINC is invoked, how long will it wait for new "idleness" before processing workunits again?
20) Questions and Answers : Macintosh : Suspend on user login, resume on logout? (Message 142520) Posted 25 Jul 2005 by Christian Seti (user) Post: We want to use Mac BOINC with networked, managed clients using Mac OS Server 10.4. This server version offers the ability to trigger login items and logout items, which could be shell scripts. What I'd like to do is run the command line version of BOINC (as indeed this is the only version that will execute when the Mac is idling at the login screen), but have two shell scripts which suspend BOINC when a user logs in and then resume it when they log out. The logout script is probably the easy one as this (I presume) is merely the same shell script as the one in the computer's UNIX startup items. But how do I cleanly escape BOINC with a user login script? I'm thinking of something along the lines of a 'kill' action coupled with 'grep' searching 'ps' but I don't know exactly how to do it. And anyway, shouldn't there be a cleaner way to do this? What if a kill action negates hours worth of work on a workunit because of the abrupt shutdown?

Next 20

©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.