I have been running a 0.6 day cache for years... By using WCG profiles to control how many of each task type I get sent, I can maintain a work load that doesn't quite fill that cache, so when a few units finish they get replenished quite quickly; indeed, when others were complaining about no work my MCM1 caches were all either full or just one or two tasks short... The same applied to OPN1/G and ARP1 when work [other than retries] was actually available.

I still get the odd Server Aborted, but (as pointed out) that's one of the penalties for getting lots of retries... And, of course, it shouldn't abort a user task if it has passed the first checkpoint unless the work unit is known to be bad, so Server Aborted is only bad news if there's a long time between checkpoints - waste of a download, yes; waste of CPU, probably not...

The only BOINC project I participate in that has very long running work units (CPDN) seems to send them out based on the number of available "cores" rather than buffer capacity, so I don't have problems with that :-)

I suspect a lot of those users happened to make their first contact with a BOINC project that had high default cache configurations (back in the day, 10+10!...), and that then propagates to their preferences on other projects -- if they don''t realize it's a problem they won't do anything about it (more on this later..)

Also, I wonder what the Science United user default setup is at WCG - not every user will know that they can change caches and other settings via the client, so if those are high...

Before the pre-hiatus workload clear-out, most WCG projects used the BOINC grace-day option to give No Reply jobs an extra day's grace before sending a retry -- that meant that any "slow" users would either hit "Not Started by Deadline" and self-abort, or would have a bit of extra time to return. That would have stopped most of the Server Aborts I've had (though it's amazing how often I can get my retry sent back before the.late returner sends their result in, especially for OPN1/OPNG!)

I'd be tempted to leave ARP1 as it is - I can put up with the odd aborted job in exchange for trying to keep the generations moving on... However, I'd be inclined to shave a day off the 6-day deadlines on other projects and put the grace day back... I don't think any of the other projects (even HST1) need 5+ days to run a single task, and I wonder how many really slow machines are still running here anyway...

Unfortunately, I suspect significant numbers of the users with large caches are running in "fire and forget" mode and may not realize they are causing any issues (as I mentioend above). Such users are highly unlikely to see anything posted on here :-( And there will also be users whose attitude is likely to be "so what -- I never run out of work and that's what matters" (but how many of those tasks are actually returned in time and count for anything?)

I'm not sure what can be done about it in practical terms -- that's one of the reasons I'd quite like to see the grace period back for most WCG projects...

Cheers - Al.

I run with a 2.0 cache and have for years. Lately I have 4 hours or less of tasks waiting. In the recent past I would have a cache of almost 2 days. Something changed and the cache and active jobs are seeing lots of dry spells.

MCM tasks run in 1hr or less on the AMD 7950X, 1:4hr-ish on the AMD 5950X and 1:42 plus on the AMD 3950x. Larger deltas when running ARP. If running over 8 ARPs on a machine the run time extends significantly. I limit the machines to 4 or 8 ARPs.

You have me at a loss. Please explain what you mean about the types:

This is from the results log of a completed work unit. The line VMethod = NFCV specifies the type to which I was referring.

<core_client_version>7.6.31</core_client_version>
<![CDATA[
<stderr_txt>
Commandline = ../../projects/www.worldcommunitygrid.org/wcgrid_mcm1_map_7.61_x86_64-pc-linux-gnu -SettingsFile MCM1_0193802_5599.txt -DatabaseFile dataset-sarc1.txt
Settings File
DateOfDesign = 20200218
Designer = Krembil/cubes
WorkOrderID = 0193802_5599
DatasetID = sarc1
RSeed = 334745600
StartingGeneSignatureAlgorithm = randomFixedLengthSearch
RunPermutationAlgorithm = 0
FitnessFn = 0
NumberOfGenesInStartingSignature = 20
NumberOfGenesInSignatureMin = 20
NumberOfGenesInSignatureMax = 20
SearchAlgorithmNumberToCreate = 12071
MinFitness = 0.497
VMethod = NFCV
NFolds = 20
SvmArgs = "-v 0 -t 0 -c 1000"
SvmLearnLimit = 250000


Cheers

Hi,

I have the same issue... the new device has been working for about 2 weeks and is not displayed in the device list.

br Igelwurst