Hi, my first posting here, but I have read a lot of the forum over the last few days.

I have a a fairly slow PC that is set to cache 2 days work. I have looked at the status of my next few WUs. This one http://setiathome.berkeley.edu/workunit.php?wuid=110515578 has already reached its quorum before my PC has started work on it. It is my next WU due to start in about 2.5 hours from now.

Is there any value to SETI in starting work on this unit or should I abort it and let my PC crunch units that have not yet reached quorum? Keith

I would abort it. Once credit is granted the result is transfered to the science database, and the only reason it hangs around here is so that late hosts can still get credit.

---

BOINC WIKI

BOINCing since 2002/12/8

I would abort it. Once credit is granted the result is transfered to the science database, and the only reason it hangs around here is so that late hosts can still get credit.

Thanks for the reply. I will probably wait for a few more replys to this post by Suspending it instead of Aborting it.

I am quite new to BOINC SETI, although I originally ran S@H in 1999 until 2001. I've noticed that most of the WUs currently being sent out are '99 '00 and '03. I have read about some of these being tapes previously rejected due to noise. Is S@H still getting new tapes or are the '03 ones the newest that they have?

Hi, my first posting here, but I have read a lot of the forum over the last few days.

I have a a fairly slow PC that is set to cache 2 days work. I have looked at the status of my next few WUs. This one http://setiathome.berkeley.edu/workunit.php?wuid=110515578 has already reached its quorum before my PC has started work on it. It is my next WU due to start in about 2.5 hours from now.

Is there any value to SETI in starting work on this unit or should I abort it and let my PC crunch units that have not yet reached quorum? Keith

Unless it has passed its deadline (Jan 31, in this case) - crunch it, don't suspend it. Don't try to micro manage BOINC, just let it do its thing.

---

I am quite new to BOINC SETI, although I originally ran S@H in 1999 until 2001. I've noticed that most of the WUs currently being sent out are '99 '00 and '03. I have read about some of these being tapes previously rejected due to noise. Is S@H still getting new tapes or are the '03 ones the newest that they have?

The main Seti is not getting any newly recorded data at the moment. We are crunching the tapes that were put aside for one reason or an other, as well as some whose data never made it to to database due to problems in the processing like splitter malfunction. I believe the last tapes were made in mid 2006. Seti Beta is currently testing recordings from the new multibeam receiver array too make sure no problem exist in processing these before being introduce to the masses.

I personally never bother to check my results to see if I'm first or last to report. My slow system, with its 14 projects, is sure to often be the last. I just crunch what I get in the order I get it. There are plenty of people out there that only crunch when their screensaver is on that are just as slow.

I found that micromanaging Boinc tends to cause more problems than it solves and appears, judging from the posts I read, to become addictive and drive people nuts as they try to squeeze every possible cycle out of their systems.

---

Boinc V7.2.42
Win7 i5 3.33G 4GB, GTX470

Hi, my first posting here, but I have read a lot of the forum over the last few days.

I have a a fairly slow PC that is set to cache 2 days work. I have looked at the status of my next few WUs. This one http://setiathome.berkeley.edu/workunit.php?wuid=110515578 has already reached its quorum before my PC has started work on it. It is my next WU due to start in about 2.5 hours from now.

Is there any value to SETI in starting work on this unit or should I abort it and let my PC crunch units that have not yet reached quorum? Keith

Aborting it would allow the deleters to remove those results, a small help to the overloaded servers. Good idea, since as you've surmised crunching it wouldn't help in any way. But the key is that a canonical valid result has been chosen, not always the case when the quorum is first reached.

David Anderson posted a message on one of the mailing lists awhile back saying he hoped in future to make BOINC notify users about queued WUs which already had a canonical result. Obviously he intends to encourage aborting such WUs, though it would be a user choice.

                                                               Joe

*lol*

I do over 30 WUs per day and have a job, there is no way I could have the time to check what WUs to crunch or not...

...and it would go against what they say in this thread:

http://setiathome.berkeley.edu/forum_thread.php?id=36714

Well, some people are impossible to please right, damed if you do and damed if you don't !

That was the thread which prompted my original post. The difference for me is that I am currently only running a single host which crunches 2 or 3 WUs a day on average. My CPU time per average WU is between 6 to 12 hours. I have only been active on SETI BOINC since 7/1/07.

I am NOT proposing to abort WUs that have not yet reached quorum, only ones which have already reached quorum before they reach the top of the cache on my PC. As I posted previously I currently have my cache set to 2 days although I actually connect 2 or 3 times a day (due to recent problems at Berkeley).

I was looking for opinions to confirm my reasoning that a WU which was already reached its quorum does not need my 4th result although I understand that I would receive credit as long as I return it before the deadline. I can also see the wisdom in not "micro managing" BONIC, which in the case of faster crunchers seems sound advice. As my PC is relativly slow, and I have the time to look at the BOINC manager 3 or 4 times a day, this works for me.

I am just trying to maximise the value of my CPU time to the project, and wanted to confirm my hypothesis.

