this happens since about 20 minutes ago:
after earlier jobs were finished and uploaded, every new one which is downloaded fails right at the beginning with "computation error" (runtime:0; CPU time: 0). Regardless of what type of WU it is.

The stderr's of these WUs all look this way:

<core_client_version>7.6.22</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code -44 (0xffffffd4)
</message>
]]>

Thus, my daily quota was finished within short time :-(

any idea what problem this is?

Same here, all units are failing with this error message:


Stderr output

<core_client_version>7.6.33</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code -44 (0xffffffd4)
</message>
]]>


This is happening on my windows 10 computer. I disconnected my other computer from the network, no errors on that one, right now.


This same error is happening to units downloaded earlier that were previously running well, once the host contacts the server.

Same, http://www.gpugrid.net/workunit.php?wuid=12499116 5 WU Failed on one computer, probably hit daily quota and is disabled now.

thanks, folks, for the quick replies.
So there seems to be something wrong in general with the WUs that are being downloaded currently.

This happens at a very bad time, as I suspect that due to the Easter holidays there will be no one available at GPUGRID to rectify the problem :-(

Hi,
same here .... (unknown error) - exit code -44 (0xffffffd4)... continuously !
With no wu now ... because computer has finished a daily quota of 3 tasks !
After the damage ... now the trik !
Please suspend/cancel this daily quote, thanks in advance.
K.

____________
Dreams do not always come true. But not because they are too big or impossible. Why did we stop believing.
(Martin Luther King)

Same thing here, quota maxed.

Hi!
Also happened on my two pc's;

one win 7 Ultimate 64, Nvidia 680 Gtx Driver 381.65,boinc 7.6.33 and
one win 10 Core 64, Nvidia 970 Gtx Driver 381.65, boinc 7.7.2 .

Tried to reset the latter one, still the same error !

With regards,

Hans Sveen
Oslo, Norway

I too am getting "Computation Errors" on all my GPUGrid tasks, currently.

Long runs (8-12 hours on fastest card) v8.48 (cuda65)

e3s12_e2s3p1f468-ADRIA_FOLDGREED50_crystal_ss_contacts_100_ubiquitin_6-1-2-RND2729_7
http://www.gpugrid.net/result.php?resultid=16219421

e4s6_e3s8p1f477-ADRIA_FOLDGREED50_crystal_ss_contacts_100_ubiquitin_8-0-2-RND8520_2
http://www.gpugrid.net/result.php?resultid=16219440

e16s215_e5s183p2f300-PABLO_contact_goal_KIX_CMYB-1-4-RND5301_2
http://www.gpugrid.net/result.php?resultid=16219443

e5s12_e4s5p0f45-ADRIA_FOLDGREED90_crystal_ss_contacts_20_ubiquitin_2-0-1-RND7117_3
http://www.gpugrid.net/result.php?resultid=16219446

I too am getting "Computation Errors" on all my GPUGrid tasks, currently.

Same issues as listed above, regardless of long/short WUs. Hope we can hear back from the team soon!

Matt's FAQ: What do the application error codes signify? lists "-44 The computer's date is wrong." Mine still looks OK, but I'm getting the same errors as everybody else.

One machine still has a task running, so I'll grab a copy of the files and the workunit/result specifications from client_state.xml: then see what's different about the replacement when I need one.

I experience the same behavior.
I would like to add that from my experience the workunits in progress will also fail with this error if you restart your PC, right after the restart.
See task 16216692, 16216249, 16216581
I've sent a notification e-mail about this to the staff.

Same here :-)

Same here
____________
[CSF] Thomas H.V. Dupont
Founder of the team CRUNCHERS SANS FRONTIERES 2.0
www.crunchersansfrontieres

50 failed tasks since 14:46 UTC on the 14th of April. They continue to come and fail.

If this again turns out to be a staff failure, I'm done.

Is this science or science fiction.

Once again, the weekend comes and the junk rolls out.

Why would you ever trust the science of a group who is so careless with their work.

Interestingly enough: on the Project Status page, the number of unsent tasks is going up continuously.

Interestingly enough: on the Project Status page, the number of unsent tasks is going up continuously.

