My GTX560 Ti & dual GTX550 Ti rigs don't mind the VLARs at all but overnight my triple 9800 rig started on its lot with very bad results eventually locking it up while I slept, so they all got aborted this morning on that setup.

Cheers.

---

<snippage occured>

*EDIT* - Bill, out of curiosity, when was the last time you saw a VLAR running on one of your nVidia GPUs?[/quote]

3 are running concurrently right now. Ran out of regular
gpu work units during the outage so shipped a few over from the cpu.

Why? And yes I did receive some for the Nvidia gpu during the last server hiccup. Did those too on the gpu. Run times were posted in an earlier post.

Why? And yes I did receive some for the Nvidia gpu during the last server hiccup. Did those too on the gpu. Run times were posted in an earlier post.

b/c a number of us haven't seen any VLARs crunch on our GPUs since the "fix" was put in place. in the Bug in server affecting older BOINC clients with NVIDIA GPUs thread, someone was asking troubleshooting questions a few days ago. after solving his problem, he made mention of some VLARs, which briefly led Erik Corpela to think that the VLARs were broken again. but it was quickly pointed out that his VLARs occurred on August 11th, before the fixes were put into place. so it seemed like a false alarm, but then you mentioned having VLARs on your nVidia GPU, so now i'm wondering again...

to be clear, i'm not having problems with this phenomenon myself.

---

For anyone whom I might have confused, I have received
zero vlars for my Nvidia gpu since Eric's last fix on the
server bug. I will and do transfer some to my gpu to keep
it busy if I run out of regular work units and cannot get
any from the servers.
My apologies If I gave any other impression.

8/21/2012 7:50:44 PM | SETI@home | Started download of astropulse_6.04_opencl_nvidia_AUTHORS
8/21/2012 7:50:45 PM | SETI@home | Finished download of astropulse_6.04_opencl_nvidia_AUTHORS
8/21/2012 7:50:45 PM | SETI@home | Started download of astropulse_6.04_opencl_nvidia_COPYING
8/21/2012 7:50:48 PM | SETI@home | Finished download of astropulse_6.04_opencl_nvidia_COPYING
8/21/2012 7:50:48 PM | SETI@home | Started download of astropulse_6.04_opencl_nvidia_COPYRIGHT
8/21/2012 7:50:50 PM | SETI@home | Finished download of astropulse_6.04_opencl_nvidia_COPYRIGHT
8/21/2012 7:50:50 PM | SETI@home | Started download of astropulse_6.04_windows_intelx86__opencl_nvidia_100.pdb
8/21/2012 7:53:13 PM | SETI@home | Temporarily failed download of astropulse_6.04_windows_intelx86__opencl_nvidia_100.pdb: transient HTTP error
8/21/2012 7:53:13 PM | SETI@home | Backing off 3 min 33 sec on download of astropulse_6.04_windows_intelx86__opencl_nvidia_100.pdb
8/21/2012 7:53:13 PM | SETI@home | Started download of libfftw3f-3.dll

Ok, I'm stumped. What's with the nvidia AUTHORS/COPYING/COPYRIGHT, etc stuff? Also: What the heck is the last line there? (the .dll)

---

8/21/2012 7:50:44 PM | SETI@home | Started download of astropulse_6.04_opencl_nvidia_AUTHORS
8/21/2012 7:50:45 PM | SETI@home | Finished download of astropulse_6.04_opencl_nvidia_AUTHORS
8/21/2012 7:50:45 PM | SETI@home | Started download of astropulse_6.04_opencl_nvidia_COPYING
8/21/2012 7:50:48 PM | SETI@home | Finished download of astropulse_6.04_opencl_nvidia_COPYING
8/21/2012 7:50:48 PM | SETI@home | Started download of astropulse_6.04_opencl_nvidia_COPYRIGHT
8/21/2012 7:50:50 PM | SETI@home | Finished download of astropulse_6.04_opencl_nvidia_COPYRIGHT
8/21/2012 7:50:50 PM | SETI@home | Started download of astropulse_6.04_windows_intelx86__opencl_nvidia_100.pdb
8/21/2012 7:53:13 PM | SETI@home | Temporarily failed download of astropulse_6.04_windows_intelx86__opencl_nvidia_100.pdb: transient HTTP error
8/21/2012 7:53:13 PM | SETI@home | Backing off 3 min 33 sec on download of astropulse_6.04_windows_intelx86__opencl_nvidia_100.pdb
8/21/2012 7:53:13 PM | SETI@home | Started download of libfftw3f-3.dll

