No issues on Win10 or Debian Linux boxes on older or newer CPUs.

Win10
Virtual memory size: 192 MB
Working set size: 194 MB

Linux
Virtual memory size: 168 MB
Working set size: 110 MB

Out of curiosity where do you see how many steps a task has done? I can only find where it says how many docking's have been completed. In case it makes a difference I am running Windows 10 64 bit Thanks in advance

Hey Speedy51, good to see you around, hope you're well. What I did is I watched the progress bar, and noted when it increased the progress percentage. I don't know how many calculations or dockings are being completed for the boinc manager to decide "yep, it's time to increase the progress percentage". But since I run at pretty stable all-core boost frequencies, 24/7, it should take about the same amount of time if the same number of calculations are being done. At least in theory. I saw very regular periods of time between increments of progress, so it seems like its roughly the same number of calculations or dockings per increment of progress. So, I called that progress a "step". So, a task with 200 "steps", the progress percentage will increase 200 times over the course of the unit, and since it is very regular, that can also allow you to estimate the time to completion. There's probably a better word for it, so if someone could enlighten me, I'll use the clearer one

Since it looks like the devs are still looking for data, I'll put down the glut of information I was able to take down. All the machines below are running Linux Mint, latest updated versions (none of my windows machines have caught any yet). Numbers are: workunit name after the "TEST" part, Virtual Memory, and Working Set Size memory usage in MB. Then in parentheses, I will denote whether it was an estimated short (under 1 hr), medium (1-7.9 hrs), or long (8+ hrs) running unit.

Dual epyc 7301 system, 64 gig ram, 64 concurrent threads:
002_0021: 168.25 /66.30 (short)
002_1248: 168.25 / 94.96 (short)
002_0132: 178.85 / 113.94 (short)
002_0143: 178.85 / 104.46 (short)
002_1105: 178.85 / 109.19 (short)
002_0018: 178.91 / 112.82 (medium)
003_0171: 178.85 / 113.94 (medium)
002_1106: 178.85 / 113.65 (long)
003_1412: 168.25 / 104.53 (long)
003_0149: 168.37 / 104.59 (long)
Other notes: I suspended all my tasks, ran all the COVID-19 betas at once (about 20 of them), and then immediately after running all the betas, resumed my other tasks. I did not observe a major change in performance like if I ran a bunch of MIP1 tasks at once, or ran all ARP1 tasks at once, so I'm not seeing enough L3 cache use to cause a knock-on effect.

Ryzen 7 1700 system, 16 gig ram, 16 concurrent threads:
003_1199: 179.02 / 114.27 (medium)
Other notes: about a 34 second "step" time

Ryzen 5 3600 system, 16 gig ram, 12 concurrent threads:
I wasn't able to access and take down the information in time before the unit finished. It only lasted 46 seconds. Finished fine though.

Final ranges for VSM: 168.25 - 182.85
Final ranges for WSS: 66.30 - 116.88
I didn't see much of a correlation between VSM and WSS usage, except that in very, very short units (under 2 minutes), there were some that had numbers on the lower edge of the range. But some very short units had memory figures in line with medium or long units, so the correlation between VSM and WSS and the length of the unit is pretty weak.

4 of my 5 Android tasks are marked as invalid, the other one is still pending verification.

Pete

Got 2 on XP 32 bit, both failed as below:

Result Name: BETA_ OPN1_ TEST002_ 1112_ 0--
<core_client_version>7.14.2</core_client_version>
<![CDATA[
<message>
couldn't start app: CreateProcess() failed - (unknown error)</message>
]]>

May be able to patch the app as before.

Paul.