Should I change flops value for 6.08 when running with CUDA 2.3 dlls? GPU run times have dropped 30 to 50 per cent! Rebranded VLARs' estimates are half of what they should be.

---

Should I change flops value for 6.08 when running with CUDA 2.3 dlls? GPU run times have dropped 30 to 50 per cent! Rebranded VLARs' estimates are half of what they should be.

Yes, I was thinking the same thing. In fact, the original multipliers MarkJ and I posted back in March were, IIRC, based on the original RT and FFT, not even the v2.2 upgrade which was pretty good as well. I haven't done the maths yet, but you may need to declare that the speed of your CUDA card is double what it currently says. When I get a chance to watch a steady flow for a while, I'll try and get a better estimate.

Mark let me know when it is ready, we can then put a copy in the FAQ

I've updated the instructions on my blog, now that AP 505 is with us.

I have also installed the V12 optimised cuda app without the VLARkill as I am also running ReSchedule to shift the VLAR's from cuda to cpu. I have yet to add that to my instructions/app_info. Perhaps its time to start a new thread called "app_info for AP503, AP505, MB603 and MB608" :-)

Regards

---

Please consider a Donation to the Seti Project.

Should I change flops value for 6.08 when running with CUDA 2.3 dlls? GPU run times have dropped 30 to 50 per cent! Rebranded VLARs' estimates are half of what they should be.

Will the 2.3 dll's work with older cards? I run a couple of 8600GT's which IRC are built on CUDA V1.1. Information I've read says CUDA V1 cards cannot handle V2.x

Brodo

Should I change flops value for 6.08 when running with CUDA 2.3 dlls? GPU run times have dropped 30 to 50 per cent! Rebranded VLARs' estimates are half of what they should be.

Will the 2.3 dll's work with older cards? I run a couple of 8600GT's which IRC are built on CUDA V1.1. Information I've read says CUDA V1 cards cannot handle V2.x

Brodo

The only v1.1 I know about is the 'Compute capability', as reported by BOINC.

My 9800GT cards are also compute capability 1.1, and they take the new driver and 2.3 DLLs just fine - knocked about 30% off the processing time.

Thanks Richard - It was an error on my part. I misunderstood samuel7's post and thought he was referring to the CUDA version, not the dll version in the video card drivers. :-S

Brodo

Should I change flops value for 6.08 when running with CUDA 2.3 dlls? GPU run times have dropped 30 to 50 per cent! Rebranded VLARs' estimates are half of what they should be.

@ Richard
We also need to factor in the new extra-sensitive MB's as the flops values are presumably no longer correct for them. Is there a way of telling the new ones from the old ones (apart from flops estimate)?

Unfortunately I can't get to cuda 2.3 yet as GPUgrid app doesn't behave with later drivers. They are currently on cuda 2.1 and were trying to get to 2.2. Then cuda 2.3 got released this week :)

---

BOINC blog

Should I change flops value for 6.08 when running with CUDA 2.3 dlls? GPU run times have dropped 30 to 50 per cent! Rebranded VLARs' estimates are half of what they should be.

@ Richard
We also need to factor in the new extra-sensitive MB's as the flops values are presumably no longer correct for them. Is there a way of telling the new ones from the old ones (apart from flops estimate)?

Unfortunately I can't get to cuda 2.3 yet as GPUgrid app doesn't behave with later drivers. They are currently on cuda 2.1 and were trying to get to 2.2. Then cuda 2.3 got released this week :)

1) No, actually we don't. The speed of the application hasn't changed (it can't have, it's the same application). And because the the fpops estimate has been properly doubled to reflect the doubled actual work, it should all balance out. Joe has pointed out that because the CPU setup phase only has to be carried out once per double-length WU, there's a small gain - especially for CUDA - but he estimates no more than 5%.

2) I don't know what the B***S*** about drivers is at GPUGrid, but it's not true. All my tasks there have been run under 185.85, on the same machines with 2.2 DLLs in the SETI directory, and with no sign of distress - until, that is, task 1006526, just reported and run throughout with drivers 190.38: no sign of distress there either. I suspect it's similar to the threads we saw at Lunatics about crashes - eventually we were able to conclude that the majority were marginal hardware or cooling problems. I'm off to post along the same lines at GPUGrid now.

where can you download the cuda 2.3 dlls

---

where can you download the cuda 2.3 dlls

http://lunatics.kwsn.net/index.php?module=Downloads;sa=dlview;id=208

Wow. CUDA 2.3 gives a whole new meaning to the term "shortie". My 20% UNDERclocked GTX295 is now chewing through VHAR's in under 2 mins each (best so far is 1 min 40 sec).

