I have been receiving WU with to completion times of 119 hours+. However as the WU is crunched the to completion time drops dramatically. It ends up being only 5 or 6 hours to process.

If you've run one of the nasty WUs to completion, BOINC will have adjusted your DCF (Duration Correction Factor) to match its extended time. It will gradually come down as you do normal work, taking about 20 to 30 WUs to get back to normal.

If you want to fix it quickly, you can close down BOINC, find the <duration_correction_factor> entry for <project_name>SETI@home in the client_state.xml file, and edit it. Given a shown estimate of 119 hours for an unstarted WU which will actually take 5 hours, multiply the value by 5/119 or 0.042. That should be close enough, if it's slightly too low it will fully correct when one WU completes, if it's slightly high it will creep down as usual.

                                                                Joe

I also did this fix and was "rewarded" with a huge increase in computing time.
What i notiched was that 1 slow unit (thats all i had until now) could raise the time instantly.
Correctly processed units seem to only have a minor influence on scaling the time down.
Is this a design fault or a feature of which i fail to see the logic.

---

I have been receiving WU with to completion times of 119 hours+. However as the WU is crunched the to completion time drops dramatically. It ends up being only 5 or 6 hours to process.

If you've run one of the nasty WUs to completion, BOINC will have adjusted your DCF (Duration Correction Factor) to match its extended time. It will gradually come down as you do normal work, taking about 20 to 30 WUs to get back to normal.

If you want to fix it quickly, you can close down BOINC, find the <duration_correction_factor> entry for <project_name>SETI@home in the client_state.xml file, and edit it. Given a shown estimate of 119 hours for an unstarted WU which will actually take 5 hours, multiply the value by 5/119 or 0.042. That should be close enough, if it's slightly too low it will fully correct when one WU completes, if it's slightly high it will creep down as usual.

                                                                Joe

Thank you for the help.

---

I have been receiving WU with to completion times of 119 hours+. However as the WU is crunched the to completion time drops dramatically. It ends up being only 5 or 6 hours to process.

If you've run one of the nasty WUs to completion, BOINC will have adjusted your DCF (Duration Correction Factor) to match its extended time. It will gradually come down as you do normal work, taking about 20 to 30 WUs to get back to normal.

If you want to fix it quickly, you can close down BOINC, find the <duration_correction_factor> entry for <project_name>SETI@home in the client_state.xml file, and edit it. Given a shown estimate of 119 hours for an unstarted WU which will actually take 5 hours, multiply the value by 5/119 or 0.042. That should be close enough, if it's slightly too low it will fully correct when one WU completes, if it's slightly high it will creep down as usual.

                                                                Joe

I also did this fix and was "rewarded" with a huge increase in computing time.
What i notiched was that 1 slow unit (thats all i had until now) could raise the time instantly.
Correctly processed units seem to only have a minor influence on scaling the time down.
Is this a design fault or a feature of which i fail to see the logic.

It is a feature. The reason being that the estimated time to completion is supposed to be slightly on the high side so that you don't download a bunch of work that you can't finish before the deadline.

This has actually happened. We have had "runs" of various angle ranges which take different times to complete. When we have a run of very short running time angle ranges, the Duration Correction Factor (DCF) will slowly drop. With a long run of these, it can get "used" to the low crunch times and start downloading more work to compensate. Then a "run" of very long running time work may come across. BOINC thinks that these will run approximately the same as the others so it downloads a bunch of them. This results in your computer going into "Earliest Deadline First" (panic) mode ignoring everything else just to get these work units crunched.

If the DCF were to decrease immediately upon completing one of these very short running time units, it would immediately download more work and possibly end up in EDF (Earliest deadline first) mode. So it's designed to recover quickly from a low value by jumping immediately to the value of a longer running unit, but decrease slowly from the longer times to shorter ones.

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

I have been receiving WU with to completion times of 119 hours+. However as the WU is crunched the to completion time drops dramatically. It ends up being only 5 or 6 hours to process.

If you've run one of the nasty WUs to completion, BOINC will have adjusted your DCF (Duration Correction Factor) to match its extended time. It will gradually come down as you do normal work, taking about 20 to 30 WUs to get back to normal.

