I can confirm . 8.20 cuda 6 short run ; ran one each on gtx770 & gtx780 WinXP Pro 64bit with the 335.28 driver all went fine. Only just slightly longer GPU run time than observed with 5.5 and 332.21 driver.



PS: I have this wild dream that one day Nvidia comes out with a new driver and it actually shortens GPU run time ! DARE TO DREAM :)

Try the new version 820

Moved one of the XP Pro32 machines back to 335.28 last night and it just completed a 8.20 Cuda60 WU this morning. This one was a short on a GTX460.

http://www.gpugrid.net/result.php?resultid=8012977

I'll move the other XP machine back to 335.28 now.

Thank you.

PS: I have this wild dream that one day Nvidia comes out with a new driver and it actually shortens GPU run time ! DARE TO DREAM :)

Doesn't really happen with compute applications the way it does with games. I suspect that the larger performance increases boasted about for individual games comes from shipping manually-optimised versions of a game's shader kernels along with the driver.

For compute applications (for ours at least), that's not possible. We'll only get a benefit from the driver if it addresses system-level issues; for example the launch overhead of WDM.

Matt

Finally got some of the new 820(CUDA60) units on my XP32 cruncher and they started ok without erroring out :-)

Thanks for sorting out the problem with the app!!!

Update on 820 Cuda60 on XP Pro32

Computer 1 completed another for 2 good and 0 errors
Computer 2 I switched this morning to 335.28 completed 1, 1 in progress, and 0 errors.

Looks resolved. Again, thanks.

I'm still getting the occasional v8.15 allocated to my Maxwell - which is a bit of a waste for all concerned.

Task 8064144

I'm still getting the occasional v8.15 allocated to my Maxwell

Don't know what's going wrong there. Try a project reset?

Matt

Same here: My 750 Ti is getting Cuda55 long work units and they all error out... the short units are Cuda60 and are successful. A few days ago I got some long run Cuda60 units which were also sucessful - but I'm not getting those anymore.

Is there anything I can do to force Cuda 6 long run units?

http://www.gpugrid.net/results.php?hostid=170512

Oh, you are talking about long. The app isn't on acemdlong yet. No until I'm happy with the results I get on short.


Matt

I'm still getting the occasional v8.15 allocated to my Maxwell

Don't know what's going wrong there. Try a project reset?

Matt

I don't see how that would help? I started testing the card with short run tasks, switched to long tasks when the the cuda60 app was made available. Got a long task error when the highest version dropped back to cuda55, so switched to short tasks again.

Mostly, the short tasks have been tagged as cuda60, and have run successfully. It's just that single short task allocated at 10:47 this morning which failed because of the cuda55 tagging: since then, I've completed one cuda60 task without error, and I'm in the middle of another one now.

All tasks for host 170387

Which plan_class a task is allocated to use (cuda42, cuda55, cuda60) isn't something either we or our BOINC clients can control (though some wish....). Currently, it's a server decision only, which is why I drew attention to it.

Referring to Specifying plan classes in XML, it looks as if you may need filter the lower plan_classes (cuda42, cuda55) with

Fields for NVIDIA GPU apps:

<max_nvidia_compcap>0499</max_nvidia_compcap>
maximum compute capability

or something like that - I'm not 100% certain of my translation of "<5.0" into MMmm format.

I've had 6 App820(CUDA60) units successfully complete on my XP32 cruncher... Looking good!!!

Agree; 820 now looking good on win x86 - gtx 650ti

Thanks

I'm still getting the occasional v8.15 allocated to my Maxwell - which is a bit of a waste for all concerned.

Task 8064144

This is still an issue. I only just attached to the project and my first unit was cuda55 which errored. My 2nd unit is cuda60.

Task 8203849

Should we detach until this is fixed? Half my units are erroring due to 8.15.

This poor unit keeps being sent as 8.15 http://www.gpugrid.net/workunit.php?wuid=5508762

I guess no one cares enough. I'll detach, back to PrimeGrid with me.

I would keep running the WU's, but I would abort any 5.5 I see downloading. The WU's that fail do so very quickly but there is a lot of wasted Internet usage.

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

I would keep running the WU's, but I would abort any 5.5 I see downloading. The WU's that fail do so very quickly but there is a lot of wasted Internet usage.

And, at the moment, there is a lot of idle-time due to slow server ...

It would be incorrect to say I understand why the scheduler is fickle in giving out cuda55 and cuda60 to Maxwell machines, but I think I can see how to stop it happening. Scheduler restart shortly.

Matt

One day, my heterogeneous PC will have: 1 Maxwell GPU, 1 Kepler GTX 660 Ti, and 1 Fermi GTX 460... while running the latest NVIDIA drivers. I hope that, whatever scheduler changes you make, will still allow for heterogeneous scenarios such as mine.

I think the scheduler is written to 'test' sub-optimal plan_classes randomly, to avoid a client getting stuck indefinitely in a one-off rogue allocation.

That means that the periodic 'ping' with cuda55 is deliberate, and has to be actively prevented when, as now, there's an app or two which are incompatible with a certain class of cards or (more commonly) drivers.

Use that max_compute_capability (check the tag name - it's probably not that) on the lower plan classes to prevent them being sent to Maxwell or above.