Way t' go...

F.

---

thanks richard, installing new driver now and downloading dlls. thanks again.

---

2) I don't know what the B***S*** about drivers is at GPUGrid, but it's not true. All my tasks there have been run under 185.85, on the same machines with 2.2 DLLs in the SETI directory, and with no sign of distress - until, that is, task 1006526, just reported and run throughout with drivers 190.38: no sign of distress there either. I suspect it's similar to the threads we saw at Lunatics about crashes - eventually we were able to conclude that the majority were marginal hardware or cooling problems. I'm off to post along the same lines at GPUGrid now.

I've updated the drivers and cuda dlls for seti before with no problem. The issue is the GPUgrid app doesn't seem to behave with later drivers. At one point they claimed it was a bug with the cuda fft routines (which have been updated in cuda 2.3).

I will be trying the latest and greatest (190.38) drivers once i've knocked over my last lot of cuda work on one machine and see how it all hangs together this time.

---

BOINC blog

.... The issue is the GPUgrid app doesn't seem to behave with later drivers....

So some people seem to be saying, but it doesn't seem to be true for me - just completed task 1010279 on a second machine. The current GPUGrid thread on the subject seems to be covering some genuine issues with Linux drivers, but the Win 32 allegations just seem to be re-hashes of old archaeology without evidence. We had something similar at Lunatics, with people blaming applications, drivers, anything but their own hardware - which was where the problem turned out to be.

If people want to play safe and not update CUDA drivers while a long GPUGrid task is in progress, that would make sense: but not to upgrade at all because of this rumour would be shortsighted.

Wow. CUDA 2.3 gives a whole new meaning to the term "shortie". My 20% UNDERclocked GTX295 is now chewing through VHAR's in under 2 mins each (best so far is 1 min 40 sec).

Way t' go...

F.

WOW indeed !!
My GS250 is currently going through a batch of old "single" length shorties in around 1 min 57 sec. It was taking around 6 mins before.

Brodo

NVIDIA 190.38 (WHQL] & CUDA 2.3 ^^

24/07/2009 20:57:54 CUDA device: GeForce 8400 GS (driver version 19038, compute capability 1.1, 256MB, est. 8GFLOPS)

update :)

BYE 185.85 version CUDA 2.2

---

SETI@Home Informational message -9 result_overflow
with a general handicap of 80% and it makes much d' efforts for the community and s' expimer, thank you d' to be understanding.

.... The issue is the GPUgrid app doesn't seem to behave with later drivers....

So some people seem to be saying, but it doesn't seem to be true for me - just completed task 1010279 on a second machine. The current GPUGrid thread on the subject seems to be covering some genuine issues with Linux drivers, but the Win 32 allegations just seem to be re-hashes of old archaeology without evidence. We had something similar at Lunatics, with people blaming applications, drivers, anything but their own hardware - which was where the problem turned out to be.

If people want to play safe and not update CUDA drivers while a long GPUGrid task is in progress, that would make sense: but not to upgrade at all because of this rumour would be shortsighted.

It appears their app will work with 190.38 without issue, well it has so far. Also they have announced they will be releasing a cuda 2.2 app next week.

As for upgrading to 190.38, have managed to get 3 machines done so far. Just waiting on the others to finish off their cuda work. Highly recommended if you can do it.

---

BOINC blog

As for upgrading to 190.38, have managed to get 3 machines done so far. Just waiting on the others to finish off their cuda work. Highly recommended if you can do it.

Yes, upgrading nVidia drivers while you have CUDA work in your cache can cause problems.

I have Windows XP with BOINC running as a service, so I opened the 'Services' administration tool (services.msc), stopped the service, and set the startup type to Disabled. Then I was able to upgrade the drivers safely: check that everything was running smoothly in the nVidia control panel, copy the runtime DLLs, and restart BOINC in an orderly fashion. Worked for me.

As for upgrading to 190.38, have managed to get 3 machines done so far. Just waiting on the others to finish off their cuda work. Highly recommended if you can do it.

Yes, upgrading nVidia drivers while you have CUDA work in your cache can cause problems.

I have Windows XP with BOINC running as a service, so I opened the 'Services' administration tool (services.msc), stopped the service, and set the startup type to Disabled. Then I was able to upgrade the drivers safely: check that everything was running smoothly in the nVidia control panel, copy the runtime DLLs, and restart BOINC in an orderly fashion. Worked for me.

@Richard - could you elaborate a little, please. Would these problems only occur if running as a Service (and what kind of problems)?
Reason for request - as I am running Vista x64, I can't run as a Service. But since I upgraded I seem to be seeing more compute errors whether running Raistmer's V12 noVLARkill or stock CUDA. The errors are still very few compared to the number of WU's being crunched (about half a dozen overnight while running stock CUDA) but are annoyingly persistent.

