Config option to set worker cap

[maximmasiutin]

Fixes #1635

Added config option to set number of games cap of a single task for a worker.

There is a fishtest.ini config file at ~/.

[worker]
GamesCap = 100

This file and this GamesCap parameter is not mandatory. By default (if not GamesCap parameter is specified in the config), it is set to 9000 games per task. I.e. the tasks larger than 9000 games will be limited to 9000 games. However, if you set GamesCap for example to 100, then the largest batch a worker will receive is 100.

This option is configured on the server, not on the worker.

[Sopel97]

what's the motivation for this feature

edit. ultimately, there's no best way to distribute work among the tasks, but what we have right now works well on fishtest, so why change that?

[maximmasiutin]

1. Whenever you wish to change that on tests.stockfishchess.org, you would not need to modify the source code;
2. Different instances of fishtest would not need the code to be modified; what works well on tests.stockfishchess.org might not work well on other instances, as explained in Bug in batch size calculation introduced recently: when there are many workers but few tasks, the task is not properly split between the workers which results in idle workers #1635

[maximmasiutin]

You can just set the following in config.ini

[worker]
GamesCap = 3200000

And you will get the current behavior as on tests.stockfishchess.org, but it will be configurable. I already submitted a few pull requests to get rid of hardcoded values such as captcha key or tests.stockfishchess.org URL which are inapplicable for the other instance and are not compatible with https://github.com/glinscott/fishtest/wiki/Fishtest-server-setup

[maximmasiutin]

but what we have right now works well on fishtest,

at https://tests.stockfishchess.org/tests/view/642df05c77ff3301150e87f2 there are workers with 56 cores that got 29616 games each. With TC=150+1.5 it will probably takes 7 days to complete 29616 games. So a computer with 56 cores will be dedicated exclusively to one test for the whole week. For example, if you change priority or throughput, the changes will take place only after 7 days.

Also, why should a worker be so greedy to get 29616 games for the whole week in advance? Cannot it get smaller batches, say, every hour?

[Sopel97]

This looks to me like an issue with how batch size is calculated with respect to the available memory (or for other reasons idk, there seems to be no correlation with how fast the worker gets through these games and the actual batch size), not with the absolute limit on the batch size.

[Sopel97]

https://github.com/glinscott/fishtest/blob/68faa547232ad9a99f4a8d5acf13f216a744f0c3/server/fishtest/rundb.py#L668

This should not use the number of tasks, because as we can see for the test you linked empty tasks count the same as tasks with thousands of games. The logic is just flawed.

[vdbergh]

The reason for this scaling is that mongodb documents have a size upperbound, which was hit in the past. So one wants to limit the total number of tasks, not the total number of games.