Hello everyone,

We've generated some new work, and while I was at it, I implemented the plan class changes I alluded to in discussion with a few users who were trying to use Windows 7 to run xoroshigo.

Python does not support Windows 7 anymore, hasn't since Python 3.8 back in 2018. 3.9 made breaking changes for Windows 7 and will not run on Windows 7.

To remedy the issue, we've implemented "win-modern" and "lin-modern" as plan classes we can use if our apps won't run on older OSes.

Put simply, on linux if your GLIBC is older than 2.27, you won't get work for xoroshigo2 (or any other app that requires lin-modern - which is likely to be all of our work in the future.)
On Windows, your windows version must be 8.1 or higher.

Let us know if you run into any issues running our apps. Happy crunching!

Thanks for the new apps. Should reduce the error rate from older hosts. Running some lin-modern now already with no issues.

Is this new app making WUs run 10x longer?

Is this new app making WUs run 10x longer?

Don't know. We never saw this on the earlier apps. Developer said he tested the app for the first 50 confguration files and saw no issues. But the latest configuration files are screwing the app up or something.

Hey Keith,

I’ll write up an explainer tonight about what happened and what we’re working on to try to correct it.

The short answer though is that we did not anticipate these workunits to run as long as they are and I’ve been hard at work for much of the day analyzing and diagnosing it.

I hope to have a solid fix in place tonight or tomorrow, but I’ll still write up a more detailed post tonight regardless.

Thanks for the progress update. Hope it gets resolved soonest.

So the gist of the issue:

Some of the new configuration files produce situations where the function with most of the runtime no longer has most of the runtime.
This reveals room for optimization as another function we had not created a native implementation for yet is now consuming most of the runtime.

We've been working on this new implementation of that function, which has necessitated a re-implementation of the RNG used by numpy, and we're getting results that are close to original. Not perfect, but close.

The efforts I've put in so far have netted a 6.6x runtime improvement for the worst-case config file I tested for 1 million iterations. But, again, it's not quite ready to release because of the inaccuracy I mentioned before.

Once we decide whether we're satisfied with "close enough", or we find the bug in the implementation we've written that is causing the inaccuracy, we'll be ready to push this out to the wider BOINC project and hopefully address the runtime discrepancy for everyone.

Any reason why some v1.04 tasks are taking 5-20x longer than previously? Previous avg runtime was about 2hrs. See e.g. https://minecraftathome.com/minecrafthome/workunit.php?wuid=7371217. I have another task that's about 22hrs in with 14hrs remaining. I don't want to abort these extra-long tasks, but with constant-credit I feel like I'm getting the short end of the stick here.

---