Running work units that take about 5hrs to crunch and are not due until end of July 12 but BOINC has them as high priority over my other projects which are due in 10 days. Anybody know what's going on as its like SETI is highjacking my PC ? I have several of these to run eg
Work Unit: 02ap10ab.14185.10044.3.10.106
Application: Seti@home enhanced 6.03

Running work units that take about 5hrs to crunch and are not due until end of July 12 but BOINC has them as high priority over my other projects which are due in 10 days. Anybody know what's going on as its like SETI is highjacking my PC ? I have several of these to run eg
Work Unit: 02ap10ab.14185.10044.3.10.106
Application: Seti@home enhanced 6.03

It all depends which version of BOINC you are using. The most recent version in high priority mode always runs the task with the earliest due date first. However, previous versions work their way down your task list in the order the tasks were sent to you until they come to one that will not be completed by its deadline, then they run that task.

---

It's probably the latest as I re-installed recently to fix problem. v7.0.25 (x86) widgets v2.8.10

Running work units that take about 5hrs to crunch and are not due until end of July 12 but BOINC has them as high priority over my other projects which are due in 10 days. Anybody know what's going on as its like SETI is highjacking my PC ? I have several of these to run eg
Work Unit: 02ap10ab.14185.10044.3.10.106
Application: Seti@home enhanced 6.03

BOINC is looking at all work on hand from all projects and thinks it has an expiration date problem. Do you have more than one task from Climate Prediction? That has been reported to cause problems like this.

---

Another Fred
Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop.

Same here. Since 24 houres Seti runs in high "priority" for no reason.
Boinc 7.0.25 with opt-apps, 6 day cache and Duration Correction Factor in it's normal range. So i think there is something wacky on server side. Maybe this are some problems left to fix from the last power outage were some hardware died.

__W__

PS: all other projects set to NNT and their cache is emty

---

_______________________________________________________________________________

<dont_use_dcf/>

[censored expletive]

something possessed Eric or possibly David to upgrade the server code.

Running tasks in HP when dont_use_dcf is active is a known 7.0.25 bug.

Upgrade ASAP to 7.0.28

---

I'm not the Pope. I don't speak Ex Cathedra!

Thank you - the update to the beta works - cruising as normal now :-)

__W__

Edit:

[censored expletive]

That's not ladylike ;-)

---

_______________________________________________________________________________

Not currently running any Climate Prediction tasks. Only running Seti and Edges@home but Seti is taking over everything without my intervention.

So I need to upgrade then. Thanks I'll give it a try.

I think the reason might be getting ready to roll out the new code that Beta has been testing with the don't use dcf for some time.

---

I think the reason might be getting ready to roll out the new code that Beta has been testing with the don't use dcf for some time.

Well, up to a point, m'lud.

There's a whole bunch of new server code, which will be needed to support OpenCL stock applications properly, and this <dont_use_dcf> travels with the beneficial code that we do need. The trouble is that it was introduced into the code-base by stealth (conspiracy or cock-up? you decide), and never independently tested.

And the first version of the client which had the matching support code was v7.0.25 - and of course, that became the one which was bumped to 'recommended' before this particular buglet had been tracked down. And for some unknown reason - as Rom has just acknowledged - the post-v7.0.25 bugfixes never got put through the formal testing cycle. And now we're entering the holiday season....

As I've said elsewhere, this will really only affect people who run multiple projects. The 'high priority' marker is just cosmetic - it affects the order in which SETI tasks are run, but it isn't the sort of elevated process priority wich can lead to added thermal stress on CPUs and GPUs.

The big problem is that other projects won't get their share of resource time, which won't be popular in the rest of BOINC-land. I don't think that will be sustainable for more than a few hours, although they haven't fixed it yet.

I must say I love it how they silently enabled this option server side while recommended BOINC is still 7.0.25, which has a KNOWN, massive bug with this same option.

Bravo!

Of course this is beneficial to S@H itself... everyone is doing seti now, whether they like it or not. LOL

---

OK, panic over - David has removed the setting from the server source code "for now", and Jeff is removing it from the SETI server instance. Presumably it'll take a little while to re-compile and re-deploy the scheduler, but we should be out of the woods soon.

And it's gone - just got a 'clean' sched_reply file without the dread words.

Upgrade ASAP to 7.0.28

Any idea when 7.0.28 will become the recommended version?

---

The Universe is not only stranger than you imagine, it's stranger than you can imagine.

SETI@home classic workunits 1,405 CPU time 57,318 hours

Upgrade ASAP to 7.0.28

Any idea when 7.0.28 will become the recommended version?

When it's completd it's tests at Boinc Alpha, last time i looked at Boinc Alpha (a couple of days ago) it was testing Boinc 7.0.23 and was at 100%,
Today it's changed to Boinc 7.0.28 and is at 0%,

Claggy