Today I got a Workunit 962969273 aborted by project. What does that mean?

1. Firefox sees the broken certificate and takes what action it can to work round it;
   
2. the MW web server and whatever server(s) BOINC (and openssl) are hitting are actually returning different certificate chains!
   

Again, thanks for your efforts, but I don't think there's really any point in my pursuing this any further -- I'm not going to start digging with a network monitor, as I'm not that bothered :-) -- we've all combined to identify and report the problem, and it will probably be sorted out on Monday!

Cheers - Al.

It's not a patch. The cert store holds certificates that you trust.

Web browsers come by default with many trusted root certificates. Which is why your browser isn't complaining about the new site.

Back to the problem at hand: I see that the certificate issues are fairly well documented in this thread by now :-) -- if your security folks are saying there's nothing wrong [because it works for Windows and for browsers on Linux] please inform them otherwise :-)

Cheers - Al.

P.S. I will not be patching my certificate store :-)

I have contacted them and linked them this thread as well. If they don't get back to me today then I'm afraid it will have to wait until Monday.
I will try and fix other issues not related with the certification issue while I wait for their response.

P.S. I note that the new master URL has -new added, but the web site doesn't -- is that the long-term plan or will the master URL end up changing back to not having -new in it?

milkyway-new.cs.rpi.edu is the master address but using just milkyway.cs.rpi.edu will also reach milkyway-new. This is the way the security team here at RPI set it up.

Thu 02 Nov 2023 20:54:23 GMT | http://milkyway-new.cs.rpi.edu/milkyway/ | [http] [ID#1] Info:  TLSv1.2 (OUT), TLS header, Unknown (21):
Thu 02 Nov 2023 20:54:23 GMT | http://milkyway-new.cs.rpi.edu/milkyway/ | [http] [ID#1] Info:  TLSv1.3 (OUT), TLS alert, unknown CA (560):
Thu 02 Nov 2023 20:54:23 GMT | http://milkyway-new.cs.rpi.edu/milkyway/ | [http] [ID#1] Info:  SSL certificate problem: unable to get local issuer certificate
Thu 02 Nov 2023 20:54:23 GMT | http://milkyway-new.cs.rpi.edu/milkyway/ | [http] [ID#1] Info:  Closing connection 16
Thu 02 Nov 2023 20:54:23 GMT | http://milkyway-new.cs.rpi.edu/milkyway/ | [http] HTTP error: SSL peer certificate or SSH remote key was not OK

it's not 64-bit but it is science work :-)

According to this post "BRP7 requires and uses fp64 / double precision in some kernels". And according to this, it's not just a small part of the computation.

The nthreads parameter is ONLY for MT tasks. It sets the maximum number of threads per task to use. For the OP who wanted to run on 15 threads total for the host, that works out as 3 tasks in total using 5 threads each.
You can drop the ncpus value entirely as it is ignored by the nthreads parameter setting.

<app_config>
  <app_version>
    <app_name>milkyway_nbody</app_name>
    <plan_class>mt</plan_class>
    <avg_ncpus>3</avg_ncpus>
    <cmdline>--nthreads 3</cmdline>
  </app_version>
  <project_max_concurrent>2</project_max_concurrent>

Al, "instructions retired per second" is the secret sauce that makes this work so well. I had taken your word for it before and have all my computers running 3-thread nbodys. Thanks much for doing this useful work and explaining it so thoroughly.

I once tried to install PERF to measure instructions retired but it gave me four ways to install it and I didn't get it working. It's the only Linux program I've ever seen suggest multiple ways to install.

CPDN has issued a slug of WAH but it's windoze only. Their new guy is planning on putting out much OpenIFS for Linux this fall:
https://www.cpdn.org/forum_thread.php?id=9149&postid=69160#69160

"PERF" as in Ithena Measurements Perf tasks? If so it's like any other Boinc project you choose what kind of tasks you want to run, Perf is for Windows only while Ooni tasks are Linux only and the Cnode tasks are for both I think. There is also a Project Ithena computation that has Hex tasks https://comp.ithena.net/usr/

"PERF" as in Ithena Measurements Perf tasks? If so it's like any other Boinc project you choose what kind of tasks you want to run, Perf is for Windows only while Ooni tasks are Linux only and the Cnode tasks are for both I think. There is also a Project Ithena computation that has Hex tasks https://comp.ithena.net/usr/

• Initial wingman aborted it about 90 minutes after receiving it;
  
• your task (922770178) returned and waited (reporting either Validation Inconclusive or, perhaps¹, Pending Validation until the _2 task returned);
  
• the _2 task returned and didn't match well with yours when validated (definitely Inconclusive now!);
  
• a _3 task was sent out and returned - it was a good enough match to _2 that _2 and _3 were declared valid and yours was rejected.
  

I note that it has marked your task as Validate error; many projects use that tag for tasks whose results the validator can't understand well enough to attempt validation at all², marking basic failures to match as Invalid. There didn't seem to be anything blatantly wrong with what your task returned (though it was a long way off the results for the two that validated), so I guess MW uses that label for all types of validation failure...

I note also that you have a small number of other N-body tasks that got Validate errors (with the same sort of mismatch of results...) I wonder if that has something to do with your allowing 15 CPU threads and the system sometimes losing [partial] track of what it's doing (for instance, a missed thread synchronization might do that...) It's unlikely to be a hardware issue -- I run a similar system (but under Linux) and it has never had an N-body task that failed to validate (at 3 threads per task and only 11 or 12 threads allowed to BOINC in total...)

I've also read your messages about N-body in other threads, and note the advice shared there -- hope you can get it sorted out properly soon!

Cheers - Al.

¹ If it decides your task is a candidate for validation without a matching wingman but the validator decides to disagree it should be tagged Inconclusive at once, whereas if it has already decided you need a wingman before the validator gets a look in it should be tagged Pending. MW has a strange validator, so it may not always do what might be expected :-)

² For example, WCG tags mismatched validations as "Invalid" and results the validator can't understand as "Error" (making them indistinguishable from any other sort of error) whilst Einstein tags mismatched validations as "Completed, marked as invalid" and results the validator can't understand as "Validation Error" -- there is enough information passed between the validator and the database to tell the two cases apart but the web interface has to bother to pay attention...

I found that there was a slight degradation for each thread up to three or four, then it went downhill quite fast -- while I was working out an optimum for one of my systems, I found 2 three-thread tasks worked the CPUs harder than 1 six-thread task did

How do you define "works harder?"

And what CPU did you test this on? TIA

Is n-body a legitimate multi-CPU project or is it just multiple WUs in one package?

Does n-body use all allocated CPUs for the entire run?

Or does it start using all CPUs and then as parts finish CPUs go idle and wasted until there's just one left running at the end?

This is exactly where I wish Richard Hassellgrove and his group of software testers could get with the different Projects and get some basic across the Projects tech support, probably not free though, to help with things like this. Einstein for example has Mac apps for all the different versions from a Cheese Grater Mac to the new M2 cpu. Maybe they could even provide their apps, admin to admin, and let MilkyWay for example work on changing it so it works here.