It appears Kevin needs to let Willy @ BAM! know what the correct URL is because it's not pointing to it.

I posted to the thread in the number crunching but apparently that info hasn't been relayed over...

19-Jun-2023 17:08:24 [Milkyway@Home] Scheduler request completed: got 71 new tasks
20-Jun-2023 22:08:15 [Milkyway@Home] Scheduler request completed: got 89 new tasks
20-Jun-2023 22:15:56 [Milkyway@Home] Scheduler request completed: got 232 new tasks

I've cancelled all of the bad workunits from the job pool. Hopefully you should see them disappear from your machines shortly.

Any particular reason these runs are bundled in 4s rather than 5s?

They appear to have 26 parameters instead of 20 in the previous tasks. And, judging by the elapsed time for these new tasks on my GPU it looks as if 4*26 parameters takes about the same time as 5*20 (!)

Obviously, this consistency of run time would be more significant for folks running CPU tasks - an increase of about 25% CPU time (likely with 5 per batch) might not go down quite so well there!...

Our project has been running for upwards of 10 years now and we have been crunching literally billions of workunits over those years. As a result of all of your hard work and dedication, we have actually calculated enough results that we have run out of room to store the IDs of all of these results in a normal unsigned integer value (the default data type used for storing IDs in BOINC databases). As a result, on Tuesday night, I updated our database to be able to store IDs in a much larger data type to prevent this issue from happening again during the remaining life of the project. As a result, I also had to quickly patch the BOINC code we run on the server to allow it to use this newly available data type in the database.