vdbergh
vdbergh
There is little point for two people to work on this. So I closed my PR. Please make a PR.
@xoto10 When the run finishes I would verify that the result of the incremental updates is the same as the result of summing the tasks. Otherwise there is no way...
 There seems to be an error with quantization (170 is not divisible by 8, let alone 32).
Ok it seems the batch size is 6 games (obtained via /api/get_run). 170 is still not divisible by 6.
Not relevant for this issue, but I think currently the maximum number of games must be a multiple of the sprt batch size. This should be fixed.
Ok this last comment seems to explain it somehow as `(800000-170)%6=0`. But one would expect left over games to be assigned in the last task which is not the case...
Ah I see it. Left over games are assigned on the basis of "finished tasks" and "committed games" (computed using the active tasks). Of course the committed games may not...
So it seems the sprt batch size must be set during the creation of the run and num_games must be correspondingly quantized. BTW there should be a corresponding error message...
From this issue we see another problem. Far too many workers are assigned to an sprt run when the fleet arrives since the code assumes that an sprt test will...
This can be closed. It was fixed.