Interestingly enough: on the Project Status page, the number of unsent tasks is going up continuously.

It's because all active hosts have used up their daily quota.

Interestingly enough: on the Project Status page, the number of unsent tasks is going up continuously.

It's because all active hosts have used up their daily quota.

so I guess these are the tasks that are being generated automatically, right?

50 failed tasks since 14:46 UTC on the 14th of April. They continue to come and fail.

If this again turns out to be a staff failure, I'm done.

Is this science or science fiction.

Once again, the weekend comes and the junk rolls out.

Why would you ever trust the science of a group who is so careless with their work.

These are simply the failed workunits waiting to be resend to another host, but there's none to send to, because all have used up their dailiy quota.

My first failure was at

14:21:01 UTC on the 14th.

50+ and counting.
____________

Here's an interesting one: WU 12499196.

Three consecutive failures with exit status -44, as we're all seeing. All of those were with the v8.48, cuda65 application.

But the fourth has gone to my (one and only) GTX 1050 Ti running the v9.15, cuda80 application. And it's running just fine - even better than fine, blisteringly fast.

There was an announcement this week that v9.15 was now available to all supported GPU generations: my older ones haven't picked it up, probably because I haven't updated my drivers recently. But just maybe, the current tasks require v9.15? That's one to test in the morning.

I have updated drivers Richard on my 980ti but it won't pick up new app. I have reset project and still 8.48 cuda 6.5

I experience the same behavior.
I would like to add that from my experience the workunits in progress will also fail with this error if you restart your PC, right after the restart.

I experience the same behavior.
I would like to add that from my experience the workunits in progress will also fail with this error if you restart your PC, right after the restart.

I'd like to further clarify that.

If you suspend in-progress tasks, then resume them, they will fail. I just lost tons of work that way :) I smile, because it's all I can do. It happens. Just wanted to add that suspending and restarting the task itself, is also a problem.

I have updated drivers Richard on my 980ti but it won't pick up new app. I have reset project and still 8.48 cuda 6.5

Here's an interesting one: WU 12499196.

Three consecutive failures with exit status -44, as we're all seeing. All of those were with the v8.48, cuda65 application.

But the fourth has gone to my (one and only) GTX 1050 Ti running the v9.15, cuda80 application. And it's running just fine - even better than fine, blisteringly fast.

There was an announcement this week that v9.15 was now available to all supported GPU generations: my older ones haven't picked it up, probably because I haven't updated my drivers recently. But just maybe, the current tasks require v9.15? That's one to test in the morning.

There was an announcement this week that v9.15 was now available to all supported GPU generations: my older ones haven't picked it up, probably because I haven't updated my drivers recently. But just maybe, the current tasks require v9.15? That's one to test in the morning.

I don't think so.
It's more likely that some dll stopped working after a given date, that is 04.14.2017.
It could be a licensing limitation, or other time limit which is expired.

Great find, Retvari! That should help the devs to solve it as quickly as they can!

On a lighter note, I found another easy workaround too, here:
https://www.youtube.com/watch?v=dQw4w9WgXcQ

I've downloaded 4 new tasks with my main cruncher PC, then I've set the date on this PC to 04.13.2017, and I've started the GPUGrid tasks. Guess what? It's crunching! Yes, the 8.48 app. So there's a date limit somewhere in the 8.48 app.

Great find, Retvari! That should help the devs to solve it as quickly as they can!

... be patient !

So there's a date limit somewhere in the 8.48 app.

Business and Enterprise Editions provide access to older Tcl versions:

Although non-production use is permitted for free using our latest Community Edition versions, use of legacy versions on non-production and/or production machines requires a Business Edition or Enterprise Edition license.

So there's a date limit somewhere in the 8.48 app.

My suspicion (unverified) is that the problem might lie with tcl84.dll

That's been replaced with tcl86.dll in v9.14/5...

Zoltan wrote:

I've downloaded 4 new tasks with my main cruncher PC, then I've set the date on this PC to 04.13.2017, and I've started the GPUGrid tasks. Guess what? It's crunching!

So there's a date limit somewhere in the 8.48 app.

My suspicion (unverified) is that the problem might lie with tcl84.dll

