I'll go to a project that has an open source code for Nvidia GPUS and an off-line test suite similar to Seti@home.

Hey! I'm sure your optimizations will be greatly welcomed!!

To follow my own interests: Go Einstein@Home? ;-)


Keep searchin',
Martin

I'm still convinced that somehow, whether it be intent or just net result, the higher your RAC is the lower you are in the priority stack in terms of actually getting work during a recovery from outage. This is entirely too consistent to be the luck of the draw.

It could be my "Seti Toaster"

To win a SETI Toaster you need to crunch at least 1 Billion credits. LOL

. . I don't think my current toaster will last that long :(

Stephen

:)

Well the leaks are out about the NVIDIA RTX 3070/3080

Now to see how long before they are officially out on the web.

Cheers

OK, I've applied Retvari's workround on my Linux Mint host running special sauce and the spoofed client. There's good news and bad news.

Good news (1): It's running
Good news (2): It's picking up the command line. -nobs isn't specifically acknowledged, but I've got an -unroll in there too, and that's reported.

Bad news: It's not received the instruction to run on device 0 / device 1

The device number is being passed correctly in init_data.xml, but the special sauce app isn't looking in the right place. I see Petri's app_info.xml doesn't contain an API version specifier, and it worked before, so I assume it's only listening for a command line. That's ancient, and should be corrected. Petri needs to compile against a newer BOINC API library and make the appropriate coding adjustments.

But at least my machine is running 2-up on device 0 - so at about half normal speed - and some warmth is creeping back into my workroom.

...
    // Patch for Cuda device selection, Care of Juha Sointusalo.
    // Deals with boinc api 7.5 onwards breaking change (mid major version),
    // from standard use of command line to field not present on preferred earlier versions.
    // init_data.xml has e.g. <gpu_device_num>0</gpu_device_num>
#define BOINC_MAJOR_VERSION 8 
#if (BOINC_MAJOR_VERSION >= 8) || ((BOINC_MAJOR_VERSION == 7) && (BOINC_MINOR_VERSION >= 5))
    if (app_init_data.gpu_device_num >= 0) {
      gCUDADevPref = app_init_data.gpu_device_num + 1;
      fprintf(stderr, "app_init.xml specified GPU %d\r\n", app_init_data.gpu_device_num);
    }
#endif
...

Muchas gracias Juan.
That is exactly what I was looking for.
To save time for everyone who hasn't seen it, I will reprint Richard Hasselgrove's earlier post:

____________________________________________________________________________________
Posted: 23 Dec 2019, 16:55:49 UTC

For general information

I've had a provisional whisper back from the project. As of about an hour ago, the provisional plan is to go through normal maintenance and backup tomorrow (Tuesday), and then revert the database changes so we can go back to running the old server code.

My gloss on that is that it probably means a longer outage, and an even worse than usual recovery, but everyone should be able to enjoy the rest of the holiday in peace. Most especially, the staff can relax. Sounds like a good idea to me.
ID: 2024655 · Report as offensive \
Posted: 23 Dec 2019, 16:55:49 UTC

For general information

I've had a provisional whisper back from the project. As of about an hour ago, the provisional plan is to go through normal maintenance and backup tomorrow (Tuesday), and then revert the database changes so we can go back to running the old server code.

My gloss on that is that it probably means a longer outage, and an even worse than usual recovery, but everyone should be able to enjoy the rest of the holiday in peace. Most especially, the staff can relax. Sounds like a good idea to me.
____________________________________________________________________________________


p.s. Thank you, Richard!

Any oldtimers here remember that one Christmas season that seti was very down... was it a month?? two??

Was that the 1 where it all came crashing down in early December and didn't get fixed until late January, or something like that?

It might actually be a good plan for those of us running Anonymous to set No New Tasks until this gets figured out, in order to quit hammering the servers for those running stock who could actually get some work.
Personally, Einstein is running fine here until it's squared away and I just can't see breaking what works here to work around a far-end issue ... Just a thought.

. . Or you could do what I have done with the machines with no work, turn them off and save on power bills.
Stephen :)

The lack of heat being produced here is very helpful ATM with the very hot and smokey conditions we're experiencing, but I'd imagine that those in the other half of the world would prefer to have the heat on. ;-)

Cheers.

I agree with Z, the hybrids are perfect for crunching. With them you could easily keep the temps within a safe range even on hot & high humidity places like the one i live.

The only problem i have with the hybrids is with their pumps, i had 2 of them fail about 1 per year. They are hard to find here but when changed all return to work fine.

