Nice, I see it now. Hopefully the headbanging is over...

Not quite yet. We're probably on some good leads for the pulse variations, though that's the stickiest area in the whole codebase/algorithm (very few relevant science papers). So headbanging could continue for a bit, depending on if Petri finds something simple while I arrange for the more detailed dissection/analysis/autopsy.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Hello Gianfranco,

I see you've gotten 41p_zi3e running. I haven't had any success with Toolkit 7.5 in Darwin 15.4 or Ubuntu 14.04. I get the same Errors, and also get the same Error with Toolkit 8.0 with 15.4;
Undefined symbols for architecture x86_64:
"cudaAcc_initialize(float (*) [2], int, int, unsigned long, double, double, double, double, int, double, long, bool)", referenced from:
seti_analyze(ANALYSIS_STATE&) in seti_cuda-analyzeFuncs.o
ld: symbol(s) not found for architecture x86_64

Hi TBar,
I got the same error but Petri send me a new cudaAcceleration.cu that works correctly without the error.

Gianfranco

---

I don't want to believe, I want to know!

Hello Gianfranco,

I see you've gotten 41p_zi3e running. I haven't had any success with Toolkit 7.5 in Darwin 15.4 or Ubuntu 14.04. I get the same Errors, and also get the same Error with Toolkit 8.0 with 15.4;
Undefined symbols for architecture x86_64:
"cudaAcc_initialize(float (*) [2], int, int, unsigned long, double, double, double, double, int, double, long, bool)", referenced from:
seti_analyze(ANALYSIS_STATE&) in seti_cuda-analyzeFuncs.o
ld: symbol(s) not found for architecture x86_64

Hi TBar,
I got the same error but Petri send me a new cudaAcceleration.cu that works correctly without the error.

Gianfranco

I've sent that to TBar too now. Jason's already got it.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

There seems to be some version number confusion. Current minimum opencl_nvidia_mac requires OSX <min_os_version>110402</min_os_version>. From below it looks like you're asking for a max OSX version below the current minimum OSX version.

Anyone knows how this number translates into human-readable OS X version and how "lower than Darwin 15.4" Will be translated into <max_os_version> tag value?

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

There seems to be some version number confusion. Current minimum opencl_nvidia_mac requires OSX <min_os_version>110402</min_os_version>. From below it looks like you're asking for a max OSX version below the current minimum OSX version.

Anyone knows how this number translates into human-readable OS X version and how "lower than Darwin 15.4" Will be translated into <max_os_version> tag value?

If I read this correctly, 11.4.2 is the kernel version, so equates as OSX 10.7.5, Lion.

https://en.wikipedia.org/wiki/Darwin_(operating_system)

---

So, what restriction tag should looks like?

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

So, what restriction tag should looks like?

<max_os_version>150399</max_os_version> , or in other words, one less than 15.4?

Just thought I'd add that it was the DeskTops that began producing mostly Inconclusive results with Darwin 15.4. Most of the nVidia Macs are Laptops, and the Laptops began producing Inconclusives with Darwin 15.0. My own observations confirm the problem started with the Laptops Last Year around October, and is also noted here, We are aware of some issues users of Premiere Pro may experience after upgrading to OS X El Capitan.

Apparently the change in Darwin 15.4 was an attempt to 'correct' the problems that began with Darwin 15.0. The 15.4 update just finished the job that began with 15.0.

So, it should be
<max_os_version>149999</max_os_version>, right?
I'll pass it to Eric.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

We are close to the One Year Anniversary. Next month will be the One Year mark since the Apple nVidia Laptops began Producing mostly Incorrect results due to the OpenCL changes in El Capitan (Darwin 15.0). One can only guess how many of those Laptops managed to co-validate and send incorrect results into the database. One Year, thousands of machines...

The next Anniversary will be March 21st, that will be the One Year mark since the Apple nVidia Desktops also began producing incorrect results with Darwin 15.4. One can only wonder if the problem will still exist Mar 21st, it seems likely it will exist next month.

People using Apple nVidia Laptops might be interested to know there is only One result sent to the Database and used to search for ET. That result, called 'canonical', is usually the first listed result that is matched by another Host. Since your machine's GPU doesn't produce a matched result, it will Never be used as 'canonical'. Basically this means None of your nVidia GPU work will Ever be used in the search for ET. Basically you've wasted your GPUs time for the last Year. Fortunately, your CPU results are usually valid and don't have this problem. Unless you have one of those Laptops running Darwin 11.4.x (Lion) with an AVX CPU, in that case you are just wasting your AVX CPU's time.
Oh well, Happy Anniversary!

We are close to the One Year Anniversary. Next month will be the One Year mark since the Apple nVidia Laptops began Producing mostly Incorrect results due to the OpenCL changes in El Capitan (Darwin 15.0). One can only guess how many of those Laptops managed to co-validate and send incorrect results into the database. One Year, thousands of machines...

The next Anniversary will be March 21st, that will be the One Year mark since the Apple nVidia Desktops also began producing incorrect results with Darwin 15.4. One can only wonder if the problem will still exist Mar 21st, it seems likely it will exist next month.