That's been replaced with tcl86.dll in v9.14/5...

I've tried to replace tcl84.dll with tcl86.dll by renaming the latter (and setting don't check file sizes in cc_config.xml), but then I got a different error:

There are no child processes to wait for. (0x80) - exit code 128 (0x80)

Sad to report that both approaches failed. A normal work fetch got me v8.48 even with a cuda 8.0 driver, and it failed with the clock error as before.

A full v9.15 file set (copied from my GTX 1050Ti machine, also running Windows 7/64) under app_info.xml gave repeated iterations of

15/04/2017 12:28:16 | | CUDA: NVIDIA GPU 0: GeForce GTX 970 (driver version 368.81, CUDA version 8.0, compute capability 5.2, 4096MB, 3066MB available, 4087 GFLOPS peak)

which driver version is necesary and which driver version is save?

... updating drivers should do it

My drivers are locked to the versions that came with the devices: changing drivers causes failures.

I will return as soon as the current system issues have been resolved as I believe GPUGrid performs valuable work.

Now I am off to Folding and WCG.....
____________
John

For a more correct solution we will have to wait for Matt to update the old app next week. In the meanwhile as I said updating drivers should do it

... My failures are on Windows 10, using 381.65 and 381.78. Please provide more details on what drivers you think should work, and also why failures still happen on 381.65 and 381.78.

I see you've deprecated v8.48 completely, but left v9.15 (superficially - as far as we can see) unchanged. I couldn't get it to work earlier, but I'll try again within the hour - test machine is busy with another project just at the moment.

The problem should now be fixed for anyone with a CUDA 8-capable driver.

Matt

I've changed the rules for issuing the 915 version. Any Windows machine that is 64 bit and reports CUDA 8.0 capability will get it now.
Matt

OK, let's put XP to bed - I think it's a red herring in this case.

I have two - well, three - identical Windows 7/64 machines, each with GTX 970 GPUs.

Two tests - first, with an older cuda 7.0 driver: no tasks available, no tasks sent. That's the right answer after deprecating v8.48

Second, the one which I upgraded with a cuda 8.0 driver earlier today (specifically, 368.81). Task was sent, and along with it the v9.15 application - again, as intended. So far so good.

BUT - as reported earlier in this thread (but I appreciate you wouldn't want to read through the entire thing on a holiday Saturday), v9.15 isn't running on my Maxwell cards with the current batch of tasks. (It runs fine on a Pascal card in another machine)

Symptoms are:

Under BOINC, repeated iterations of

Task e4s7_e2s3p0f357-ADRIA_FOLDGREED10_crystal_ss_contacts_100_ubiquitin_4-1-2-RND7142_0 exited with zero status but no 'finished' file

So which steps will be taken next to enable older drivers for XP to work?

My XP with driver 368.81 did download version 915, the task did start, but was broken off after a few minutes with "too many exit(0)s"

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

I was running the same cuda 7.0 driver version on all machines until this morning - I upgraded this morning for testing only.

My experience is that each successive driver release is slower for general purpose computing (generalisation - YMMV). Since I'm not a gamer, I don't want need or want the latest game patches. I just picked one that was the last in its particular sequence, so more likely to be stable and bug-free.

We have the benefit of Jacob Klein reporting into this thread as well (see message 46910) - he does test the latest drivers for the benefit of the wider BOINC community, and has persuaded NVidia to fix several bugs over the years. He reports the same as me.

Edit - Your Pascal app release post (message 44869) says simply "NVIDIA Driver 360+" - I thought I'd aimed high enough above that?

Sure, anything I can do to help. Supper has just beeped in the microwave, but I'll download while I eat, and install later.

Edit - 381.65 on its way.

MJH:

Can you please explain:
1) What caused the problem?
2) What solved the problem?
3) Why were "updated drivers" previously recommended as a solution?

Specify *which* problem, please.

Version not downloading - server configuration (plan class specification, I suspect), fixed.

Current set of tasks failing on older cards - not fixed, under exploration.

MJH:

