We're considering lowering the deadline for SoB to 45 days.

Prior to crunching the current n=27M SoB range, the deadline was 40 days, and the 27M tasks were about 50% longer than the old tasks, so it seemed reasonable to increase the deadline by 50% as well.

Looking at the data, however, almost all SoB tasks have an elapsed time of 45 days or less. Computers have gotten faster, and people don't tend to use their old slow computers on SoB.

We'll make this change sometime prior to the January SoB/PSP/ESP challenge, but since this change only affects new WUs, there would still be 60 day tasks being sent out for a while.

If you have any thoughts about the deadline, we'd like to hear them.

Personally, my two computers are, respectively, very fast and very, very slow. The fast one does a set of four SoB tasks in just under 4 days, and the slow computer takes about 65 days to do one task. It's possible that the latest CPUs using DDR4 memory may be even faster than my fast machine.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Personally, deadline being 10x longer of fastest computers and 3-5x of average/median computer is fine.

Shorter deadline have some benefits and in my view outperformes potencially losing couple of slowest boxes on SoB (which may do better on shorter subprojects)

____________
My stats

To further muddle things, with SoB being part of January's "Year of the Sheep" challenge, we're looking at the next range of SoB tasks (n=31M). We might get to them during the challenge, and if not I suspect it's very likely we'll get there sometime during 2015.

The n=31M tasks take about 30% longer than the current n=27M tasks.

45 days increased by 30% brings us right back to 60 days.

We therefore now have two questions: Whether to lower the deadline to 45 days on current tasks, and what deadline to set on the next batch of tests.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I think having it at 45 days at least until the end of the challenge, even if the next range is needed. Once the challenge ends or when the next range starts (whichever is later) THEN increase the deadline. That way cleanup will be faster.
____________
Largest Primes to Date:
As Double Checker: SR5 109208*5^1816285+1 Dgts-1,269,534
As Initial Finder: SR5 243944*5^1258576-1 Dgts-879,713

I think having it at 45 days at least until the end of the challenge, even if the next range is needed.

Should explore whether 50 or 55 days may work. Should be set to lowest number of days yet still allow 90-95% of computers to finish before the deadline. As you said "Shorter deadline have some benefits and in my view outperformes potencially losing couple of slowest boxes on SoB", so we should push that crossover point more towards less days and losing a few more 'slow' computers. After all it IS the longest CPU sub-project and there is plenty other sub-projects for those 'slow' computers to crunch.


____________
Largest Primes to Date:
As Double Checker: SR5 109208*5^1816285+1 Dgts-1,269,534
As Initial Finder: SR5 243944*5^1258576-1 Dgts-879,713

What percent of total SOB tasks exceed the current deadline?

The better question, therefore, is "How many have an elapsed time of more than 45 days, or 50 days, or 55 days, or 60 days?" Put another way, the question I'll answer, instead of "How many task did make the deadline?" will be "How many tasks could have made the deadline if BOINC ran them sooner?"

In excess of 99% of SoB tasks currently run within 45 days. The 99th percentile is reached at 38 days.

For the larger n=31M tasks, in excess of 97% could be run within 45 days, and the 99th percentile is reached at 52 days.

Is it possible to compare group of tasks by deadline (ie. 45- and 60-days deadline during recent change), once they are returned?
This may put some light on "if BOINC ran them sooner/later".

It's looking like 50 days seems like a good compromise for n=31M.

Merry Christmas all.


____________
Largest Primes to Date:
As Double Checker: SR5 109208*5^1816285+1 Dgts-1,269,534
As Initial Finder: SR5 243944*5^1258576-1 Dgts-879,713

Hi,

after 26 hours, is your job 1% complete or 10% complete?
That is crucial information, not BOINC estimate that may be way off.
Your task can take 2600 or 260 hours depending on how much is complete in 26 hours.

ad 2) Yes, turn off hyperthread while doing any LLR job.
Or at least set BOINC manager to you use no more that 50% of processors.

ad 3) New setting/preferences will not affect already downloaded WUs.

ad 4) I would solve first question first.

Having other projects will eventually cause BOINC to run SoB job in high priority.

