But what about the removal of bad WU's from your servers You must set up a way to stop the resending out of the BAD WU's Letting the system purge it self is not right. You have the capability to do auto upgrades you should have the capability to auto abort bad WU;s on client side To let bad WU's run on yours or our system is a BAD THING

The bad WU's are removed from our servers, but we can't remove them from your machines. Hopefully there will be no more bad WU's at all so this won't be a problem anymore.

Well David I let this one FA_RLXpt_hom002_1ptq__361_380_3 run through 48 HR it did not self abort as you said it would ...

The FA_* WUs are old ones from mid-march so they don't have the timeout enabled. As far as I know, these FA_* WUs were never cancelled, so they pop up now and then and get sent out again until 4 people have rejected them.

Can you post a link to the result? I think you will actually get credit for this. The result is reported to us as a large amount of "claimed credit"; we are going through on a weekly basis and granting credit for these jobs that caused big problems and returned "invalid" results. The results and your posting are still useful to us -- in this case, the postings on this work unit helped us track down a pretty esoteric bug in Rosetta. Let me know what the result number is -- if its not flagged to get credit, I can see why.

But what about the removal of bad WU's from your servers You must set up a way to stop the resending out of the BAD WU's Letting the system purge it self is not right. You have the capability to do auto upgrades you should have the capability to auto abort bad WU;s on client side To let bad WU's run on yours or our system is a BAD THING

The bad WU's are removed from our servers, but we can't remove them from your machines. Hopefully there will be no more bad WU's at all so this won't be a problem anymore.

ARGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHH

Another failed project 17027763 12417632 11 Apr 2006 20:35:20 UTC 12 Apr 2006 12:28:07 UTC Over Client error Computing 44,064.20 136.62

This makes at least 5 projects with crashes and more than 5 cpu days wasted in total.

What the hell is happening. To Say I am frustrated is an understatement

I think most of the problems reported in the last few posts were from work units created before the March 28 update--hopefully these older wu will all get through the system in the next day or two.

Lauren, since 35+ of your nodes are "crunching boxes", i.e. dedicated to work for projects like Rosetta, have you ever considered running Linux instead of WinXX (XX=XP, 2K, ME etc) on them? Linux consumes less RAM than WinXX for a minimal system. You don't need the GUI anyway for such a box and Linux's remote-control capabilities are very good.
?

The question was not whether your systems were stable enough to run dc projects (as I've seen your stats in other dc projects).. but to try and find out what's different about your hardware/software configuration that makes it more suseptible to the 1% bug than average. It's a problem that only shows up when Boinc is in control of Rosetta (Rosetta alone crunches through that sticking point) - and seems to be showing up more often on certain hardware. (Come to think of it, if you have a low max time set, and are running through up to 480 WUs a day, to have a few get caught might be the average failure rate..)

The more data about the machines with 1% failures we can give Rom, the more likely he'll be able to track down the intermittent problem. And when we help track it down and get it eliminated.. it'll make life easier for everyone dealing with the problem.

In the meantime.. is the problem showing up on your machines that have 512 Megs, or just on ones with 256Megs? Do you have Boinc setup as a service on the WinXP machines, or as a standard app?

[quote]that is not good. with the jobs currently released, this problem should be greatly reduced, and from the "percent complete" we will be able to tell where the problem is.

would it be possible for someone to write in a script that would automatically abort a wu if it's stuck at 1% for more than say an hour? for those of us running farms this would be a godsend until the 1% stall problem is solved.

I just yesterday emailed David Anderson asking whether such a feature could be incorporated into boinc. haven't heard back yet. if someone can figure out how to do this outside of boinc it would be great.

All work units sent out since Friday have a maximum time limit of roughly 24 hours, so no computers should be getting stuck much longer than this

This thread is approaching 100 posts - Is the project ANY closer to solving the 1% bug?

Yes This what I would like to know "" ANY closer to solving the 1% bug?""
I have had to abort about 10 WU's stuck at 1% For a loss of about 300 Hrs of computer time in just the past week.
Maybe a auto self abort if it go's past 3 times the limit
People like me some times can not check up on all the nodes every day, and to let a WU run for 114 Hrs is just a waste of time and Money I do not work in IT and I pay for the total cost to run DC

In most cases an automatic abort feature causes more problems than it solves. The Max time errors were caused by an attempt at automatic aborts. But more often than not restarting the WU will work to "un stick" a WU.

While this sticking problem is a bigger issue for unattended systems, I am seeing a lot of people on this thread aborting WUs in less than 1/2 hour of run time. Very few of the WUs will get to more than the 1% stage in under a half hour. There are some that will, but the current batch is not among those.

So if you are aborting in under a half hour, especially if you are not checking the screen saver to see if the WU is stepping, you are making your problem worse. If the WU is stepping (even slowly) it is not stuck. If there is no activity on the screen saver except for the clock, then it may be stuck, and then it is appropriate to take some action. But the first choice should be a restart of the WU. In most cases rebooting the system is not required, only stopping and starting BOINC.

But remember, there are times in the normal process where the time between steps may become significant. I have seen this interval exceed 20 seconds or more in some cases. The slower the system the longer the interval. So examine the graphic display carefully for activity.

The RALPH project is testing a possible solution for this issue right now, so help is on the way as Dr. Baker said in his post below.

This thread is approaching 100 posts - Is the project ANY closer to solving the 1% bug?

Well with a reply like this one accuseing me of just doing it for the points will do NOTHING but but push me way.

First, realize that _I_ am not "project staff" - I'm a volunteer participant just like you are. That tag to the left under my name says "forum moderator", not "project" anything. However, I volunteer my time to help people who have a problem and ask for help on these boards.
.