Posts by Heechee

1) Message boards : Technical News : Small Word (Sep 20 2007) (Message 649761)
Posted 27 Sep 2007 by Profile Heechee
So, do we really need a whole new mechanism requiring cherry-eaters to report what they have in their bowl, or do we simply need more realistic expiration dates on our food?

In all of the debates on this thread I don't think I have seen where the science is the main consideration. The most important thing to consider is that the greatest amount of work possible is done for the project.

By having WUs that have long expiration dates it can mean more WU are completed in a given amount of time because some of the older machines have a chance to complete the calculations. The biggest problem with long expiration dates is that a few users may get upset and quit the project. Because the ones that would quit would probably have the faster machines, this could have a more detrimental effect than losing some of the slower machine due to short expiration dates.

IMHO, I think that the project should shorten the expiration date a little, but not by that much. Hopefully this will create a good balance and give the greatest amount of WUs completed in the long run.

I also think it would be a mistake to complicate the project with unnecessary extra controls. It works the way it is now, lets keep it as simple as possible.
2) Message boards : Technical News : Splitsville (Aug 16 2007) (Message 623771)
Posted 21 Aug 2007 by Profile Heechee
I don't think they were less noticeable.

You're very right, Kiva. I meant to say less-remembered. 8-)

They were less noticable as well. For example if there was a splitter problem just resend the results already split. There were no (or more limited) status pages to tell what the servers were doing. I don't remember there being a weekly maintanince outage with classic either.

Less remembered because of programs like SETIqueue; because they worked so well participants forget how difficult it was to get work sometimes. This also points to a problem with SETI classic; there were so many queue programs to choose from because it was such a serious problem getting work reliably. There were also no deadlines so it was possible to queue a much larger number of tasks to survive the longer outages.

I think part of it was the computers where a lot slower then and the work units used to take a long time to crunch. I had a script that would copy data into backup directories to make sure that if the project was down I would have data to crunch. I only needed to store 5 or 6 extra work units to have enough to last most of the outages that SETI had then.
3) Message boards : Technical News : Barrel of Bottlenecks (Aug 15 2007) (Message 620396)
Posted 16 Aug 2007 by Profile Heechee

The effect is to cause WUs to progress very slowly - 0.05% in 2 hours seems typical - and then exit with a -9. Helps to keep the load off the download server, of course, but doesn't contribute much to the science.

Had a WU that went for eleven hours yesterday, and still showed only .05% completed. I suspended that one and the next in line took only two hours. (I'm running SETI on my really old, slow box, because my double proc box seizes up on the BOINC client.) This morning there was no new work, so I resumed work on the very slow WU. It seemed to start over again from scratch, showing zero proc time, and now shows a sensible 2 hours to completion.

Also BOINC is having a tough time DLing new work. It's been working on two new WU for an hour or so, already.

As for the credit discussion -- with all the credit I've got, and a $1.25, I can get a cup of weak coffee. IOW, I'm not here for the credits. I want ET to be able to phone home, is all.

I have a WU that I just suspended that had been running for 24:49:05 and only showed 0.020% complete with 27:48 left to completion.

The only reason I am here is to search for a signal from elsewhere in the universe. Credits are nice, but that shouldn't be what all this is about.

I think that Matt and the whole crew do an awesome job keeping things running! Thanks for all that you do!!
4) Message boards : Technical News : Ho Hum (Jun 04 2007) (Message 581409)
Posted 4 Jun 2007 by Profile Heechee

This morning I came in and found my linux desktop CPU load at around 1000. The culprit was beagled. I have no idea what beagle is or what it tries to do - all I know is that I don't need it and it clogs my system. But you can't kill it, and the scant documentation I found says nothing about how to disable it. One problem I have with linux operating systems is the endless inclusion of software packages with non-descriptive names and irrational behavior. Then again I'm a total Luddite.

- Matt

Matt, this may have the information you need to disable beagle.
5) Message boards : Technical News : Normal Operations (May 30 2007) (Message 579157)
Posted 31 May 2007 by Profile Heechee
Well done guys!! Thanks for all of your hard work and sacrifices keeping the project running.

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