Hi Sergei,

I've noticed that workunits are usually generated in groups of 1000, with the last digits of the workunit name indicating which workunit of that particular batch it is. A while ago I also noticed that there are groups of ranges tested twice, where the last digits in the workunit name are not in numerical order and the workunits not generated in batches of 1000. Just curious what the additional workunits are for, as it appears to test the same range as the sequentially generated workunits.

Here is an example of some workunits with the same range tested;
Normal, sequentially-generated workunit: https://sech.me/boinc/Amicable/workunit.php?wuid=10971671
Workunit generated out of sequence that tests the same range: https://sech.me/boinc/Amicable/workunit.php?wuid=10971468
Another workunit generated out of sequence that tests the same range: https://sech.me/boinc/Amicable/workunit.php?wuid=10971256

I have also noticed that the workunits generated out of sequence are not all generated at the same time like the sequential workunits, but instead they are gradually generated between the batches of 1000 sequential workunits.

Thank you,
Kellen

Yes, it sends smaller batches to CharityEngine's computers because they're mostly unstable/unreliable. But it shouldn't send repeating tasks, I'll look into it.

Edit: yes, there was a bug in the code. I forgot to move the batch from "unsent" to "sent" folder in this case. Thanks for noticing! But anyway, it didn't go completely to waste because it provided some more redundancy in the search up to this point.

Great! Thanks for the quick reply! I was wondering why all of the computers crunching those tasks were owned by "Anonymous". I just took a bit of a closer look and it seems as though batches of 100 workunits are generated, starting from where the large sequential batch of 1000 workunits ended, and repeated small batches are generated over that same range. Then, the next sequential batch of 1000 is generated from the end range of the previous one. Something else to note is that the /task_size parameter is different even when the same range is tested.

Regards,
Kellen

Nice! Glad to see it was an easy fix! That should more than double the speed of the rest of the search to 1.0E20.

Thanks again for the very fast replies!

Regards,
Kellen

Yes, it should move faster now, maybe 10²⁰ will even finish before the end of this summer.