I'm pleased to see that I was in fact wrong about that early WUProp example being ghosts!

Dylan had said he would start a Beta Test thread when they started up again (there isn't one yet), but maybe this was just a soak test for construction, issue, return and validation -- quick impressions here (instead of starting a new thread in the Beta section myself...)

There appear to have been several batches, all deliberately designed for short run times -- out of over 2000 tasks I've seen, only one clocked up enough elapsed time to register anything other than 0/0 for CPU and elapsed hours on the web site!

Not a single download error (mine or wingman's) reported, and only 12 other Errors amongst the wingmen -- 4 were SIGILL failures and 8 couldn't find a viable GLIBC -- that is a nice low failure rate!

Validation seems to be enabled (good to see, as it's a second critical check), but I think that happened fairly late on 2025-12-17 (their time, not UTC!) because neither the BETA Testing History nor my monitoring programs picked up any validated tasks early on 2025-12-18 (UTC). However, a later check showed 18% of my tasks had Validated, 14.5% waiting for a wingman to return and the other 67.5% in PVal jail!

It will be more interesting if/when some more substantial tasks are issued -- these are so quick that I don't think my limiting of threads to 2 for the BETA tasks would make a significant difference to runtime -- I just hope we get warned before they're sent out so that those of us with such limits can adjust them if we want to!

Cheers - Al.

Adri -- I suspect something like that might still be a good idea.

This version of the Mapping application doesn't declare its command line in the stderr file, and as my mass of Beta tests (about which I was still building that post when your post landed) all arrived and went away while I was in no position to look at what got downloaded to see what the command line looked like, so I don't know if they offer up a default value for nthreads -- judging by the debug information in the stderr log, I suspect not (and there's nothing relevant in the config.ini file...)

All my app_config files for WCG have something similar to yours, except that I have values higher than 1 for max_concurrent on all my Ryzens as they have enough "CPUs" to cope.

If we get to find out about the next tranche of BETA WUs before they land, some careful testing can be arranged -- I seem to recall that the previous version set up lots of threads but only made active use of less than 1 or 2 CPU threads no matter what setting was given for nthreads, but this is a later version. At least the debug information gives some idea of what some of the apparently inactive threads might be for!...

By the way, my only other experiences with BOINC multi-threaded tasks are MilkyWay and an early CPDN test batch -- by default, MilkyWay doesn't include nthreads in the command line (but the application respects it if presented via app_config.xml), whereas CPDN currently has a fixed requirement for its large tasks (and I can't/won't run them on my systems because of their memory footprint!).

Cheers - Al.

Thanks for all the MAM reports. I doubt I'll ever see a MAM WU on my mac, so I really need all the reports to understand the status.

edit to add some personal stats:
My results total:2900
pending:848

You received an app for MAM? What is the version?
Anyone else receive a MAM app?

Nice! Well, we are fully shut down for the holiday starting tomorrow, so that is not great timing on our part. Oh well!

I will be able to accurately track validation progress since we will not be completing any new work for two weeks.

I think January has the potential to be great for WCG if this beta goes well. We (Boca Raton HS) also have some exciting new hardware arriving in January, so lots to look forward to for our students. They just completed presentations in class about the projects on WCG so they are excited to see improvements in WCG as well.

As always, thank you to everyone here for your support and advice!