If you want to fix it quickly, you can close down BOINC, find the <duration_correction_factor> entry for <project_name>SETI@home in the client_state.xml file, and edit it. Given a shown estimate of 119 hours for an unstarted WU which will actually take 5 hours, multiply the value by 5/119 or 0.042. That should be close enough, if it's slightly too low it will fully correct when one WU completes, if it's slightly high it will creep down as usual.

                                                                Joe

I also did this fix and was "rewarded" with a huge increase in computing time.
What i notiched was that 1 slow unit (thats all i had until now) could raise the time instantly.
Correctly processed units seem to only have a minor influence on scaling the time down.
Is this a design fault or a feature of which i fail to see the logic.

It is a feature. The reason being that the estimated time to completion is supposed to be slightly on the high side so that you don't download a bunch of work that you can't finish before the deadline.

This has actually happened. We have had "runs" of various angle ranges which take different times to complete. When we have a run of very short running time angle ranges, the Duration Correction Factor (DCF) will slowly drop. With a long run of these, it can get "used" to the low crunch times and start downloading more work to compensate. Then a "run" of very long running time work may come across. BOINC thinks that these will run approximately the same as the others so it downloads a bunch of them. This results in your computer going into "Earliest Deadline First" (panic) mode ignoring everything else just to get these work units crunched.

If the DCF were to decrease immediately upon completing one of these very short running time units, it would immediately download more work and possibly end up in EDF (Earliest deadline first) mode. So it's designed to recover quickly from a low value by jumping immediately to the value of a longer running unit, but decrease slowly from the longer times to shorter ones.

I See.

The client completely unaware of the error assumes this is the first one of a set of similar (long) units.

---

I See.

The client completely unaware of the error assumes this is the first one of a set of similar (long) units.

Exactly, so it will take a while to get the estimated time back down to normal. That's the reason it was suggested editing the client_state.xml file.

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

WU: 147512707.

0.26 cobblestones? Is this correct? The third guy didn't get credit at all. What's wrong? It is the WU that crunched very very slowly.

---

Manned mission to Mars in 2019 Petition <-- Sign this, please.

WU: 147512707.

0.26 cobblestones? Is this correct? The third guy didn't get credit at all. What's wrong? It is the WU that crunched very very slowly.

The third guy aborted the WU manually.

---

http://setiathome.berkeley.edu/workunit.php?wuid=147603991

this was the first of 3 units that was taking 24 hours to process without actually completing itself. My typical runtime on a unit is 1.5 hrs. I actually had chalked it up to signing up for E@h and getting the executables somehow mangled in the memory of BOINC, so I detached from E@h and deleted my S@h executable - which of course screwed up the execution of other WUs.

In any event, only one user claims to have processed that unit, and is making claims for other WUs along the order of 90 cobblestones. He's using a client for Darwin. Is there any chance that the main windows app has a bug that Darwin doesn't?

http://setiathome.berkeley.edu/workunit.php?wuid=147603991

this was the first of 3 units that was taking 24 hours to process without actually completing itself. My typical runtime on a unit is 1.5 hrs. I actually had chalked it up to signing up for E@h and getting the executables somehow mangled in the memory of BOINC, so I detached from E@h and deleted my S@h executable - which of course screwed up the execution of other WUs.

In any event, only one user claims to have processed that unit, and is making claims for other WUs along the order of 90 cobblestones. He's using a client for Darwin. Is there any chance that the main windows app has a bug that Darwin doesn't?

That Mac did manage to get to Pulse overflow before BOINC killed the task for Maximum CPU time exceeded. I think that's mainly because the BOINC benchmarks for those quad systems are not nearly as much higher as their capability to crunch SETI work is. That makes the maximum time limit relatively further out. The other possibility is the compiler for those Mac builds may be producing more efficient code for the triplet finding loop.

The high claims are of course because the stock Mac builds have the 3.81 multiplier from Beta.

                                                                Joe

Is this a 'bad' WU too?

It was running ~ 1.5 hours, it was at ~ 15 % (not stopped!), ~ 2.5 hours (remaining time)

(Normally my PC need ~ 1.5 hours for this AR..)

New Rev. 2.4 from Crunch3r..

http://setiathome.berkeley.edu/workunit.php?wuid=149328091

---

Is this a 'bad' WU too?

It was running ~ 1.5 hours, it was at ~ 15 % (not stopped!), ~ 2.5 hours (remaining time)

