Recent Changes in projects

[StefanR5R]

Asteroids@home

No Asteroids last week, for anybody. :-|

This downtime will apparently last until September or October.
Source: project site

 

[Fardringle]

Minecraft@home now has a CPU project. The Minecraft GPU project has always (in my experience) been very inefficient and pretty much not worth running except to get another stats milestone.

However, the CPU project looks like it will be VERY good for credit rewards.

I've only done a small amount of testing on a secondary computer so far, but the results are interesting.

Quadro K2200 GPU averages about 3.2 hours per task. Credits range from around 2400 to 3100 per task. The Quadro is a temporary (had it in a desk drawer at work) replacement for a GTX 750ti that died recently. The 750ti was averaging about 2.9 hours per task for the same credit range. Approximately 25K credits per day.

Intel i7-4790 (not K) averages about 2.4 hours per single thread task, running 6 tasks simultaneously and leaving 2 threads for the GPU. Credits are locked at 2500 per task. Approximately 25K per day per CPU thread, based on a few hours of testing. And that's on a 7-year-old CPU. I have a feeling they won't leave the credits that high for very long. That's even more credits than Universe@home gives.

RAM usage is almost nonexistent. GPU tasks use about 60MB of RAM, and CPU tasks use 1.3MB per task.

When I'm in the mood, I'll test the apps on my GTX 1060 and Ryzen 9 3900X as well to see how they compare. The computer that is running it now is the one that my girls use to play Minecraft so it seemed appropriate.

edit:
The GTX 1060 is averaging around 55 minutes per task and the Ryzen 9 3900X is averaging around 2 hours and 1 minute per task. That puts the GPU estimate around 78.5K per day (lame) and the CPU at about 30K per day per CPU thread, so somewhere around 660K per day running 22 tasks. That's pretty silly for a CPU project, but I just might have to run it for a while to boost my stats milestone in the project - at least until they drop the credits down to a reasonable number...

Definitely moving the GPUs to different projects, though!


On a side note, one of the project devs has been doing their development and testing on a Pi 4 and it is averaging around 4 hours per task, so if you have any lonely/lazy Pi 4 boards lying around, they could score around 40K per day (10K per core).

 

[StefanR5R]

World Community Grid
You may have seen it in your boinc notices:
IBM is handing the operation of WCG over to a Toronto based research institute.
According to the announcement, the way how WCG works (not just hosting of projects, but I presume also the curating of the projects) is supposed to stay the same. There is no explanation for why IBM is withdrawing (if I may call it this way).

World Community Grid finds a new home at Krembil Research Institute

 

[StefanR5R]

The WCG web pages look rather different now. I just discovered it, therefore haven't looked around enough to make up my mind if for the better or worse.

Edit:
So far the changes seem to be cosmetic, not about functionality. The personal "history", "devices" and "results" pages now have a button with which you can download these tables in CSV format. Is this new?

The change must have been made already early in the past week. At least that's what the dates of the inevitable complaints in the WCG forum are indicating.

 

[StefanR5R]

NFS@Home
The project URL was switched to HTTPS, i.e. it changed from http://escatter11.fullerton.edu/nfs/ to https://escatter11.fullerton.edu/nfs/.

Out of curiosity, I hit 'update' on NFS on a computer which has the old URL (while the project is at 'no new work'), and got this message in the client log:

You are attached to this project twice. Please remove projects named NFS@Home, then add https://escatter11.fullerton.edu/nfs/

Well, the computer is not attached twice. Anyway, moral of the story: Before the next time one wants to run NFS@Home, it has to be removed from the client, then re-attached.

I haven't looked up what happens if you are actively running NFS right now. The proper cause of action would certainly be to set it to 'no new work' right away, wait until all tasks are completed and reported, then remove and re-attach.

 

[Skivelitis2]

I'm currently running NFS for WUProp hour purposes (nothing to do with FB sprint) until the WCG challenge. I am getting the " using an old url ...Please detach/reattach when convenient" message.

Edit: My bad.....thought a sprint for this project may have started!

 

[StefanR5R]

GPUGrid
had issues with an outdated SSL certificate, but as far as I can tell they have resolved it now.

 

[StefanR5R]

CPDN
published a modest batch of Linux work ("UK Met Office HadAM4 at N144 resolution") a couple of days ago. Also, next week some Windows work may become available.
(source)

 

[StefanR5R]

PrimeGrid Generalized Fermat Prime Search subprojects (GFN)

cpuGFN20: updated from Genefer 3.3.4 to Genefer 3.3.5
cpuGFN19: updated from Genefer 3.3.4 to Genefer 3.3.5
cpuGFN18: updated from Genefer 3.3.4 to Genefer 3.3.5
cpuGFN17MEGA: new; based on Genefer 3.3.5
cpuGFN17LOW: updated from Genefer 3.3.4 to Genefer 3.3.5
cpuGFN16: new; based on Genefer 3.3.5

