I would say they need to tighten the criteria. If you keep the default buffer of 0.1 + 0.5 days, you would probably qualify with no problem. "Reliable" should be special, not ordinary.

The intent should be to get good results back early of course.

I have no problem with half the allowed time, if that works for you. But I have not had problems with the 0.1 + 0.5 day cache settings on any of my machines, except for work unit availability. I run Ryzens (1700, 2600, 2700) mainly, but also Coffee Lakes, all under Ubuntu 18.04.3. I think they should tailor "reliable" for the better machines, which are becoming more common anyway.

However, whatever works for them is OK with me.

EDIT: The bottleneck seems to be identifying "reliable" machines. There may be no solution except sending out enough to find them. The more the "unreliable" machines suck them up, the longer that will take.

Thanks for reading the comments 🙌

PS, could not fathom 21 per 30 minutes (1008 a day), until seeing the noon stats

Statistics Date		Total Run Time
(y:d:h:m:s)		Points Generated		Results Returned
11/26/2019		1:171:12:41:04		2,325,425		439
11/25/2019		3:308:18:05:40		6,817,641		1,309
11/24/2019		6:183:00:58:27		11,161,094		2,087
11/23/2019		8:002:16:09:25		13,827,241		2,450
11/22/2019		8:273:23:31:07		15,276,844		2,603
11/21/2019		8:281:07:34:31		15,097,973		2,536

Quite a bit less than the daily validation suggested... 1700-2000 before the randomization, than catching up to 2500.

Keith

Thank you for listening to our raving. If you consider an anology with marketing, Delft would be the manufacturer, WCG would be the intermediary (or shopkeeper) and we would be the customer. Whilst the customer is not always right, woe betides a shopkeeper who doesn't listen to his customers.

I have now changed my cache settings in device profile to connecting every 1.5 days with 1.5 days extra cache to allow for my 27 hours crunching time in order to have a WU waiting for crunching to finish.

Mike

I'd like to talk a little more about what "reliable" means, if I may.

I've come to the conclusion that I have a problem with any system which relies upon saying that a reliable host is one that returns a result within x days. That immediately excludes any machine with a cache larger than x. Why exclude them?

BOINC Manager is designed to try to ensure that all tasks are returned by their deadline. Surely the test should be more along the lines of 'How many WUs has this machine returned which were over deadline?', or perhaps 'How long ago is it since this machine returned a WU which was over deadline?'.

Example: A (sub-)project has a deadline of 7 days. WUs average 1 day to process. I have a machine which is always on and has a cache of three days to guard against outages over a weekend. Most WUs will be returned after around 3 days -- too late to record the machine as reliable if the definition is 'within 2 days'. BUT, if you send my machine a WU with a deadline of 2 days, BOINC Manager will panic and start that WU straight away, and you'll get it back in 1 day - well within the two day deadline.

Shouldn't you be measuring how well machines do what they're told to do, and not just performance against some unknowable deadline? If BOINC Manager doesn't know about it, and so cannot react to it, it is simply arbitrary and not a useful measure.