OK, when I start upgrading my other two tomorrow morning I'll start with 372.54, and if that works, probably stick at 373.06 (first and last of the 372 series respectively).

I can confirm that both these drivers allow v9.18 (cuda80) tasks to download and run on my GTX 970s under Windows 7. I'll settle on 373.06 - last bugfix for the series.

Technically speaking, these are major version 370 drivers, according to the release notes.

But Richard,

Instead of playing with R370, you could be playing with R375, or R378, or even R381 --- the installer is 415 MB now, and they're only introducing about 2 new bugs for each one they fix! :)

I have every installer and release note, all the way back to 280.26. It's taking 37.3 GB of space.

I'm happy just bumping along the bottom - I'll leave the stratosphere to you :)

It really does make it worth investing in a 50 Mbits internet connection and SSD system drives, doesn't it? I wonder who's got shares in who?

And I'm glad GPUGrid got the project internet connection sorted before we all had to upgrade to cuda 8.0 - I'm getting that 140 MB cufft64_80.dll in about 40 seconds.

I'm happy just bumping along the bottom - I'll leave the stratosphere to you :)

Indeed. Just look at all these PRETTY numbers!
There not a non-alpha version to be found! Just the way I like it! :)

4/15/2017 3:21:41 PM | | Starting BOINC client version 7.7.2 for windows_x86_64
4/15/2017 3:21:41 PM | | This a development version of BOINC and may not function properly
4/15/2017 3:21:41 PM | | log flags: file_xfer, sched_ops, task, scrsave_debug, unparsed_xml
4/15/2017 3:21:41 PM | | Libraries: libcurl/7.47.1 OpenSSL/1.0.2g zlib/1.2.8
4/15/2017 3:21:41 PM | | Data directory: E:\BOINC Data
4/15/2017 3:21:41 PM | | Running under account jacob
4/15/2017 3:21:42 PM | | CUDA: NVIDIA GPU 0: GeForce GTX 980 Ti driver version (381.78, CUDA version 8.0, compute capability 5.2, 4096MB, 3962MB available, 7271 GFLOPS peak)
4/15/2017 3:21:42 PM | | CUDA: NVIDIA GPU 1: GeForce GTX 980 Ti driver version (381.78, CUDA version 8.0, compute capability 5.2, 4096MB, 3962MB available, 6060 GFLOPS peak)
4/15/2017 3:21:42 PM | | OpenCL: NVIDIA GPU 0: GeForce GTX 980 Ti driver version (381.78, device version OpenCL 1.2 CUDA, 6144MB, 3962MB available, 7271 GFLOPS peak)
4/15/2017 3:21:42 PM | | OpenCL: NVIDIA GPU 1: GeForce GTX 980 Ti driver version (381.78, device version OpenCL 1.2 CUDA, 6144MB, 3962MB available, 6060 GFLOPS peak)
4/15/2017 3:21:42 PM | | Host name: Speed
4/15/2017 3:21:42 PM | | Processor: 16 GenuineIntel Intel(R) Core(TM) i7-5960X CPU @ 3.00GHz [Family 6 Model 63 Stepping 2]
4/15/2017 3:21:42 PM | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 fma cx16 sse4_1 sse4_2 movebe popcnt aes f16c rdrandsyscall nx lm avx avx2 vmx tm2 dca pbe fsgsbase bmi1 smep bmi2
4/15/2017 3:21:42 PM | | OS: Microsoft Windows 10: Professional x64 Edition, (10.00.16176.00)
4/15/2017 3:21:42 PM | | Memory: 63.90 GB physical, 73.40 GB virtual
4/15/2017 3:21:42 PM | | Disk: 300.00 GB total, 222.52 GB free
4/15/2017 3:21:42 PM | | Local time is UTC -4 hours
4/15/2017 3:21:42 PM | | VirtualBox version: 5.0.37

I was expecting it to work on 64 bit XP, actually. Given that it doesn't there's not a tremendous amount I can do to fix it immediately.

We haven't had an XP test platform for a long time: Microsoft's ended support for it 3 years ago! You really should upgrade...
Matt

Matt,
It's a bit off-topic, but let me explain:
These Windows XP x64 hosts are dedicated crunching boxes (therefore it does not matter if their OS is not supported anymore). A lot of effort have been put into them to make the GTX 980Ti work under Windows XP, selecting the right MB, "hacking" the NV driver to recognize the top-end cards, etc. The reason for *not* to upgrade them from Windows XP is to maximize their throughput (avoiding WDDM).

... But for now, if you could make a fresh CUDA 6.5 client, that would be great (and it would save us a lot of work).
Thank you in advance!

I can only fully underline what Zoltan is saying, and hope that all the many crunchers using XP for good reason will be able to continue for a while.

+ 1

Damn, guess this means I will have to move off the 359.06 drivers eh?

CC 3.0 ... still isn't working on 9.18 ...

I have the same situation. I was told, that the reason is in obsolete .dll file and bad WU at the server. The problem must be solved within a week or so.

I can confirm, that the driver version: 373.06 solves the problem for my GTX 970 cards, but not for the GTX 670. It does not download any new WU on this computer.

