Server state: Over
6 Jan 2023 19:03:27 UTC
Topic 228869
(moderation:
I have running at the moment some of the big "Binary Radio Pulsar Search (Arecibo, large)" WUs...
They've gone past their deadline and the server status gives:
Server state: Over
Should they be aborted?
Or is it still worthwhile to leave running even though past the deadline?
One example is:
Name: p2030.20200628.G47.06-03.53.C.b5s0g0.00000_2080_0
Workunit ID: 697989736
Thanks,
Martin
See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)
No abort them if they are
)
No abort them if they are past deadline. You are wasting cpu cycles and wasting up/dn load server resources if you try to return them past deadline. The tasks have no value to the project now.
Thanks for clarifying that,
)
Thanks for clarifying that, good to know.
They're now aborted.
Thanks,
Martin
See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)
Keith Myers wrote: No abort
)
From this example, that is not the full story...
See: Task 1430264656
Note that had the server state listed as "over" and yet was accepted even though reported a few hours late.
My guess is that you can still meaningfully return a result provided noone else has already returned a result and provided you can still see the details listed for your particular task.
Happy crunchin'!
Martin
See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)
Yes, this can happen . . .
)
Yes, this can happen . . . . rarely when your returned task is validated after the deadline. But you have to catch the task before any other host has been sent the followup wingman task iteration.
I wouldn't count on the circurmstances happening consistently.
Keith Myers wrote: Yes, this
)
Especially with people running very small caches these days at most projects.
Also depends on the
)
Also depends on the project.
I have several hundred "server cancelled" wingman tasks on a couple of projects where the schedulers get antsy when the wingman task deadline is approaching expiration within a couple of hours but hasn't returned the task yet and the projects scheduler pre-issue another wingman task, and then the first wingman task squeeks in under the task deadline limit after the secondary, tertiary et al wingman task is issued.
So the latest wingman task is cancelled because consensus was achieved by the original tasks and after the issuance of the latest wingman task return.
And you might have a fast host that has already completed the task all for nought and get no credit.
So it all depends on project schedulers and circumstances.
Keith Myers wrote: Also
)
That's true I had forgotten about that!!
For another example that
)
For another example that didn't die:
Task 1444966435
From:
See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)
ML1 schrieb:So... Despite
)
There's no wingman for O3MD1 CPU tasks. e@h's scheduler is in no hurry to reassign such delayed tasks. I think that's also because einstein@home heavily modified the BOINC server software to optimize for task locality. The very large data files for O3MD1 CPU tasks should be duplicated for as few user hosts as possible (saving network bandwidth), so that client hosts process as many tasks as possible that are close together (different parameters, same raw data). Waiting many days past the deadline before reassigning a task seems to be a smart strategy for O3MD1 CPU tasks.
It's different for other science apps, like BRP4, BRP4X64where there are wingmans and each workunit processes different raw data files. No task locality...