I didn't want to declare my strategy a success before it was actually measurable, but it seems to have worked...

Sapphire: 24 Feb: 1,971,297 points 5,857 results 2:000:02:05:48 run time
Emerald:  11 Feb: 1,007,282 points 2,390 results 1:000:22:43:45 run time

I was just 5 days short of Emerald when the project stopped in December so roughly speaking Emerald reflects the first phase of the project and the delta between it and Sapphire reflects the current phase of the project. So I managed to haul my points per hour back from 2 to roughly the same average as in the first phase of the project.

My theory is that those of us who had pounced on the project when it restarted and got reliable status early as a consequence were in effect in a race to the bottom and we ended up staying at the bottom upon achieving reliability. However, new people are joining the project all the time so there is still a small proportion of WUs where I'm wingman. These are the WUs to treasure because the points granted are typically 5x to 10x what my device was claiming.

So, how to get more wingman WUs? Only by processing more WUs!

So I did some selective aborts of unstarted WUs from the same batches as those that were taking >12 hours and delivering ~2 PPH, effectively to clear the logjam and improve my chances of getting some more WUs as wingman. I aborted roughly 2 such WUs per core across my devices, effectively eliminating about 1 day of crunching in total....and then went on vacation.

Having become the aborting wingman on these WUs I got to see the claims and points awarded to those who did crunch them - the lowest grant was around 150 points and the highest just under 600, so between 5 and 20 times more than I was getting for them! As Rob has pointed out, some of these WUs are still coming back as _3 and _4 issues, but I have accepted them and allowed them to crunch and I got about 150 points for them this time round.

So, my conclusion is that the problem was temporary and caused by the enthusiasm of us early adopters who pounced on the project the moment it restarted. It's now mitigated by the gradual drift of new crunchers into the project. If you feel your points claims are too low, then maybe crunch the WUs where you are wingman first, so that the grants have a chance to influence the subsequent claims your devices make on the other WUs where there is no wingman.

I know the points for OET1 vary all over the place, but this is the first time I have seen getting a fraction of a point for a workunit.
OET1_ 0000443_ xMBGP-FW_ rig_ 20210_ 0-- Computer Valid 3/18/15 12:47:53 3/18/15 18:47:19 0.23 / 0.23 0.8 / 0.8

Sometimes you just have to grin and bear it

Cheers

All this was good for a day record result validation of 776K. Yesterday had maxed out on one device for IP tasks [35 per core] and buffer setting at 1 day, valued at 0.8 days TTC per core. This morning the buffer had shrunk to 26 per core, but at a TTC of 1:18 days i.e. not fetched work for a longer time.

The project average was pretty good though, 0.47 hours duration at 28.2 C/H... who the winners and losers were in this euphemistically called Credit_New 'system', you may make out for yourselves... had one where my copy 'claimed' 1.51 credit and the wingman 23.53, for the same work, to the FLOP exact

Yes, me fastest [buffer-less] Linux ran dry on 9:27 UTC with batch 449. Not parsed history, but suspect we've had everything from 298 to 496 except the _OM long running that the techs are holding back.

P.S. Have the added line that "Tasks are committed to other platforms", which will be the repairs [to suppose]. Added MCM to the profile for now.

Ah, that's finally forward in batch count since 496 some month or so ago.