I would abort WUs if they already have the neccessary quorum. Basically, if credit has been granted to the other computers then there is no need to do the computations again. Aborting won't cause the WU to be sent out again and, as others have pointed out, it lets the server finish off the unit and get on to new things.

---

Personally, I think they should just eliminate the possibility of wasted "busy work" computation by going to an IR 3 instead of 4.

So what if someone has dropped out, or a host has malfunctioned and a fourth needs to be generated? All it means is you're going to have a pending hanging around longer in the grand scheme of things and it's not like you won't get the credit eventually. The fact is the pendings don't even effect your RAC significantly once you reach steady state for a given preference set.

Given the backend hardware and other issues we have all seen recently, IMHO it is far better to knock 25% of useless BOINC Database load right off the top than bring the project down to accomodate 'instant' gratification for something ephemeral like credit. Sure, I like my credit as much as the next guy, but it seems pretty obvious if the project is down or running in crippled mode when your host wants to upload/report or needs new work you're not helping your cause overall by demanding no delays in granting credit.

Alinator

Why the 4th initial replication? It's a matter of a finding a balance between the load on the database and the wish of people to get a faster turn around on the issuing of credits. There was a debate about this one or two years ago. Someone did a statistical study to determine how often a 4th or more replication was actually needed. I can't find the threads right now. Maybe someone can dig it up.

At that time, with the fixed 2 weeks due date, it seems to me that it was just as efficient to have that initial 4th initial copy as far as the load on the database was concerned and the added benefit was to provide the faster turn around time for those that wanted the credits faster. It would be interesting to revisit this issue to see what effect that the faster computers, the enhance client, the optimized clients and the variable deadlines has had.

---

Boinc V7.2.42
Win7 i5 3.33G 4GB, GTX470

Agreed, but that was then, this is now. Funding and human resources are in even shorter supply than they were then.

Also, they have gotten some newer equipment since then, and recently we seem to have begun to push it to it's limits again. So as you say, maybe this question should be revisited again.

If taking some of the pressure of the existing equipment with a simple config change buys the project some breathing room to work on rolling out the other projects pending rather than having to spend large amounts of their very limited time 'firefighting' backend problems then I'm all for it, even if it means I have to look at a longer list of pendings.

Alinator

Agreed, but that was then, this is now. Funding and human resources are in even shorter supply than they were then.

Also, they have gotten some newer equipment since then, and recently we seem to have begun to push it to it's limits again. So as you say, maybe this question should be revisited again.

If taking some of the pressure of the existing equipment with a simple config change buys the project some breathing room to work on rolling out the other projects pending rather than having to spend large amounts of their very limited time 'firefighting' backend problems then I'm all for it, even if it means I have to look at a longer list of pendings.

Alinator

We're crunching something like 480000 tasks per day, 120000 WUs from the splitters with Initial Replication 4. Reducing it to 3 would mean the splitters would need to produce 160000 WUs a day to match demand, the database for current work would still have to keep track of about the same amount of data. I don't see a reduction in server load, rather a minor increase. The big plus of course is that 33% increase in the amount of original data processed, it's going to be needed for the ALFA data.

                                                            Joe

Hmmmm, yes the number of new results split would go up all other things being equal. However, shouldn't the total number of open WU's go down, since the backend wouldn't have to be waiting around for the useless 4th result to arrive and go through validation to be purged from the DB. It seems to me when you consider the real mix of hosts in the field includes a fair amount of older hardware, they comprise the lions share of 4th's holding up the purge process. So the backend ends up waiting for them regardless of whether the IR is 3 or 4. Of course folks running monster caches plays a role here too, so it's hard to say just how much an IR of 3 would make a difference either way.

I wonder if exploring these questions was one of the reasons Eric went to 3 over on Beta.

I'm just thinking that anything to reduce the overall load on the backend processes is a good thing under the current circumstances. ;-)

Alinator

I feel micro managing the client is not a good idea. If you main all you are concerned about is credit and not science don't worry you will get credit for the units you crunch if returned before the deadline. Why spend hours matching you work units? If you have nothing to do leave the computer alone it will crunch faster idle then surfing and delete workunits.

---

SETI@home classic workunits 5,429
SETI@home classic CPU time 73,472 hours

The client was meant to be left alone with little interference from the user. It does work better that way. Crystallize references a discussion regarding a user who was doing a great deal of selective dumping for the purpose we think of skewing their RAC. The user in question was dumping low RAC returning work units. Crystallize seems to be in support of this but like many on users I do not advocate it and feel there is a bit of a moral and integrity issue there.

In the case of my machine I would literally go NUTS trying to micromanage it all day. I keep a cache of between 850-1100 work units which equates to a full 10 day cache. My computer returns 4 work units every 1 hour 10 minutes which means I would constantly be checking work units if I was to follow that line of micromanagement. The best approach is crunch what Berkeley gives you and don't complain too loud.

---

Oh...and get yourself an optimized app...Chicken makes some great ones. It could potentially get your computer to crunch up to 50% faster. See this thread for more info.

---