Have some smaller units as well and your cache will fill up. There are plenty of units available - just not on demand. With 50/50 you will fill up your arp cache within a day. It is reporting the other units that brings you the other arp units.

Mike

It was recently stated by uplinger that the circulation was upped to 6000, which I interpret as grid blocks. Quorum 2, that's 12,000. Since the participation rate is, ahem, the daily validation averages just over half of that. https://www.worldcommunitygrid.org/stat/viewP...&numRecordsPerPage=30

When the new number came out, I decreased cache from 4 to 3 and it gets quite quickly refilled when a result is reported (20 minutes upload from here plus 2 minutes forced back off). Today, I'm reducing from 3 to 2. Not that it makes any difference to the returned/validated, just that this cuts the time my machine is returning a result from 72 hours or so to 48 or less, given they take about 22 hours to crunch, 1 at the time. So from now 1 will be waiting on the other to do the computing about 1 day minus about 20 minutes before starting.

PS He was contemplating to increase it further, but for now is sticking to the randomized distribution i.e. no hard timing. 6 threads on OPN1 ensures the server is quizzed about 60 times a day and that seems to be enough to hit on a arp1 filled slot. Best I can do to get 1 thread do rainfall prediction 24/7.

Yves, you are lucky with the fibre optics. My road is due to get fibre optics later this year. The nearest point at the moment is 500 m away.

Just to confirm what has been said before, there are now plenty of arp units. It is just that they are not available at all times. They are released randomly, which is why you need to run short duration projects alongside arp in order to update often enough to get those units when they are released. That also helps to keep the crunching time for arp units down to a minimum.

The optimal settings for arp would normally be to use app_config to restrict your arp crunching to half your available cores/threads and your arp cache to twice that. That way your machine would also be classified as 'reliable' and get re-sends which would only have 3.5 days to be crunched.

You can use the other half of your threads to crunch opn and/or mcm which are much shorter and readily available. There are also capacity issues with mip and availability issues with hstb.

Mike

The whole of my telephone exchange area has been readied for Fibre Optic. They just need to sort out a few local problems (most already done) and then they will draw the new cables through the existing ducts all over.

Mike

And so Murphy meets member. Reduced the queue from 3 to 2 given the greater availability, but number 2 is now 12 hours into computing and no new one waiting to start during the 20 minute upload and report phase... That's heading for an idle thread as it is set for exclusive ARP1.