According to ....generations.txt there were 22 extreme units validated in the last 24 hours, averaging 20 hours to complete.

Mike

Mike, could you explain what the file state.txt is trying to make clear?

+--------------+----------------+-------------+
| number_units | max_generation | type        |
+--------------+----------------+-------------+
|           23 | 132            | Accelerated |
|           38 | 127            | Extreme     |
|        29125 | 142            | Normal      |
+--------------+----------------+-------------+

You say: "There are 38 Extremes and there are 1465 in their generations". When I count the number of Extremes in generations.txt, they (1+1+1+2+1+2+2+4+2+2+7+2+2+4+3+4+1+5+4+2+9+4+1+4+5+2+3+7+20+96+519+743) add(ed) up to 1465 (yesterday). What is that number of 38 then?

Mike, Adri;

Firstly, regarding the counts given in state,txt -- up until 31st October 2022 (inclusive) the counts seemed to include every grid cell, whereas from 1st November onwards the counts now only sum to 29186...

On 31st October 2022 state.txt was as follows

+--------------+----------------+-------------+
| number_units | max_generation | type        |
+--------------+----------------+-------------+
|          102 | 124            | Extreme     |
|          168 | 130            | Accelerated |
|        35339 | 140            | Normal      |
+--------------+----------------+-------------+

whilst on 1st November it was as follows

+--------------+----------------+-------------+
| number_units | max_generation | type        |
+--------------+----------------+-------------+
|           47 | 124            | Extreme     |
|           20 | 130            | Accelerated |
|        29119 | 140            | Normal      |
+--------------+----------------+-------------+

with 6423 cells no longer included.

It doesn't directly answer the question as to what is being counted, but(assuming that some aspects of the generation management take place on the non-BOINC database) it suggests that there may be some issue in the connection between the two databases, as often mentioned in web-site related contexts. It would be interesting to see the queries used to generate the three reports [for a user-based forensic effort] , but I don't think we're likely to get lucky in that matter :-)

And on that note, Mike remarked
I rather suspect that as far as Igor's team are concerned this is part of the "IBM set it up and we're leaving it alone unless it is an obvious source of system failure" section which will [slowly] get resolved as they sort out the more critical aspects of the inter-database communication problems. I wonder how much of the stuff that worked fine in an all-IBM environment was taken for granted when documenting systems; do we know how much worthwhile documentation was provided? Mike's "blind leading the blind" assessment may be nearer the truth than one might hope would be the case...

----

On the subject of Adri's one-off work unit -- do we officially know that the work generation for each category is effectively separated out? There's plenty of evidence in the current generation shifts and average completion times to suggest that there's a constant [but small] trickle of Extreme units and that the same may be true for Accelerated units...

I actually looked at the work units surrounding Adri's oddity - there was one other ARP1 unit there, and everything else appeared to be MCM1. Given the reasonably swift turn-around being reported for Extremes at present, it must happen once or twice a day -- perhaps it's regulated by the number of units that actually get assimilated and purged on a given day?

The above may also apply to Accelerated cells, but it would appear that Normal cells may not get another batch issued until all stragglers from the last batch have returned. If anyone can tell us what the real situation is regarding triggers for new work, I'd love to know!

If there is actually a trickle of work going out for those categories the odds against any of the regular ARP1 posters getting one would be pretty remote, I suspect -- sorry, unixchick :-( -- so we'd be none the wiser about the new work...

Cheers - Al.

I noticed when units started to flow a couple of weeks ago that they were releasing in generation order starting with 134, then 135 next day, then 136, etc.
I guess it was their way of staggering the flow. I doubt they were being returned that quickly.

Mike

I think when ARP ran into trouble and things weren't working for them, they had a tech at IBM to help them. They reformulated the WUs to be more granular and restarted them from a certain generation, or started them all over. I'm guessing they don't have that level of expertise or attention anymore. They might have to abandon the difficult areas.

We know that ARP has had a drive/tape space issue, so they might not have had time to look at the difficult WUs to manage them. I hope they can restart/rewind the ones that need that once the holidays are done, and they have the time to do that.