Two Beta WUs completed so far, both in just under 3 hours on an old i3-3220 CPU

I've had a look at the various tasks I've completed so far and have a few notes and questions as a result...

The first thing I noticed was that while these BETAs were running all my other tasks were running about 10% slower. At first I put it down to the possibility that this version of MAM1 is a heavier memory user than (say) MCM1, as the more ARP1 I run, the slower both ARP1 and MCM1 get. However, perhaps not (see later)...

There's significant differences in CPU time across tasks on a single client; the faster of my two systems that got BETA tasks had a range from 45 minutes to 10.5 hours and the slower system from about 55 minutes to over 14 hours! Is that just down to the RandomSeed value or is there some other influence that isn't visible?

I also saw one task that seemed to take 4 hours to get up to 1% then only took another 5 hours to finish -- I presume there are two or more distinct phases to a task and that the first stage doesn't show up much on the progress percentage. It might be that some of the other long-running tasks did the same sort of thing, but that's the only one I noticed as I was doing other things as well.

The next thing I noticed was that the results page reports equal CPU and elapsed time (which tends to imply that the elapsed time was lower than CPU time if BOINC thinks a task is single-threaded). Checking the client job log for WCG shows these BETA tasks have a much higher CPU time than elapsed time, and this was reflected if examining a task with perf stat -- typical returns suggested active use of between 1.3 and 1.6 times as much CPU as elapsed time. So on the system I was looking at (with BOINC notionally capped at 75% of CPU threads), running 3 BETA tasks at the same time as a mix of MCM1 and ARP1 actually resulted in needing 14 or 15 "CPUs" instead of 12, with possible power-cap throttling as a result, despite the CPU frequency capping I do to try to avoid that happening!

Part of the possible performance problem is that Linux will keep shifting BOINC task threads from CPU to CPU so a lot of the benefits of L3 cache may be lost, and the more threads, the more shifts! Unfortunately, perf stat doesn't seem to be able to monitor LLC misses on newer Ryzens, so I can't get definite evidence of this unless some Betas turn up on one of my old Intel systems at a time when I can dig into it.

(I also noticed is that each task I looked at in detail seemed to end up with 22 threads(!), most of which didn't clock up enough CPU time to show a non-zero value when examining the threads with ps; what are all those for?)

Other than the above, I have nothing to report as nothing crashed (unlike some Debian wingmen tasks that failed because they couldn't find libgomp -- oops!), but I haven't had a chance to test things like task recovery after suspension or client shut-down (as I wasn't even expecting to see any BETA work yet...)

Looking forward to more testing, I'm calling it a day for now as I've just noticed I've pulled a 24+ hour shift...

Cheers - Al.

A 3rd has finished on the same system as my previous report - this one took 20 hrs 30 mins.

As has been noted by alanb1951, elapsed and cpu time are recorded as identical. In fact is looks very much that they have recorded the the elapsed and cpu times as the time between when the WU was sent by WCG and received back completed, within a few seconds. It has no bearing whatsoever on the real CPU time spend processing This is true for all 3 WUs returned so far.

Edit: improved wording

Corrected. Thanks!

Nothing yet on Windows. But, still looking.