Validation time

Questions and Answers : Preferences : Validation time
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile Tiers Jean-Francois
Avatar

Send message
Joined: 3 Sep 00
Posts: 26
Credit: 514,827
RAC: 0
France
Message 1808296 - Posted: 10 Aug 2016, 12:52:10 UTC

Hello all.
Why the validation time is so long ?
As an example, I have 24 completed tasks that are waiting for validation, the oldest dating from mid June.
I think I understood that validation is depending on other crunchers activity.

Is there a way, when the "Mirror cruncher" doesn't perform fast enough, to transfer the given task to another cruncher ? Or to send him/her a message to recall him/her that he/she is not alone here ?

Cheers
JF
Life is a sexually transmitted fatal disease(E.Bellamy)
ID: 1808296 · Report as offensive
AMDave
Volunteer tester

Send message
Joined: 9 Mar 01
Posts: 234
Credit: 11,671,730
RAC: 0
United States
Message 1808319 - Posted: 10 Aug 2016, 14:24:31 UTC - in response to Message 1808296.  

Read from here to the end of the thread.

Is there a way, when the "Mirror cruncher" doesn't perform fast enough, to transfer the given task to another cruncher ?

Not prior to the WU deadline being reached.
ID: 1808319 · Report as offensive
Profile Stubbles
Volunteer tester
Avatar

Send message
Joined: 29 Nov 99
Posts: 358
Credit: 5,909,255
RAC: 0
Canada
Message 1808413 - Posted: 11 Aug 2016, 0:23:33 UTC - in response to Message 1808319.  
Last modified: 11 Aug 2016, 0:25:28 UTC

Is there a way, when the "Mirror cruncher" doesn't perform fast enough, to transfer the given task to another cruncher ?

Not prior to the WU deadline being reached.

One more reason to reduce the deadline from 40-60 days to 30 or even 20.
Maybe the 20 day deadline (at the bottom of that gragh) is a test by the project staff that we're unaware of.
Or maybe it's the new deadline for tasks that have been reissued after they exceeded the deadline by the 1st host.
Does anyone have an idea if either scenario (or a 3rd one) accounts for that 20-day bar (in the graph)?
Cheers,
Rob :-)
ID: 1808413 · Report as offensive
Profile Tiers Jean-Francois
Avatar

Send message
Joined: 3 Sep 00
Posts: 26
Credit: 514,827
RAC: 0
France
Message 1808699 - Posted: 12 Aug 2016, 11:13:04 UTC - in response to Message 1808413.  

One more reason to reduce the deadline from 40-60 days to 30 or even 20.

This might be a good solution. Making this decision remains in the hands of SETI@HOME staff. They might have reasons that we're not aware for not making this kind of change.

Anyway, many thanks to all for your explanations and remarks.

JF
Life is a sexually transmitted fatal disease(E.Bellamy)
ID: 1808699 · Report as offensive
rob smith Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer moderator
Volunteer tester

Send message
Joined: 7 Mar 03
Posts: 22158
Credit: 416,307,556
RAC: 380
United Kingdom
Message 1808702 - Posted: 12 Aug 2016, 11:33:09 UTC

The reason given in the past by project staff is that the long deadlines are there to allow "even the most humble" computer to get work and return it in time, allowing for those that only run their computers for a few hours a day and use the "screen saver" applications.

I think these days most "windows class" computer are capable of returning work well inside the current deadlines, indeed probably with much shorter deadlines, but there are "android class" user that take considerably longer to process a single unit. Just now, with the amount of work going on to get new data source on line, adjusting the server code to alter deadlines is very low down the project priority list.

At the same time I can see one potential downside of reducing the deadlines - an increase in the number of tasks that time-out and have to be re-sent, which may in turn result in an increase in Work Units that are "scrapped" because they have timed out on too many computers.

Further there are considerations for the definition of the caches - the current limit is ten + extra ten, which means twenty days of cache, so in the worst case a full cache might lead to work that has been started within the deadline by a "slow user" gets aborted because it hasn't finished in time, which in turn "upsets" the user.

It is all a big balancing act.
Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?
ID: 1808702 · Report as offensive

Questions and Answers : Preferences : Validation time


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.