(Normally my PC need ~ 1.5 hours for this AR..)

New Rev. 2.4 from Crunch3r..

http://setiathome.berkeley.edu/workunit.php?wuid=149328091

It was created 19 Aug 2007 9:38:04 UTC, long after the splitter problem was cured. Another (wuid 149328099) from the same splitter group processed normally, so the thresholds are almost certainly correct. Looking in the WU or result would of course provide the best evidence, if you saved information before aborting.

                                                               Joe

I too have got another one 04mr07ab.10282.4980.3.4.87_2 and I know it is a -9 one going 2hrs and only 0.06 again. Will leave it to 16:00 BST and then abort it sorry to the other person waiting on this.

---

I too have got another one 04mr07ab.10282.4980.3.4.87_2 and I know it is a -9 one going 2hrs and only 0.06 again. Will leave it to 16:00 BST and then abort it sorry to the other person waiting on this.

That one ran for just over 3 hours on a P4 2.4GHz - a bit slower than yours.

If you could bear to run it for just a little bit longer, you could kill it for good - seems a shame not to put it out of its misery, now you've already spent so much time on it.

Edit - I should have commented on it being a 'past deadline' re-issue. D**n. We could be seeing a lot of these - all hands to the boards!

I suspended my latest bad task (04mr07ab.7106.5798.10.4.216_3) as soon as I got it. SETI isn't sending me any more work though. Is that normal for task suspension?

I suspended my latest bad task (04mr07ab.7106.5798.10.4.216_3) as soon as I got it. SETI isn't sending me any more work though. Is that normal for task suspension?

Yes it is, and I see you've had the WU for over a week - pity you didn't ask earlier.

If you feel up to performing Joe Segur's "technically adventurous" surgery described in this post, you could get it to run very quickly to completion - since it's already been processed by someone else, that would get rid of it for good. But you'll have to be quick: the deadline expires in under an hour, and after that it'll be put in the queue for issuing to someone else.

If you don't feel that adventurous, just abort it now - it's so close to deadline that it'll hardly make any difference.

I too have got another one 04mr07ab.10282.4980.3.4.87_2 and I know it is a -9 one going 2hrs and only 0.06 again. Will leave it to 16:00 BST and then abort it sorry to the other person waiting on this.

On the end it took 2 hrs 45 mins to complete and that is with the latest version of chicken

---

For those of you technically adventurous, here's another option to handle the WUs with negative triplet threshold.

The negative threshold means no triplets can possibly be found, a high enough positive threshold has the same effect. But the very high positive threshold doesn't make crunching slow, it actually makes it slightly faster than a normal threshold because triplet finding has less work to do. So the workaround is:

1. Ensure the WU is not in use by shutting down BOINC. (IF your preferences are to have suspended work removed from memory, then Suspending the work would be enough.)
2. Open the WU in an editor. NOT a word processor or anything else which may change more than you intend.
3. Find the <triplet_thresh>-x.xxxxxx</triplet_thresh> line.
4. Change it to <triplet_thresh>99</triplet_thresh> .
5. Save the WU file.
6. Restart BOINC or Resume the WU.

That WU may not start running. You could force it by Suspending others, or simply let BOINC get to it whenever.

When it does run, it is likely to overflow on Pulses. The result should match that from someone who has allowed the WU to creep to that naturally. Because of the high threshold your credit claim will be lower, but probably by less than 1 cobblestone.

I did this to all 4 I had, wuid 148063182 has validated against a full run, wuid 148063170, wuid 148063178, and wuid 148140560 don't have other completed work yet.

I am not urging anyone else to try this, and can't think of another situation in which I'd consider modifying a WU. Normally any change to a WU would lead to an invalid result, this is a very unusual exception. Even so, I considered long and thoroughly before posting this, and will not be at all unhappy if someone from Berkeley decides to hide this post.

                                                                 Joe

I am not sure if this is a good idea. If a work unit is discarded due to too many errors, this might notify the administrators that something needed to be done about the problem WU. Once Eric finally fixes the splitter (what the admins did looks like a band-aid on code that was not their specialty so their patch may have broken the splitter in a way that they might not have seen), he will know that this work unit errored out, and have it resplit with the corrected splitter. If you modify the work unit, this flag might not be generated.