According to knread, they are treating 5 generations as 'normal'. As we are now into 082, that would be generations 078 - 082. 077 is therefore now 'priority'.

I haven't seen an 081 or 082 yet.

Mike

I'm crunching an 049 right now. Specifically, ARP1_0010193_049.

Just noticed that I was sent ARP1_0001951_083_1 at 18:30 UTC on 29th July...

Cheers - Al.

A few updates. First the latest distribution of the units:

count    generation 
-------- ---------- 
6        001        
...
3        035        
2        036        
0        037        
0        038        
1        039        
4        040        
7        041        
5        042        
4        043        
7        044        
7        045        
5        046        
6        047        
6        048        
4        049        
8        050        
7        051        
6        052        
7        053        
12       054        
11       055        
6        056        
8        057        
13       058        
11       059        
10       060        
9        061        
15       062        
7        063        
9        064        
14       065        
18       066        
19       067        
13       068        
25       069        
15       070        
22       071        
17       072        
36       073        
63       074        
186      075        
798      076        
3067     077        
7002     078        
9564     079        
7895     080        
4665     081        
1745     082        
236      083        
3        084        

As noted on Monday we had about 2500 results (~1250 units) that were waiting to be assigned. We were able to recruit a little more firepower and by mid-day yesterday the backlog dropped to running between 0 to 200. As a result, for the first time in a long time we were able to have all the work assigned and in progress which is an important part of making the project run as quickly as possible.

I've been reworking a few things on the backend and from the time that a unit is validated, it will take about 15 minutes before then next generation is out running so the delays are also minimized on the server side (previous when we had a backlog, this turnaround time didn't matter as much so it was as long as 6 hours, but now getting the next generation out as quick as possible is worthwhile).

We are averaging about 8000 units/day right now (we the last two days being above that average). If this pace continues, then we will be completing a generation about every 4.5 days.

Thanks to everyone contributing and we really appreciate the help in getting this running quickly.

Kevin,

Thanks very much for the update. I hope you will be able to re-post the "generation" table every once in a while. It gives us incentive.

I too have been watching Mike's posts on the "end date". Of course that isn't really an end date but a date when the last generation gets sent out and we can assume declining project resource need shortly after that.

I am curious if you why those 6 are still on generation 1. The sequential aspect to this project on any one piece of land mean there are limits to how fast we can get the last work unit for the project completed.

These laggards are only given to "reliable hosts" which I believe is defined as returning results within 2.0 days. We also know that the average high priority WU turnaround time is 1.7 days. Since two valid results need to be submitted before advancing to the next generation, I am assuming the "laggard interval time" will be about 2 days + your 15 minutes to set up the next generation. Assuming there are no "invalid" or no responses from the clients assigned these laggards (I doubt it, but let's assume so) then the earliest the last work unit for the project will be completed is late July 2022.

Other than those 6 stuck on one, we moved the end group from generation 32 to generation 35 in 6 days.... or 2 days per generation. Small sample size, I know, but it would match my assumed "laggard interval time" above.

Paul