My Dell Precision m6500 (i7 m620 w/ 8 gb RAM also used for internet and some games) is 26 hours in showing 2137 hours (about 90 days) remaining.

1) Should I abort this job and change settings to avoid these in the future?
2) Turn off hyperthreading till this job is finished?
That might put me at about 45 days, but this seems to be a low credit payout job and will compete with the higher resource share WU's (Prime is set to resource share 8, Einstein at 545 and Asteroids at 8500) and remove two threads available for watching On Demand shows or playing Civilization.
3) If I turn off long jobs in settings now will that effect this current WU?
4) It appears my i7 m620 takes about 9 to 10x longer than the average CPU time reported (with hyperthreading on) so maybe I should uncheck any job reporting average of 80+ hours or no jobs with greater than 6 day deadlines?

3.328% at 27.23 hours and that calcs to 817 hours or about 34 days.
I was trusting the new BOINC estimation code. That's a huge difference from the 2136 hours currently displayed.

I was looking for clean-up SoB work on one box and got a mixture of 45 and 60 day tasks. None of it is actually challenge-credit work, but a couple WUs are really old and I'm sure the original crunchers will be happy to have a wingman that won't time out. But, it will still be a few more days :-)

I favor the current 45 day limit. When we move to the new range, maybe re-examine.

G

3.328% at 27.23 hours and that calcs to 817 hours or about 34 days.
I was trusting the new BOINC estimation code. That's a huge difference from the 2136 hours currently displayed.

Have you either RESET or DETACHED from PrimeGrid since that change was made on the server? Unfortunately, the change won't be activated until you do that. Note, of course, that doing this will kill any tasks you have in progress, so make sure all of your tasks are done (or ABORT them) before doing this.

I don't remember resetting on this machine nor have I detached.

The WU is at 6.098% on 47:05 hours which is 47.0833/0.06098=772 hours or 32.17 days to finish this WU but the BOINC client estimation algorithm still says over 2000 hours.
Is this a bug that needs reporting or some information the estimation algorithm is using that I don't know about? Maybe it's going by the heavy usage history from me yesterday.
I'll let this play out to the end as maybe there is something to learn. Maybe I should take screen shots for an eventual bug report.

If you have questions about BOINC timing or enabling the exact BOINC timing, please read this thread.

Further discussion about timing should be there. Thank you!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

You do know that you have 45 days after the deadline to get that SoB job in before it's purged, right? You're going to be a day or three late - you will receive full credit.

Edit: Come to think of it, since SoB was part of the challenge, we're not purging any of them until after the challenge stats are final. But a 45-day purge delay is the minimum for SoB.

That link you gave only works for you. For everyone else, here is the workunit in question.

No, the deadline is the stated deadline. But, unlike some other sites, completed workunits (those that have a quorum - two clients agreeing on a result) are still on our site for varying arounts of time afterwards. We did this specifically so that people could have a chance to get credit on late results for those workunits.

The BOINC client doesn't know anything about this. If a task hasn't even started by the deadline, the client will automatically cancel it. But, once the task has been started the client will continue it in spite of the deadline passing. We keep the workunit (with the now expired task(s) around for an additional time so that such tasks get credit. That additional time varies by subproject.

If we extended the deadlines, the BOINC client would just wait that much longer before starting the tasks. The way we do it means that a missed deadline doesn't mean you've totally wasted your computing power.

I'm not sure why those other sites have such long deadlines. For some of our subprojects like the conjectures (ESP, PSP, SoB, SR5, TRP), a single prime returned cancels any further work on that k value. That could mean anywhere from 1/100 to 1/3 of future work becoming unnecessary. In that event any unneeded unsent work is automatically cenceled. So longer deadlines will mean we're possibly wasting the computing power of our users.

Laptops are not all that well suited for running our LLR application. It works the processor pretty hard and generates a lot of heat. Your computer may have slowed itself down in response to that heat. As far as the deadline goes, 99% of completed SoB tasks are returned within 36 days. We have a 45-day deadline. That plus the additional time until purge seems more than sufficient.

This one was given a chance to proceede a week ago. And no luck so far. I might abort it right away (and another one) but I'm curious now -- what BOINC is going to do next?