Paul

My formula allowed for an extra generation to allow for the return of the last generation, but it was devised before we knew about all these stragglers.

Kevin

Might I suggest that in order to move these stragglers along as fast as possible, you adjust the qualification for 'priority' status so as to keep the queue of stragglers close to zero and concentrate the fastest machines on the stragglers. That way they turn around quicker.

An interesting statistic is that as at 24 July, when 081 started, 121,394 x 2 units needed to be returned to complete 081 including all the stragglers. On 30 July, when 084 started, that number had risen to 178,532 x 2. During those 6 days, we started 3 new generations and the oldest stragglers also moved forward 3 generations (ignoring those on generation 001).

When will those 6 be released?

Mike

Now that we have exact figures, we can use a more precise methodology:

As we are now averaging about 17000 results returned per day and there are 99 generations to go plus 178532 catch up units at the start of generation 084, the formula is (99*35609*2+178532)/17000 = 425.24

That gives a target date for completion of the end of September 2022, assuming crunching continues at the same rate until the very end. Assume the end of October 2022 to allow for the tail-off of contributions. That would be my 80th birthday!!!!

The current generation is no longer an accurate method to determine the completion date but it was the best we had available before the recent updates.

Mike

Those who have received gen 084 will probably get those back within 2.3 days (some sooner), at which point, once validated, 085 will get built and sent. 2.3 days later 086 will get built and sent. Seems like the front end will be expanding rapidly.

Based on the last 5 gens being low priority, that would suggest the high priority work will grow. Logic would then suggest that, over time, the high priority work would over take the lower priority work and front end growth would stop. However, if we apply the "hold high priority to 20 percent" rule, there would be nothing to attenuate the front end growth and the range between front and back should expand. Should be an interesting remainder of the year for ARP1.

Mike,

You must be describing "proposed future conditions" because it doesn't seem that is how it is working now.

It's great to put the fastest machines on the high priority work but it's the 20% rule that is the limiting factor here. On any given scheduler request, there is a 80% chance the fast machine will get a low priority work unit assigned and, on any given scheduler request, logic would say that it is most likely a fast machine generating the request. Therefore, it is more likely a fast machine will get a low priority WU. Then, you add in the additional 100% chance the non-reliable machines will get a low-priority WU. Which matches what I'm observing on my farm. The reliable machines are getting 80% low priority work

If Kevin adjusts the definition of "low-priority" to be the latest 5, then 6, then 7, generations, what will happen is, the low-priority work will expand from 5 generations long today to potentially 15 generations more in the future. The "nose" of the generational "snake" will continue to grow at the same pace. The removal of the backlog exacerbates the front end growth problem. As soon as a 84 is validated (may only be one), an 85 is built, sent, and starts execution. It returns and 86 is then built, sent, and executed. I guess, as more and more low priority work is out in the wild, the chance of getting a later generation decreases and the nose growth would begin to slow.

I would remove the 20% rule and let the ecosystem manage itself. There aren't that many high priority WUs available at any given scheduler request to create that much of a slow down in the project. I would be surprised if it ever got to 50%. By removing the 20% rule, you will be achieving your goal of having the faster machines run the high-priority work because there will be a greater chance of having one available at each request.

But I'll execute whatever is sent. Kevin is in charge of distribution and whatever works for him, works for me.

Happy Crunching my friend....

Paul

I have assumed that the 3 have been created and probably already sent out as non-priority, but too soon to have been returned.

For the 6 from generation 001, I have considered them as outstanding but because there had been 6 days already for them to be returned I presume that for some reason (?) they had not been sent out.

Mike