1) Questions and Answers : Unix/Linux : No graphics at all (Message 534056) Posted 20 Mar 2007 by AtesComp Post: This is a "well" documented problem. The BOINC manager will let you run the graphics once and then won't work again until the BOINC client is shut down and restarted. The problem is that the BOINC client actually starts the graphics and, when the window is closed, it doesn't release some kind of "hook" to the window. Therefore the client doesn't open a new graphics window on the second attempt. To me, the whole system for displaying the graphics through the client is annoying and bad programming. The manager ought to be able to handle the graphics instead as a separate process and let the client crunch away.

2) Questions and Answers : Unix/Linux : Problems with SETI@Home Linux after viewing graphics (Message 504801) Posted 18 Jan 2007 by AtesComp Post: I have continually had the same kind of problem with BOINC. I'm now on 5.4.11 and still have problems. I think the problem revolves around the way "boinc" and "boincmgr" are run and interact. I only run SETI, so the discussion should be clear. 1. Run "boinc" and "boincmgr" as a regular user: ---------- Select a running task in the task tab and press "show graphics". This lets me use the "show graphics" button once. When I close the screen (use the x button) and press "show graphics", nothing happens. I have to reboot to get a new graphics screen. 2. Run "boinc" as a daemon during system boot and "boincmgr" as a regular user: ---------- The daemon is setup with service script in my OpenSuSE 10.0 system (this is not well documented). Need to use the command "xhost +local:" in a terminal before starting "boincmgr" (this is not well documented). Select a running task in the task tab and press "show graphics". This used to work, sometimes. Now it doesn't work at all. I would think that most people would prefer (2) as it runs always as long as the system is on and in my case at runlevel 5. This second example brings to light the problem with running the graphics under BOINC--the client program is actually doing the graphics, not the manager. Would it not be cleaner, and possibly more flexible, if the manager ran the graphics instead of just sending a command to the client? The manager could connect to the client (RPC, UDP/TCP port, etc) to get the display data and display it locally. This would make creating a screen saver a snap by having it connect to a client and auto-selecting a running task! It also offloads the graphics from the client--all it needs to do is report data in a separate thread. I see the problem is that each project has its own graphics system. Fix it by having the client send the graphics code for the project to the manager and store it for later use, and update as needed on each reconnect. The servers do this kind of thing for the clients to process the work units so why not have the clients do the same for the managers graphics display. A possible further problem to this is platform compatibility. Java anyone? UPDATE: To get a new graphics screen, the client needs to be stopped and restarted after closing the graphics screen. I can recreate this at will using either method 1 or 2. It seems like the client's graphics screen is not closing properly or the client "thinks" the graphics screen is still open. A stop/restart of the client obviously resets this. UPDATE 2: This has been discussed before in other threads and was referred to as a "graphics hook" not being released. It apparently happens with all the different project graphics. It is true that the computing power is the primary purpose for running this software, but it gives non-techies a reason to buy into this program--graphics adds a "cool" factor--and results in an overall increase in computing power. The frustration continues...

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