When will we receive a new app for this type of cards?

After two days of useless requests my computer finally got a new job in GPUGrid. But new `long run` task lasts three times longer, than any previous `long run`! With the same amount of calculations (5 000 000 GFLOPs) on the same machine it is running for 27-29 hours instead of 9-10 before.
My old GTX680 perfectly fulfilled the calculations in the GPUGrid until April 14, 2017. Now it has become practically useless in this project.
Although it still shows high results in Einstein@Home.
If this changes are the result of "code optimization", then it is negative.
Please think about the owners of old Nvidia GPUs (with Compute Capability 3.0 and 2.1). Many people still use them.

Unfortunately, the "same amount of calculations (5 000 000 GFLOPs)" applies to all tasks assigned to the long queue, and isn't adjusted to reflect the complexity (duration) of the task - even though tasks are assessed before the run starts, so that a proportionate amount of credit can be issued.

It would be a significant improvement to the way this project runs alongside other projects under BOINC, if the task calculation estimate could be adjusted as well as the credit award.

After two days of useless requests my computer finally got a new job in GPUGrid. But new `long run` task lasts three times longer, than any previous `long run`! With the same amount of calculations (5 000 000 GFLOPs) on the same machine it is running for 27-29 hours instead of 9-10 before.

The workunits won't take longer than before, only the estimation of the remaining time (what you see) is miscalculated. This time estimation will normalize after a couple of workunits done. As this is a new app, so the BOINC manager has to learn the duration correction ratio for this version. Alternatively you can make an app_config.xml to instruct the BOINC manager to calculate the remaining time based on the fraction done and the time elapsed.

Copy the following to the clipboard:

notepad c:\ProgramData\BOINC\projects\www.gpugrid.net\app_config.xml

Press Windows key + R, then paste and press [enter].
If you see an empty file then copy & paste the following text:

<app_config>
 <app>
  <name>acemdlong</name>
  <fraction_done_exact/>
 </app>
 <app>
  <name>acemdshort</name>
  <fraction_done_exact/>
 </app>
 <app>
  <name>acemdbeta</name>
  <fraction_done_exact/>
 </app>
</app_config>

If you already have an app_config.xml, then you should only insert the line

  <fraction_done_exact/>

after each line containing the name of the application.

Click file -> save and click [save].
Open the BOINC manager, click Options -> read config files.

Zoltan, thanks for the "fraction_done_exact" app_config.xml, seems very useful.

On one of my PCs, there already is:

<app_config>
<app>
<name>acemdshort</name>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>1</cpu_usage>
</gpu_versions>
</app>
</app_config>

so, in this case, how do I include the "fraction_done_exact" part so that it works not only for acemdshort, but also for acemdlong ?

Erich56:

1) See here:
https://boinc.berkeley.edu/wiki/Client_configuration#Application_configuration
... There's a pretty example of what an app_config.xml file is supposed to look like.

2) Learn to read XML :) Seriously, you can do it, I promise. Look carefully at his example - You'll see that the fraction_done_exact element lives within the app block. And, when declaring an element that isn't a block, you can put a slash at the end of it to not need a separate terminator for that element.... ie: <fraction_done_exact/>

So, if your XML file declares multiple app blocks (say x blocks), and you want all of them to use this setting, then you'll need to add the line x times, in the right places.

Looking at what you pasted, it seems you will need to create the acemdlong app block entirely.

So, if your XML file declares multiple app blocks (say x blocks), and you want all of them to use this setting, then you'll need to add the line x times, in the right places.

Looking at what you pasted, it seems you will need to create the acemdlong app block entirely.

okay, all clear, thx, seems to work :-)

Anyone having some weird GPU usage lately? it's stable at 90% for like 3 mins, then 0% (while still showing "Running" in BOINC) for a long time.

Aborted 2 units thinking they were faulty (contact goals), but i'm seeing same behaviour with ADRIA unit at the moment.

EDIT: running latest Nvidia drivers and 9.18 app

Anyone having some weird GPU usage lately?

Yes, this afternoon I happened to notice this behavour on one of my Windows 10 machines - latest software, latest driver.
Since I was out for a while, I cannot tell for how long time the CPU usage (as seen in the Windows Task Manager) was at zero.
The task (still running) is a Pablo_contact_goal_KIX. But if you can observe this with a ADRIA task as well, then it seems that the fault may rather be with the new software.

Anyway, what I noticed already is that with the new software, in Windows 10 crunching is a bit slower, and overclocking even less possible than before.

this evening, again I noticed this strange behaviour as described above.
The interesting thing is that in the BOINC Manager, the task is shown as "active", although the progress bar does not proceed, and the CPU usage in the Windows task manager is zero.
And after a while, the task resumes crunching.

I'm noticing similar behavior on my machine. Running a GTX 1070. I look at GPU core load directly in HWinfo and it will just sit at 0% load for long periods, but from looking at the task history they seem to be completing eventually. Anyone know what's going on with this?

back at it again

Anyone else getting a bunch of faulty WU?