Here's what I'm seeing with 9.15:
- My PC "Speed", that has GTX 980 Ti x2 .... appears to work fine with 9.15
- My PC "RacerX", that has GTX 970 and GTX 660 Ti x2 ... appears to have problems running 9.15 apps on the 2 GTX 660 Ti GPUs. See below.

I thought CC 3.0 GPUs were still supported.
Any ideas?

Interesting. The machines I'm having problems with also have dual GPUs of different vintages - mine have a secondary GTX 750Ti in both cases. But GPUGrid is excluded from the 750s, and only runs on the 970s.

Thanks MJH.

I'll do my best to test 9.16 when it's released, though I sure wish I could get email notifications for my subscribed threads ... that's been broken for a while :/ Maybe you could take a peek.

Failing on all machines.

Windows 10x64 on all.

4 X GTX670's
3 X GTX680's
4 X GTX770's
2 X GTX780Ti's

They all have late driver versions.
____________

Richard the problem with your machines is (at least) the driver version.

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). If that doesn't work, rinse and repeat with 375.63 / 376.33 and so on.

MJH:
9.16 tasks are still not working for my GTX 660 Ti GPUs.

I updated my windows 10 computer to nvidia driver 381.65 from 359.06. Everything is running fine so far, but this driver is slightly slower.

Now, what is going to happen to windows xp? I would like to see it supported a little bit longer, and please don't tell me to upgrade.

If you are going to retire cuda 6.5, then please give us a warning before hand and don't do it, in this abrupt and amateurish manner.

And do keep track of your licenses' expiration dates and give us ample warning when we need to upgrade our software!

Thank you!!

Now, what is going to happen to windows xp? I would like to see it supported a little bit longer, and please don't tell me to upgrade.

If you are going to retire cuda 6.5, then please give us a warning before hand and don't do it, in this abrupt and amateurish manner.

And do keep track of your licenses' expiration dates and give us ample warning when we need to upgrade our software!

Thank you!!

My GTX750Ti - driver 376.53 & GTX1050Ti - driver 378.92 are working fine now.

2 GTX460 running driver 378.92 are not getting any work even though they are above the minimum driver level and show CUDA version 8.0...

4/15/2017 9:06:31 PM | GPUGRID | Sending scheduler request: To fetch work.
4/15/2017 9:06:31 PM | GPUGRID | Requesting new tasks for Miner ASIC and NVIDIA GPU
4/15/2017 9:06:33 PM | GPUGRID | Scheduler request completed: got 0 new tasks
4/15/2017 9:06:33 PM | GPUGRID | No tasks sent
4/15/2017 9:06:33 PM | GPUGRID | No tasks are available for Short runs (2-3 hours on fastest card)
4/15/2017 9:06:33 PM | GPUGRID | No tasks are available for Long runs (8-12 hours on fastest card)

9.18 is also not working for my GTX 660 Ti GPUs.
SWAN : FATAL Unable to load module .nonbonded.cu. (300)

Also, the 9.x tasks aren't responding to suspending very well, sometimes it takes 10-20 seconds after issuing the suspend command, before they actually suspend!

Here you can see where it was fine on the GTX 970, but immediately failed on the GTX 660 Ti:
https://www.gpugrid.net/result.php?resultid=16242220

Note: I am running a pre-release version of Windows 10 - but I wouldn't think that would matter, would it?

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 now tried task
e4s8_e2s3p0f357-ADRIA_FOLDGREED10_crystal_ss_contacts_100_ubiquitin_4-1-2-RND4569_2

on my Windows 10 64-bit, driver 376.53, acemd 918.80.

It errored out after 1.30 seconds:
(unknown error) - exit code -1073741790 (0xc0000022).

Why so?

on my Windows 10 64-bit, driver 376.53, acemd 918.80.

Windows 10/64-bit
GenuineIntel Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz
NVIDIA GeForce GTX 960M (2048MB) driver: 381.65

Running for 17 minutes
No problem for now
Fingers crossed
____________
[CSF] Thomas H.V. Dupont
Founder of the team CRUNCHERS SANS FRONTIERES 2.0
www.crunchersansfrontieres

It's been running well for 10 minutes ... so let's keep our fingers crossed.
The card is a GTX970.

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).

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 :)

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.

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.

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.

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?

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.