I had to turn off BOINC SETI on one of my servers for a few days, so now several of the WUs on that machine are past their report deadline. Running these WUs is a waste of time, right? So, how do I get rid of them? I tried updating the project, installing the latest BOINC, etc. but these stale units are still there.
Any suggestions?

---

reset

---

Semper Eadem
So long Paul, it has been a hell of a ride.

Park your ego's, fire up the computers, Science YES, Credits No.

As Pascal has said in his message of no meaning.

RESET should work.

but still has my approval...


It is 10 oclock, do you know what your WUWUs are doing tonight...

No but i know what i am... and the missus does too...

And it aint crunching...

---

Reset worked just fine. Thanks for the speedy replies.

---

> Reset worked just fine. Thanks for the speedy replies.

So, what about our SLOW replies?

:)

---

There's got to be a better way than simply resetting - which as far as I can tell simply deletes the whole project directory and downloads a fresh seti client and new workunits. By doing this, not only are we dumping the expired units, but all the other units too which then just further delays the validation system as these must wait to expire and then be reassigned.

Has anyone simply tried manually deleting the units that have/will expire before you can process them and leaving the rest. Just wonder if this would work?

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

> There's got to be a better way than simply resetting - which as far as I can
> tell simply deletes the whole project directory and downloads a fresh seti
> client and new workunits. By doing this, not only are we dumping the expired
> units, but all the other units too which then just further delays the
> validation system as these must wait to expire and then be reassigned.
>
> Has anyone simply tried manually deleting the units that have/will expire
> before you can process them and leaving the rest. Just wonder if this would
> work?
>
> Ned
>
Ned,

I've tried the abort feature of boincview, and it works fine, you select the offending WU, pick abort, the WU almost instantly goes to 100%, then 'technically fails' while leaving everything else absolutely intact. I used this to ditch the infamous 14mar04aa WU's that were giving grief before boinc 4.12 got released.

TTFN

---

Ken Phillips

BOINC question? Look here



"The beginning is the most important part of the work." - Plato

Ned asked:

> Has anyone simply tried manually deleting the units that have/will expire
> before you can process them and leaving the rest. Just wonder if this would
> work?

Not quite, but after installing a newer boinc version to a new directory instead of the one where my old boinc client was located, I did notice that I lost my cache worth of WUs due to that. So the new client started by downloading a whole new batch of WUs. Wasting the WUs in the old cache seemed a bit of a shame (leaving others waiting for credit a long time), and since they were for the same version of the seti client, it seemed to me that I should be able to merge the two caches. This was accomplished by moving the contents of old project's directory to the new one, along with the `slots' directory with the work units that were being processed by the old boinc client (renaming the subdirectories to higher slot numbers not used by the new clients and adjusting the entries in the old client_state.xml accordingly), and subsequently merging the client_state.xml files by hand. A lot of work (I'll be sure to install future boinc clients to the same directory as the old one), with the potential that making a mistake would trash the newly cached WUs as well (so I made a copy of the whole new boinc directory before beginning), so only do this if your really know what you're doing.

In short: it does seem possible to edit the client_state.xml file (when boinc is not running of course) and get away with it, so I guess deleting WUs from there is an option too (though be sure to keep the file_info, workunit and results in correspondence: delete all of them for the same work unit or none). Maybe just deleting the WU file from the project subdirectory will also do the trick, as the seti application will have no choice other than reporting an error when it gets told to start that WU (since it won't have a WU file to load anymore), so boinc can move on quickly. This is probably what boincview is doing.

---

> Ned asked:
>
> > Has anyone simply tried manually deleting the units that have/will expire
> > before you can process them and leaving the rest. Just wonder if this
> > would work?
>
> [...]
>
> In short: it does seem possible to edit the client_state.xml file (when boinc
> is not running of course) and get away with it, so I guess deleting WUs from
> there is an option too (though be sure to keep the file_info, workunit and
> results in correspondence: delete all of them for the same work unit or none).
> Maybe just deleting the WU file from the project subdirectory will also do the
> trick, as the seti application will have no choice other than reporting an
> error when it gets told to start that WU (since it won't have a WU file to
> load anymore), so boinc can move on quickly. This is probably what boincview
> is doing.
>
Yes, it IS possible to manually delete the expired WUs. If you delete only the outdated WU files, they will be automatically downloaded again upon attempt to crunch them (see http://setiweb.ssl.berkeley.edu/forum_thread.php?id=4823#30541).
But you will off course penalize the others to wait longer for theit credit.
Until the proposed WU abort functionality will be available directly in the BOINC client, possibly letting the servers know about the aborted WUs.

Peter

For what it's worth, I've had 5-6 WU's expire as a result of the massive increase on processing times and the fact that the benchmarks are now completely out to lunch. :P

It's so bad now that on some of my machines, setting it to connect ~every 2 days (upper limit is 4... I know), I was having WU's expire (after 14 days) with the resource share I had it set to. I've since changed the connect to every 1 day, but still find it vaguely disturbing that the project can't manage to pull down an appropriate amount of work. (sigh)

In any case, the only GOOD thing that I found was that I still got credit for those WU's even though they were returned after the 'expiration' date. I'm not sure if I just got lucky that they hadn't already gotten 3 good results on those or if mine had been a 4th, that I still would have been credited.

I sure like the fact that they fixed the results table, so I can see these things, but also think it's sure a shame that the 4.05 WU's are so screwed on their processing times vs benchmarks that they're hardly worth crunching anymore. :P

---

>
> I sure like the fact that they fixed the results table, so I can see these
> things, but also think it's sure a shame that the 4.05 WU's are so screwed on
> their processing times vs benchmarks that they're hardly worth crunching
> anymore. :P
>
Actually it is the other way around. Previous to BOINC 4.13, the benchmarks were not completing their work as the optimizer removed some critical code. Therefore the old versions of BOINC were granting way too much credit.

---

BOINC WIKI

> Actually it is the other way around. Previous to BOINC 4.13, the benchmarks
> were not completing their work as the optimizer removed some critical code.
> Therefore the old versions of BOINC were granting way too much credit.

What I meant was that I'm now having problems with work expiring because the WU's now take far longer than the benchmarks indicate they should. For me at least, turning the 'cache' up to anything more than 1 day means some WU's will expire after 2 weeks.... that's a LITTLE off, dontcha think? ;)

---