Ok, I'm stumped. What's with the nvidia AUTHORS/COPYING/COPYRIGHT, etc stuff? Also: What the heck is the last line there? (the .dll)

Looks like the new AP-for-Nvidia stock application was released today. You are getting all the files necessary to run it. That's a first-time only event for a new application. You are running stock, so you get it automatically if your prefs are set for "use Nvidia" and AP6.

---

Another Fred
Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop.

Oh cool! Thanks for the help, bud :D

---

So, how to get this new app for Nvidia OpenCL AstroPulse if you are running current Lunatics stuff on an anonymous platform?

Keith

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

So, how to get this new app for Nvidia OpenCL AstroPulse if you are running current Lunatics stuff on an anonymous platform?

Keith

Why would you want to change, you're already running r1316, Stock 6.04 is r1316 too.

Claggy

So, how to get this new app for Nvidia OpenCL AstroPulse if you are running current Lunatics stuff on an anonymous platform?

Keith

Why would you want to change, you're already running r1316, Stock 6.04 is r1316 too.

Claggy

i'm not sure i understand what you're saying...the r1316 build didn't appear until 7/6/12, long after the most current Lunatics installer v0.40 was released (which included no OpenCL apps, let alone any apps on the r1316 build). if Keith is running the latest Lunatics installer, then he has an app_info.xml and is running anonymous platform. won't that prevent his host from automatically DLing OpenCL AP tasks for his nVidia GPU, even if APv6 are checked in his web preferences? doesn't this new OpenCL AP app have to be manually placed in the SETI@Home data directory, and isn't an entry required in the app_info.xml file in order to reference this new app and receive work for it?

Keith, see Raistmer's first post in THIS thread for a link to the Lunatics webpage that has the new OpenCL app available for download. that thread i linked you to also have a sample app_info.xml entry for nVidia GPUs in the 2nd post.

---

He already have the app, one of his tasks:
http://setiathome.berkeley.edu/result.php?resultid=2566706424

AstroPulse v.6
Non-graphics FFTW USE_CONVERSION_OPT
Windows x86 rev 1316, V6 match, by Raistmer with support of Lunatics.kwsn.net team. SSE2


Obviously he manually added it.

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

I did not know that. I only saw the News announcement of new Nvidia OpenCL AstroPulse apps to be made available shortly after the ATI ones were sent out as stock apps. Would have been less confusing if someone, somewhere had mentioned that the stock 6.04 app was r1316.

Cheers, Keith

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

The ucb Routers page, along with all the Cricket Graphs are down.

Claggy

---

I would like to make one message because of the .vlar WUs.

I let run CUDA WUs since the project admins decided to send out a CUDA application.
Immediately I bought only because of SETI@home NVIDIA GPUs. ;-D

The project admins decided not to send .vlar WUs to NVIDIA GPUs (this are SETI@home Enhanced (MultiBeam) WUs with < 0.12 AR).
Because they slow down (other daily work on) the whole machine.

I think maybe because of: The member could think: "Hey, what's up?" - and will never again crunch SETI@home WUs.

The most members of SETI@home (maybe 95 %) let run the stock applications.

The stock 6.08_cuda up to 6.10_cuda_fermi applications calculate very bad/long this .vlar WUs.

Also on pre-Fermi GPUs the calculation is very slow.

I can't remember which application it was, maybe CUDA_V12 or x32f..
On my machine E7600 with GTX260 O/C:
A shorty: 2 minutes (120 seconds)
A normal 0.448x AR WU: 8 minutes and 20 seconds (500 seconds)
A 0.12x AR WU (which will be send): 25 minutes and 8 seconds (1508 seconds)
< 0.12 AR WU (.vlar WU, not send to NVIDIA GPUs): 1 hour and 30 minutes (5400 seconds)

This mean between normal (0.448x) and nearly VLAR WU (0.12x) the time is x ~ 3.

A .vlar WU would mean x ~ 10.8 longer than a normal AR WU. Wasted performance.


Maybe in future the project admins decide to send out .vlar WUs to Fermi and later GPUs - and still not to pre-Fermi GPUs (if this is possible with the server software).
If the upcoming stock S@h v7 CUDA application calculate very well this kind of WUs on Fermi+ GPUs.


* Best regards! :-) * Sutaru Tsureku, team seti.international founder. * Optimize your PC for higher RAC. * SETI@home needs your help. *

---

The Cricket Graphs are back, but are empty of fresh data,

Claggy

---

Maybe in future the project admins decide to send out .vlar WUs to Fermi and later GPUs - and still not to pre-Fermi GPUs (if this is possible with the server software).
If the upcoming stock S@h v7 CUDA application calculate very well this kind of WUs on Fermi+ GPUs.