People using Apple nVidia Laptops might be interested to know there is only One result sent to the Database and used to search for ET. That result, called 'canonical', is usually the first listed result that is matched by another Host. Since your machine's GPU doesn't produce a matched result, it will Never be used as 'canonical'. Basically this means None of your nVidia GPU work will Ever be used in the search for ET. Basically you've wasted your GPUs time for the last Year. Fortunately, your CPU results are usually valid and don't have this problem. Unless you have one of those Laptops running Darwin 11.4.x (Lion) with an AVX CPU, in that case you are just wasting your AVX CPU's time.
Oh well, Happy Anniversary!

So does someone have a fix? Or is the fix crunch other projects?

---

So does someone have a fix? Or is the fix crunch other projects?

I suppose that depends on your definition of 'Fix'. For myself, I'd say there has been a fix since January, back when the CUDA Baseline Apps were first posted at Crunchers Anonymous.
Those Apps worked fine under Anonymous platform with the Desktop Macs, but had strange and inconsistent results on the Laptops. Later it was discovered the Codebase was missing a 5 year old change in the BOINC API. That has been fixed and once again the Desktop Macs are working fine with the App at Beta. The Laptops are also working fine...mostly. It seems they are still giving strange and inconsistent messages in the stderr_txt. They seem to be finishing the task with Valid results, but Sometimes produce the line "A cuFFT plan FAILED, Initiating Boinc temporary exit (180 secs)" in the stderr_txt. Other times the messages don't appear at all, http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24706683...strange. That would be another one for Jason to comment on.

So, All the Machines being tested are finishing the tasks with Valid results in what would be considered normal run times for the Baseline CUDA Apps. Most would call that 'Fixed'. It's definitely much better than the situation that has existed over the last year.

It would be nice if More Machines were running the Apps at Beta. It would Also be nice if the Arecibo VLARs were NOT sent to the Baseline CUDA Apps. It has been known for 7 or 8 years those Arecibo VLARs don't work well with the Baseline App, there isn't any justification to test the App against a task that will never be run. All it does is annoy the tester with screen Lag and waste time. The BLC VLAR tasks don't produce screen Lag on my machines, the Arecibo VLARs do.

It would Also be nice if the Arecibo VLARs were NOT sent to the Baseline CUDA Apps.

Perhaps it's quite hard to implement.
Server doesn't know "baseline app".
It knows GPU app. So VLAR could be either sent to GPU app or not. Cause some of GPU apps support VLAR and need testing to support it better we have situation we have. Ultimately host will crunch with capable app.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Unfortunately the only Mac nVidia Apps at Beta that consistently produce the Correct results are the CUDA Apps. If you try one of the other Apps you will receive results such as this, Validation inconclusive (53). I don't see any advantage in having a tester waste a day, or more, on running tasks that produce the wrong results and won't be used on Main anyway.

Aren't we supposed to lose Arecibo tasks anyway? Then why are we testing Arecibo VLARs that are an endangered species when all they do is annoy the tester? Again, the BLC VLARs don't annoy the tester, and are not an endangered species.

Aren't we supposed to lose Arecibo tasks anyway?

The last I remember hearing is Arecibo was "just" not running as often and was under consideration for shutdown, unless funding was found.

Either way, we'd end up in a situation similar to the end of v7- waiting on the last tasks to run and validate before being able to ignore it....

---

Unfortunately the only Mac nVidia Apps at Beta that consistently produce the Correct results are the CUDA Apps.

The same situation - too hard to separate. You looking only into OS X, but VLAR either enabled or disabled for GPU apps, not on the OS basis.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Nevermind. I just solved my 14 hour Arecibo VLAR problem. I set them to use the x41p_zi3f App. It was either that or Abort them. For anyone else attempting to test Mac Apps for Main, that finds themselves with up to 50 annoying tasks that take an hour a piece, and will never be run on Main or anywhere else soon, I'd just Abort most of them. Absolutely No Good Reason to waste a Day, or 2, on Tasks that will never be run anywhere soon.

I'd like to remind certain people that most people at SETI don't have the latest $500 GPUs that don't have problems with these tasks. The Arecibo VLARs were banned from Main for Good reason. Hopefully they will be removed from the face of the Earth soon, strange how their replacements don't have this problem.

strange how their replacements don't have this problem.

There is no "VLAR replacements". GBT targeted observations have different configuration hence different longest PoT arrays and hence different performance with existing code. But they are in no way "Arecibo VLAR replacement", they are just another data for processing.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Eric implemented plan class restrictions. Please check if affected Macs now don't get OpenCL NV work.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

@TBar,

I just Upgraded SETI Main on Andromeda to your CUDA75 application. (Upgraded from CUDA65.) I followed the directions to copy the three files into the Projects' Folder, then reinstalled BOINC. Changed BOINC to Allow New Work for SETI, picked up a few new Units; but, they still show as CUDA65... Is this normal??? Shouldn't they show as CUDA75?

I Opened the Appinfo.xml and checked, and the CUDA75 info does show... But the Units reflect as CUDA65.


TL

[EDIT:]

They seem to be running faster, though. Just completed four Units, (2 per card), and roughly 36.5 min per Unit.


TL

---

TimeLord04
Have TARDIS, will travel...
Come along K-9!
Join Calm Chaos