• 
  [
• All of these applications are singlethreaded.

In May 2022, multithreaded application versions have been added: cpuGFN16_mt, cpuGFN17MEGA_mt, cpuGFN18_mt, cpuGFN19_mt, cpuGFN20_mt.

(Genefer-17-Low has been completed by now. cpuGFN21 was updated in May 2022 too, but I don't know in which aspects; it used to support multithreading. There wasn't, isn't, and presumably won't be a CPU-only application for GFN-22 and DYFL.)

 

[Orange Kid]

DENIS@home is back.

DENIS@home

Official web page of the volunteer computing project DENIS@Home. This project is developed using BOINC and maintained by the CoMBA research group at the University San Jorge (Zaragoza, Spain)

denis.usj.es

 

[Icecold]

DENIS@home is back.

DENIS@home

Official web page of the volunteer computing project DENIS@Home. This project is developed using BOINC and maintained by the CoMBA research group at the University San Jorge (Zaragoza, Spain)

denis.usj.es

If anybody has any issues registering, try registering through BOINC Manager (not BOINC Tasks). The website registration gives an error that it wants you to consent to a checkbox that doesn't exist, and adding through BOINC Tasks doesn't work either, but it does through BOINC Manager. @Kiska tracked down the solution for this.

 

[cellarnoise]

Looks like a great project!

I've never ran it before, but will this fall.

 

[Fardringle]

If anybody has any issues registering, try registering through BOINC Manager (not BOINC Tasks). The website registration gives an error that it wants you to consent to a checkbox that doesn't exist, and adding through BOINC Tasks doesn't work either, but it does through BOINC Manager. @Kiska tracked down the solution for this.

For clarification, you can add computers to the project in BOINC Tasks. You just can't create a new account from there.

 

[TennesseeTony]

Don't forget to tell DENIS to allow exporting of stats...

 

[StefanR5R]

PrimeGrid Generalized Fermat Prime Search subprojects (GFN)

A major application update has been installed for GFN-18:

• Self-tests and proof tasks have been implemented, very similar to LLR2.
• The transform was generalized to one which is able to cover any of the GFN subprojects up to b = 2,000,000,000.

Both of these combined cause main tasks to take a few percent longer on Turing and Ampere GPUs, ≈10% on RDNA GPUs, but ≈1.5 ≈1.28 times as long as before on Pascal GPUs. The latter regression will be investigated, but a quick fix is not on the horizon. There is however a large uplift in overall project throughput, because the "fast proof tasks" replaced the "double-checker tasks".
(source)

If this application update works well, it will apparently be rolled out to GFN-19, -20, -21, -22, and -DYFL too, but maybe not to GFN-15, -16, and -17 Mega due to their generally shorter tasks versus the server-side overhead of the fast proof infrastructure.
(source, in German)

I take this opportunity to complain about PrimeGrid's poor communications habits. They rarely use their message board for announcements anymore. Well, at least they still stick around there for explanations after the fact.

 

[StefanR5R]

PS:

The transform was generalized to one which is able to cover any of the GFN subprojects up to b = 2,000,000,000.

This is only true for the GPU implementation. The CPU-only counterpart has got lower limits:

On CPU, the limit is fuzzy and is b ~ 500M (n = 12), 380M (n = 13), 300M (n = 14), 230M (n = 15), 170M (n = 16), 130M (n = 17), 95M (n = 18), 70M (n = 19), 55M (n = 20), 45M (n = 21), 35M (n = 22), 25M (n = 23).

(source – pun not intended)

Currently, the CPU-only version can therefore be used on GFN-17 Mega, GFN-18…-22, and on GFN-DYFL, but is past its b limit on GFN-15 and GFN-16. (It seems already somewhat close to the limit at GFN-17 Mega, but there is ample headroom still at the larger GFNs.)
(source)

Edit:
Genefer 17 Mega was switched to version 4.01 with fast proofs too now.

 

[StefanR5R]

GFN-19, GFN-20 and GFN-21 were switched to application version 4.01 (genefer22) two days ago.
GFN-22 was switched to 4.01 today.

FP64 capable GPUs are therefore slower now at both GFN-21 (which could use FP64 for random parts of current workunits) and GFN-22 (which could use FP64 for the entire workunit until now).

GFN-DYFL is still at version 3.21, but my guess is that this one will be switched soon too.

Edit:
Before the switch, GFN-22 was for GPUs only. Now both a GPU application version and a multithreaded CPU-only application version are provided.

 

[Skillz]

Dang, so now GFN-22 wont benefit from FP64? Crap-o-la