## Other

drummers-lowrise

Message boards : General discussion : Introduce a grace period for some challenges

Author Message
Bur
Volunteer tester

Joined: 25 Feb 20
Posts: 431
ID: 1241833
Credit: 238,722,572
RAC: 962,818

Message 149514 - Posted: 17 Mar 2021 | 20:03:12 UTC

The current SoB challenge has very long WU times. My i7-4590k takes 2 days 14 h to complete and therefore will manage to complete 3 WUs, meaning I can stop the challenge after 9 of 10 days, leaving one "dead day". My i3-2110 needs more than 5 days, i.e. after halftime I can already remove it from the challenge. I guess many people will run into similar problems.

Simply extending the challenge duration obviously doesn't help.

So what do you think about introducing a grace period within which WUs can still be reported if they were started within the challenge, but WUs started within that grace period are invalid no matter when they finish.

For SoB this period could be set to 2 days, that would decrease the number of "dead days" strongly. Only computers that take more than 6 days would be left with 4 "dead days".

I know this will be a slight disadvantage for fast computers, because they don't need that period. Overall I think it will help increase participation greatly.
____________
1281979 * 2^485014 + 1 is prime ... no further hits up to: n = 4,400,000

Dave

Joined: 13 Feb 12
Posts: 2907
ID: 130544
Credit: 1,352,046,562
RAC: 3,457,852

Message 149518 - Posted: 17 Mar 2021 | 20:54:33 UTC

No. The end is the end. That the *challenge*.

Ravi Fernando
Volunteer tester
Project scientist

Joined: 21 Mar 19
Posts: 165
ID: 1108183
Credit: 9,916,857
RAC: 8,429

Message 149519 - Posted: 17 Mar 2021 | 21:04:21 UTC

I don't think this would actually change anything, except that everyone would start bunkering before the official end of the challenge. Fast computers could download three or four tasks on the last day, thereby "starting" them in the eyes of the server, and spend the two days after the challenge running those tasks in their entirety.

Michael Millerick
Volunteer tester

Joined: 4 Feb 09
Posts: 794
ID: 35074
Credit: 305,783,940
RAC: 325,690

Message 149523 - Posted: 17 Mar 2021 | 23:18:03 UTC

I do think that the challenge durations could be standardized to be a multiple of the amount of time a specific computer would take to complete a single work unit with some buffer. Choosing ten days is relatively arbitrary.
____________

Honza
Volunteer moderator
Volunteer tester
Project scientist

Joined: 15 Aug 05
Posts: 1906
ID: 352
Credit: 4,135,737,284
RAC: 4,707,340

Message 149526 - Posted: 18 Mar 2021 | 8:23:29 UTC - in response to Message 149514.

Simply extending the challenge duration obviously doesn't help.

So what do you think about introducing a grace period within which WUs can still be reported if they were started within the challenge, but WUs started within that grace period are invalid no matter when they finish.

Grace period is technically extending the challenge duration.

On my dual-CPU host, I might be running 8 tasks alongside and each would take let's say 3,5 days.
I might be short of couple of hours on 3rd wave - with 8 tasks only on this machine that would no finish during the challenge duration.
So, I need to change my strategy.

Yeah, that's the challenge and I would NOT change it.

____________
My stats
Badge score: 1*1 + 5*1 + 8*3 + 9*11 + 10*1 + 11*1 + 12*3 = 186

Bur
Volunteer tester

Joined: 25 Feb 20
Posts: 431
ID: 1241833
Credit: 238,722,572
RAC: 962,818

Message 149528 - Posted: 18 Mar 2021 | 14:45:23 UTC

Ok, all good arguments. Especially the bunkering.
____________
1281979 * 2^485014 + 1 is prime ... no further hits up to: n = 4,400,000

composite
Volunteer tester

Joined: 16 Feb 10
Posts: 838
ID: 55391
Credit: 763,378,555
RAC: 403,347

Message 149557 - Posted: 20 Mar 2021 | 8:26:24 UTC - in response to Message 149526.

If you are running multiple tasks on a CPU, then I think you should be able to suspend them all and accelerate one of them with more threads, by manually launching the task from the command line with the desired number of threads. Stop the manual task just short of finishing it and then resume it in BOINC - it will pick up the last save point and continue processing with the number of threads that were originally assigned, and report the task to PG earlier than if you had not meddled.

I didn't try this exactly, but I was getting this kind of result when I copied a task in progress from a slot directory to another directory to benchmark different numbers of threads. The copy kept making incremental progress (at a rate commensurate with number of threads) from the latest checkpoint each time I ran the benchmark.

I don't guarantee that this procedure will work for you - or work at all.

Message boards : General discussion : Introduce a grace period for some challenges