Even though Fermi and later don't seem to have to many problems with them, their increased computation times (3-5 times longer than average) really throw the DCF out a lot, so I can't see the point in allowing them back ATM.

Cheers.

---

A reply to some points made by Sutaru

I would like to make one message because of the .vlar WUs.

I let run CUDA WUs since the project admins decided to send out a CUDA application.
Immediately I bought only because of SETI@home NVIDIA GPUs. ;-D

The project admins decided not to send .vlar WUs to NVIDIA GPUs (this are SETI@home Enhanced (MultiBeam) WUs with < 0.12 AR).
Because they slow down (other daily work on) the whole machine.

bill- If this is a problem then yes, the offending work units should not be crunched on the gpu.

I think maybe because of: The member could think: "Hey, what's up?" - and will never again crunch SETI@home WUs.

bill - If those people are so easily dissuaded from crunching for SETI
without even investigating as to why this is happening and how to fix the problem then it's probably for the best that they don't do any Boinc project work at all because they will eventually run into problems with any project they choose.

The most members of SETI@home (maybe 95 %) let run the stock applications.

The stock 6.08_cuda up to 6.10_cuda_fermi applications calculate very bad/long this .vlar WUs.

bill - Yes the work units take longer. That is not bad unless pc sluggishness
or errors are a problem. Back in the beginning of the project all work units used to take a long time. The work still needs to be done though.

Also on pre-Fermi GPUs the calculation is very slow.

I can't remember which application it was, maybe CUDA_V12 or x32f..
On my machine E7600 with GTX260 O/C:
A shorty: 2 minutes (120 seconds)
A normal 0.448x AR WU: 8 minutes and 20 seconds (500 seconds)
A 0.12x AR WU (which will be send): 25 minutes and 8 seconds (1508 seconds)
< 0.12 AR WU (.vlar WU, not send to NVIDIA GPUs): 1 hour and 30 minutes (5400 seconds)

This mean between normal (0.448x) and nearly VLAR WU (0.12x) the time is x ~ 3.

A .vlar WU would mean x ~ 10.8 longer than a normal AR WU. Wasted performance.

bill - Can't agree. The vlar will take even longer to work on a cpu than a gpu.
To me crunching a work unit faster is better. If your gpu is not busy doing any other work units, why not let it do vlars if they cause no problems.

Maybe in future the project admins decide to send out .vlar WUs to Fermi and later GPUs - and still not to pre-Fermi GPUs (if this is possible with the server software).

bill - That would be excellent

If the upcoming stock S@h v7 CUDA application calculate very well this kind of WUs on Fermi+ GPUs.

bill - Hopefully. I have no objection to aborting vlars, or any other type of work unit, if they cause problems
on the client computer. Taking longer to run is not a problem in and of itself,
though.

* Best regards! :-) * Sutaru Tsureku, team seti.international founder. * Optimize your PC for higher RAC. * SETI@home needs your help. *

I accept that VLAR wu do take longer than `normal`
Though the longest i have seen one take on a 7970 is 25 minits (after i got it set up right)
I am willing to crunch nothing but VLAR if it was possible to do it.
Though i have not seen any heer since the latest problem was fixed.

Even though Fermi and later don't seem to have to many problems with them, their increased computation times (3-5 times longer than average) really throw the DCF out a lot, so I can't see the point in allowing them back ATM.

Cheers.

I don't think anyone, including myself, was advocating allowing them "back in"
at the moment. It would be nice if they could be allowed by choice, like the AP's.

As for screwing up the DCF to the point where it causes problems, that could probably be gotten around with a bit of programming. OTOH, if it remains that
vlars never get sent to Nvidia gpu's, I can live with that too, they'll get done eventually.

A .vlar WU would mean x ~ 10.8 longer than a normal AR WU. Wasted performance.

bill - Can't agree. The vlar will take even longer to work on a cpu than a gpu.
To me crunching a work unit faster is better. If your gpu is not busy doing any other work units, why not let it do vlars if they cause no problems.

Sure, a GPU doing a VLAR might be better than an idle GPU (depending from your point of view), but if for a CPU it pretty much doesn't matter, if it's cruching a VLAR or a normal-AR task while the GPU is x times slower on VLAR, you are waisting performance if you send VLARs to a GPU. It's better for the project that a GPU do few 0.44 WUs instead of 1 VLAR. And it's up to the user to set his cache high enough that his card never idle (OK, not easy with the current load on servers, but that's another thing).

---