Remember this?

Message 54739 - Posted: 21 Jul 2015, 7:51:52 UTC - in response to Message 54737.

Wrong advise for OpenCL MultiBeam app. It will produce incorrect results with driver less than 350.xx on FERMI and up. Hence usage lower driver versions is completely restricted now. Reverting to 347 means no more work for this app at all.


Sorry, your blacklist didn't mention 347, so I thought it was still okay. But I was pointing out that there does seem to be something strange going on with the newer NV drivers and GUI unresponsiveness.


Worth to get direct confirmation or reverse against 347 indeed. For now such hosts just will not get MB work. Maybe some volunteers to dig already recived results here on beta?
____________
News about SETI opt app releases: https://twitter.com/Raistmer

Seems it's a bit more than a theory, unless something has changed.
Sounds like you might have a problem trying the same driver Eric is using, I suppose you could use Anonymous platform...

BTW , We are discussing the Current OpenCL nVidia Multibeam App 7.08(opencl_nvidia_sah) at BETA. That App Is Not on Main.

The reversion to 347 was because of 2 issues

The first was with boo_l 2. That was resolved with Lunatics v0.43b

The second was with GUI unresponsiveness.

I've not seen that recently due to the installation of Process Lasso which prevents seizure of the system by a work unit.

If I don't use that, the system does become sluggish. Which usually reminds me to turn it on.

I don't know why Eric's system is throwing out invalids with the new drivers.

---

Eric is using driver 346.46, http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=20041971.
The Developer has stated;

Wrong advise for OpenCL MultiBeam app. It will produce incorrect results with driver less than 350.xx on FERMI and up.

and,

...lower driver versions is completely restricted now.

meaning you probably can't use the App with less than 350.xx. Don't know, I'm still troubleshooting Ubuntu, but, it certainly sounds as though drivers are restricted.

Which poses a Serious problem for Macs as the Drivers are built into the system and usually can't be changed. So, trying to blame the release on Macs is somewhat questionable. I suspect it has to do with having to use the newer drivers on All systems or face incorrect results. Not a good choice.

They are sorta related

They are sorta related

How? IIRC the data is a different frequency.

---

Same raw data, different everything else.

Chalk and cheese.

Keep them separate, please, and read the question before trying to answer it.

They are sorta related

Interesting isn't it. I have been testing Ubuntu with AMD driver 15.5 running APs for the last couple of days and have scored 2 Invalids. I Never scored those using AMD Driver 14.6.
I'm upgrading Ubuntu and trying AMD Driver 15.7 on my last few APs, we'll see how it goes.
Need More APs...

Oh Nooooo,
Error! Bad return status for module build on kernel: 3.19.0-28-generic (x86_64)

I think I remember this now. I think I'm already listed on this particular Bug list.
Not good...

The new OpenCL-App sucks on normal and shorty MB-WUs. Unless there is a possibility of crunching only VLARs on the new OpenCL-App and crunching the normal and short MB-WUs on CUDA-App, the use of the new app is out of question for me...

[edit]
And yes, my driver-app-combo only produced valid results, although way to slow.

---

Aloha, Uli

Whilst I know people get carried away and start talking about other things as Richard has asked, lets try and keep questions about AP and MB separate.

Makes life easier for all

Thank you.

---

Thanks Richard, Grumpy Swede and others for trying to get this thread back on topic. Looking forward to the next round of work

---

The new OpenCL-App sucks on normal and shorty MB-WUs. Unless there is a possibility of crunching only VLARs on the new OpenCL-App and crunching the normal and short MB-WUs on CUDA-App, the use of the new app is out of question for me...

[edit]
And yes, my driver-app-combo only produced valid results, although way to slow.

Well, app not "new" in strict terms, it's just regular OpenCL MB build for NV cards that put on Beta servers this time initially by mistake and kept there "for fun&knowledge" ;)
VLAR give more load on PulseFind part of processing while over ARs, especially VHAR, have increased share of FFT. On my NV hardware (pre-FERMI) slowdown from oclFFT versus cuFFT outweights all possible improvements in apps own kernels. It's the first time when on some NV hardware and some AR that changed in such degree that gives overall speedup.
Try to play with oclFFT switches, I hope some improvement is possible there. But in general, no adequate alpha testing of OpenCL NV builds are done long time already. And it's not main direction of MB development for now.

It was a productive run overnight and all caches are full to their 10 day limit.

---

Kitties are dishin' on the AP run.....
Nom nom nom.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

It was a fine run but the party seems to be over.

---

Astropulse science database marvin, just went KAPOOF!!! or at least Disabled

Edit: And there went download server 2 vader KAPOOF!!! or at least Disabled

I have been blaming everything that happens on The Pope. As he is in the Philadelphia area for a visit & it is causing major havoc.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Astropulse science database marvin, just went KAPOOF!!! or at least Disabled

Edit: And there went download server 2 vader KAPOOF!!! or at least Disabled

I have been blaming everything that happens on The Pope. As he is in the Philadelphia area for a visit & it is causing major havoc.

He's not in the Philadelphia area yet. He's still in New York, and will depart for Philadephia September 26, 2015 at 8:40 am.

http://www.popefrancisvisit.com/schedule-category/pope-francis-visit-new-york-schedule/

I know but the prep for his arrival has been effecting everyone for weeks & this week with the few million extra people in the area traffic has been worse than normal. Normally traffic is really awful.
So I figure all this craziness might be effecting the servers as well.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

With the weekend coming it does not bode well for the AP servers. For the moment I will keep the panic small.

---

For the last few hours the SSP claims to be splitting APs but I haven't been able to snag any.

---

For the last few hours the SSP claims to be splitting APs but I haven't been able to snag any.

Perhaps it's because the science database is disabled. In saying that though I have seen at least one resend, unfortunately it wasn't on my computer

---

For the last few hours the SSP claims to be splitting APs but I haven't been able to snag any.

Perhaps it's because the science database is disabled. In saying that though I have seen at least one resend, unfortunately it wasn't on my computer

Not even a resend here for about 13 hours now.
Have sent messages to the usual suspects regarding the server jobs that are down.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster