I have uploaded the new cuda4.2 app for the acemd2 queue. Later in the afternoon the Linux app.
The long queue will join in a week if these tests go well.

Please post here any problem.

gdf

My "wrong client sent" problem persists:
I've received a cuda4.2 task, and immediately after that a cuda3.1 task.

Win7x64, BOINC 7.0.25, GTX670, 301.42
Still only getting BETA but am getting the correct app version.

5489046 3494397 12 Jun 2012 | 13:19:41 UTC 17 Jun 2012 | 13:19:41 UTC In progress --- --- --- ACEMD beta version v6.46 (cuda42)
5488924 3494311 12 Jun 2012 | 13:16:21 UTC 12 Jun 2012 | 13:19:41 UTC Completed and validated 63.75 61.92 150.00 ACEMD beta version v6.46 (cuda42)

[edit] I had also checked the acemd standard box and pulled more betas before posting. I may try turning off beta as I am assuming that beta wus are fed at a higher priority?

---

Thanks - Steve

Wondering the same myself. Are we to select ACEMD standard (short queue) tasks as well? Or are these in the Beta section still?

I allowed tasks for Beta, and they're still the short 60 sec Beta tasks

EDIT:

Nevermind, ticked short queue task box, and 4.2 are downloading. Will report back shortly.

My "wrong client sent" problem persists:
I've received a cuda4.2 task, and immediately after that a cuda3.1 task.

Anybody with the same problem?

gdf

Both 680's and the single 670 have all downloaded 2 tasks of CUDA 4.2 apiece. All running smoothly so far.

Both 680's and the single 670 have all downloaded 2 tasks of CUDA 4.2 apiece. All running smoothly so far.

Did you have to uncheck "BETA" to get these?

---

Thanks - Steve

Yes. Also uncheck Run Test apps and BETA tasks.

Only select ACEMD standard (short queue).

RUNTIMES:

On a 3820@ 4.3 PCIe. 3.0 with 6 tasks WCG running (All GPUs are stock clocks):

680@ 1110MHz= 4,392.26 seconds (SWAN_sync=0 active by default?) & 92% utilization
680@ 1084MHz= 4,478.54 seconds (SWAN_sync=0 active by default?) & 91% utilization

i52500k@ 4.2 with 3 tasks WCG running

GB 670@ 1188MHz= 4547.91 seconds SWAN_sync=0 active as well & 94% utilization

All of these tasks were MJH

EDIT: With 8100 points a piece, these runtimes actually fall in line with the long queue runtime/points. 570 long= 36,000-40,000=81,000 points.

Quite happy with the utilization and everything. Good work GPUgrid team!! Will report back when some PAOLA- 3EKO tasks complete.

My "wrong client sent" problem persists:
I've received a cuda4.2 task, and immediately after that a cuda3.1 task.

Anybody with the same problem?

Stoneageman's host have the same problem.

Do you have the same boinc client version?
Does anybody don't have the problem with a fermi card?

gdf

My BOINC client is v6.10.60, Stoneageman's is v7.0.28.

Hosts with the "wrong client sent" problem:
112231
125545
74707
117005
79303
118123
114725
69207
They are not so hard to spot from the top list of hosts. This problem is not so conspicuous for the average cruncher, since they were instructed to use old drivers, or even if they use new drivers they usually crunch long tasks only.

EDIT:

I've found two more
96619
6926

I've got the feeling that the cuda4.2 application is less tolerant of GPU overclocking.

Why do you say that? And for kepler or fermi? Or both?

I've got the feeling that the cuda4.2 application is less tolerant of GPU overclocking.

Why do you say that? And for kepler or fermi? Or both?

ATM I have Fermi cards only, so I don't have any experiences with Kepler.
A few cuda4.2 tasks have failed on my GTX 590 @ 725MHz, so I've set it to 700MHz, also on my GTX 580 @ 850MHz, so I've raised its voltage to 1075mV. Since then they are crunching fine (36 minutes).
BTW we have nothing to compare the overclock ability of the cuda4.2 client on Kepler to, since the cuda3.1 client didn't work on that chip.

Interesting. Will have to try and OC one of them when i get back home.

I've got the feeling that the cuda4.2 application is less tolerant of GPU overclocking.

This could well be: the more performance you extract from a GPU, the harder it has to work (generally).

MrS

---

Scanning for our furry friends since Jan 2002

The cuda4.2 tasks have failed on my GTX 590 @ 700MHz, and at 650MHz too, so now it's running at factory default 607MHz.
I've received cuda3.1 tasks on this host, so I can't experiment with cuda4.2 vs overclocking for a while.

Possible issues (annoyances really)

1) The IBUCH tasks on the 4.2 app w/ a 680 only run at roughly 56%. While I really don't care about this fact, with Kepler, this is apparently low enough of a percentage to not kick in the boost feature. Meaning, that these tasks drop down to I think a certain "stepping point" + my offset. I can raise my offset to correct for this, but if I am not here when another task loads, the offset will most likely cause a crash. Especially if a MJH were to pop up, since an offset of +100 would put me up to about 1210MHz. Which brings me to my next point.

2) My GB 670, which is stock OC to 1188 HARD crashed yesterday. I actually had to go into Safe Mode in order to reinstall the driver. So RZ, you may be right and CUDA 4.2 is much less tolerant of OCing. If this is the case, than I believe a sticky may need to be created in regards to this. We don't want people buying OCed cards (cost more) if they will fail constantly. Temps are VERY manageable, even with a reference card. Right now I've got my 680's at 1135MHz, and I'm hoping to reach 1150MHz before I crash.

So, in short, point one is really more of a personal annoyance, but still an issue in regards to utilization (overall) and the boost feature. Don't think IBUCH are in the long queue, so this problem should fix itself. As for the OC cards, we may have to wait and see, but I'll keep everyone posted with my progress with Kepler.