The App is in the All-In-One package at the same location http://www.arkayn.us/lunatics/BOINC.7z
Make sure to read the README_x41p_V0.98.txt file in BOINC/projects/setiathome.berkeley.edu/docs.
The 10.2 App will need driver 440.33 or Higher, Ubuntu 15.04 or Higher, and Pascal or Higher GPU.
The 440.33 driver is available in the CUDA 10.2 ToolKit, you don't need to install the ToolKit, just the driver.
In My experience, the easiest way to install the nVidia Downloaded driver on a fresh Ubuntu install is to first install the highest Repository nVidia driver from Additional Drivers. Then download the 10.2 ToolKit from nVidia, place it in your Home folder, and make sure the Execute bit is set. Next reboot into Recovery Mode and enable Networking. Switch to Root mode, cd to your home folder, then remove the Repository driver by running, apt remove --purge nvidia* and then run, apt autoremove. Next install the Driver by running the installer and setting the options to just install the driver, ./cuda_10.2.89_440.33.01_linux.run
Depending on your HDD it may take a while to read and launch the installer, it's not long if using an SSD. Once the installer is finished, reboot.
It seems to work better the first time if you use the driver installer from the ToolKit, after that, running the downloaded standalone driver should work without any trouble. If the driver fails to work, simply boot back to Recovery mode and remove the downloaded driver by running, nvidia-uninstall
Have fun.

Yea! Just read this. Would have saved me the trouble of building it!!

That would guide the Santa to deliver the right present to the best behaving children and adults who do not like to obey M$ or other rules.

Or better yet port your efforts over to Windows to make more use of all that hardware.

Or maybe we should get a fundraiser together to hire a Nvidia Windows Cuda expert to work on it against Petri's Linux efforts. ;-)

That port could be done, but AFAIK the optimization will not be high as with Linux due the way the Windows works.
Anyway the original code is available if anyone wants to play with it and try this porting.

I'm still waiting for mine.

Ha ha ha LOL. :-> Me too!~

My last early birthday present to myself was 2yrs ago and that was the 2x 1060's in that rig. ;-)

Cheers.

I'll post this first. Then I'll read the messages.

I love my 15 years T-Shirt I received some years ago - I still wear it at special days at my work: As a teacher of math, physics, chemistry and computer related stuff (programming, meaningful usage and detecting false news). Sometimes it raises questions.

Thanks to the lovely lady and a far away friend I've never met. I still use the T-shirt.

It will wear out some day. I'm still the same size.

--
Petri33.

I can't remember . . . . . Wiggo did you state you were going to hold off adding the -nobs parameter after your RAC stabilized?

Yep, other than changing the checkpoints to 6mins I'll see how the "out of the box" goes first before doing any changes.

I must have my baselines set 1st Keith, which is also why my 3570K rig is still on Win7 and waiting for its bits of my early birthday present to myself. ;-)

Cheers.

For those that are curious, I found an interesting PDF in relation to GPU processing on Nvidia GPUs
Precision & Performance:Floating Point and IEEE 754 Compliance for NVIDIA GPUs

Mathematically, (A + B)+ C does equal A + (B + C).
Let rn(x) denote one rounding step on x. Performing these same computations in single precision floating
point arithmetic in round-to-nearest mode according to IEEE 754, we obtain:

            A + B = 21 × 1:1000000000000000000000110000 : : :
        rn(A + B) = 21 × 1:10000000000000000000010
            B + C = 23 × 1:0010000000000000000000100100 : : :
        rn(B + C) = 23 × 1:00100000000000000000001
        A + B + C = 23 × 1:0110000000000000000000101100 : : :
rn(rn(A + B) + C) = 23 × 1:01100000000000000000010
rn(A + rn(B + C)) = 23 × 1:01100000000000000000001

For reference, the exact, mathematical results are computed as well in the table above. Not only are the results computed according to IEEE 754 different from
the exact mathematical results, but also the results corresponding to the sum rn(rn(A + B) + C) and the sum
rn(A + rn(B + C)) are different from each other. In this case, rn(A + rn(B + C)) is closer to the correct mathematical result than rn(rn(A + B) + C).
This example highlights that seemingly identical computations can produce different results even if all basic
operations are computed in compliance with IEEE 754.

Here, the order in which operations are executed affects the accuracy of the result. The results are independent
of the host system. These same results would be obtained using any microprocessor, CPU or GPU, which
supports single precision floating point.

As we have shown in Section 3, the final values computed using IEEE 754 arithmetic can depend on implementation choices
such as whether to use fused multiplyadd or whether additions are organized in series or parallel. These differences affect computation on the CPU
and on the GPU.
One example of the differences can arise from differences between the number of concurrent threads involved in a computation.
On the GPU, a common design pattern is to have all threads in a block coordinate to do a parallel reduction on data within the block,
followed by a serial reduction of the results from each block. Changing the number of threads per block reorganizes the reduction; if the reduction is addition, then
the change rearranges parentheses in the long string of additions.

Computing results in a high precision and then comparing to results computed in a lower precision can be
helpful to see if the lower precision is adequate for a particular application. However, rounding high precision
results to a lower precision is not equivalent to performing the entire computation in lower precision. This can
sometimes be a problem when using x87 and comparing results against the GPU. The results of the CPU may
be computed to an unexpectedly high extended precision for some or all of the operations. The GPU result
will be computed using single or double precision only.