The errors from the V12 App are the well documented:

Work Unit Info:
...............
WU true angle range is :  0.434701
After app init: total GPU memory 939524096	 free GPU memory 868741120
Cuda error 'find_pulse_kernel' in file 'd:/BoincSeti_Prog/sinbad_repositories/LunaticsUnited/SETI_CUDA_MB_exp/client/cuda/cudaAcc_pulsefind.cu' in line 920 : unknown error.
Cuda error 'find_pulse_kernel' in file 'd:/BoincSeti_Prog/sinbad_repositories/LunaticsUnited/SETI_CUDA_MB_exp/client/cuda/cudaAcc_pulsefind.cu' in line 925 : unknown error.
Cuda error 'find_pulse_kernel' in file 'd:/BoincSeti_Prog/sinbad_repositories/LunaticsUnited/SETI_CUDA_MB_exp/client/cuda/cudaAcc_pulsefind.cu' in line 925 : unknown error.
Cuda error 'cudaMemcpy(&flags, dev_find_pulse_flag, sizeof(*dev_find_pulse_flag), cudaMemcpyDeviceToHost)' in file 'd:/BoincSeti_Prog/sinbad_repositories/LunaticsUnited/SETI_CUDA_MB_exp/client/cuda/cudaAcc_pulsefind.cu' in line 1733 : unknown error.

The errors when running stock CUDA are the equally-well reported:

Work Unit Info:
...............
WU true angle range is :  0.415156
Optimal function choices:
-----------------------------------------------------
name                
-----------------------------------------------------
              v_BaseLineSmooth (no other)
            v_GetPowerSpectrum 0.00018 0.00000 
                   v_ChirpData 0.01270 0.00000 
                  v_Transpose4 0.00438 0.00000 
               FPU opt folding 0.00312 0.00000 
Cuda error 'find_pulse_kernel' in file 'c:/sw/gpgpu/seti/seti_boinc/client/cuda/cudaAcc_pulsefind.cu' in line 622 : unknown error.
Cuda error 'find_pulse_kernel' in file 'c:/sw/gpgpu/seti/seti_boinc/client/cuda/cudaAcc_pulsefind.cu' in line 627 : unknown error.
Cuda error 'find_pulse_kernel' in file 'c:/sw/gpgpu/seti/seti_boinc/client/cuda/cudaAcc_pulsefind.cu' in line 627 : unknown error.
Cuda error 'find_pulse_kernel' in file 'c:/sw/gpgpu/seti/seti_boinc/client/cuda/cudaAcc_pulsefind.cu' in line 632 : unknown error.
Cuda error 'find_pulse_kernel' in file 'c:/sw/gpgpu/seti/seti_boinc/client/cuda/cudaAcc_pulsefind.cu' in line 632 : unknown error.
Cuda error 'cudaMemcpy(&flags, dev_find_pulse_flag, sizeof(*dev_find_pulse_flag), cudaMemcpyDeviceToHost)' in file 'c:/sw/gpgpu/seti/seti_boinc/client/cuda/cudaAcc_pulsefind.cu' in line 1318 : unknown error.

F.

---

As for upgrading to 190.38, have managed to get 3 machines done so far. Just waiting on the others to finish off their cuda work. Highly recommended if you can do it.

Yes, upgrading nVidia drivers while you have CUDA work in your cache can cause problems.

I have Windows XP with BOINC running as a service, so I opened the 'Services' administration tool (services.msc), stopped the service, and set the startup type to Disabled. Then I was able to upgrade the drivers safely: check that everything was running smoothly in the nVidia control panel, copy the runtime DLLs, and restart BOINC in an orderly fashion. Worked for me.

@Richard - could you elaborate a little, please. Would these problems only occur if running as a Service (and what kind of problems)?

Surely. Recent BOINC clients delete every CUDA task in the cache if they don't detect any CUDA cards at startup (another of Raistmer's "be careful what you wish for" bug reports - you may remember my "big bug in v6.6.34" thread on boinc_alpha).

I think this can happen if BOINC starts up before the driver installation is complete. With the WinXP service mode, that's easy to avoid by setting the service to disabled for the driver-install restart. Vista has a 'delayed start' for services, which may be enough - except you'd never find out, because the CUDA question wouldn't arise. I'm not sure how you prevent a non-service mode BOINC v6 from running at startup, but you would be wise to do so: my only experience is v5 where you took the shortcut out of the 'Startup' program group, but nowadays I think it's GUI or registry.