The other problem with the Baseline Apps only affect the Laptops Occasionally.
That is a problem with the Baseline code, which I think Jason controls.
Petri's App doesn't work on those Laptops.

I haven't published any recent Mac builds of Cuda baseline yet apart from one old test build on a forum post, for a number of unrelated reasons (mostly time). If you're seeing issues with Cuda baseline builds from current source, you'll need to determine if the problems are:
- boincapi related (which typically manifest in errors after exit),
- build system related (Apple's changes of compiler and libraries)
- Cuda version including web driver change related, (possible, though doubtful IMO)
- a runtime/OS level change (possibly priority/timeouts of some sort)
- Something else (app code issue is possible, though less likely than above, and I'd need a smoking gun of some sort.)

Are you including nvcc --gencode entries during build on mac, targeted for 750ti (iirc ~ compute capability 5.0 (?) ) so as to embed PTX binaries ? or relying on the web driver to generate it on first run ? (this could be a difference fitting into multiple of the above slots, so they aren't entirely mutually exclusive conditions)

---

"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.

Well, I don't have a Mac Laptop, so, it would be difficult to test. The people at Beta are showing the entries though;
http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=72386
http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24674317
That's two for two, those are the only Laptops running the App as far as I know.
I have Never seen the problem on a Desktop GPU.
The line used on the App used by those machines was;

NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_20,code=sm_20 -gencode arch=compute_20,code=sm_21 -gencode arch=compute_20,code=compute_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52

The Line used on the 'Special' Apps with Toolkit 7.5 is;

NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52

I ALWAYS use the same Line. It's the Same line used with the x41p_zi App that doesn't have any problems with the 750Ti. I ONCE compiled an App without -gencode arch=compute_50,code=sm_50 to see what would happen. The results were the Card wouldn't work AT ALL with the Special App. This is Not good for reasons I'm sure you understand. One of these days I might compile a Special App without -gencode arch=compute_52,code=sm_52 just to see what happens with the 950s. I find it interesting the Baseline CUDA42 App doesn't have any problems with the 750Ti or the 950, and the highest gencode it has is code=sm_30.

So yes, All the current Apps are using the gencode for the 750Ti, except the CUDA42 App, because it is impossible to use anything higher than 30 with Toolkit 4.2. I even use -gencode arch=compute_61,code=sm_61 when compiling with Toolkit 8.

It appears I might have to go back to Darwin 15.4 and Driver 8.0.29 to make the 750Ti happy with x41p_zi3g.

IMO, for decades the fruit people have made their machines difficult, at best, to work with the rest of the world.

---

It appears I might have to go back to Darwin 15.4 and Driver 8.0.29 to make the 750Ti happy with x41p_zi3g.

OK, yeah gencode entries should be fine (naturally, just one possible variable eliminated).

Well anyway my characteristic spider-sense is jangling (again). If you run into the same issues sending you back to building on 15.4, then in part we're probably looking at OSX C-runtime, or Cuda Runtime thread safety issues pulling into line with ~2005 Windows (which was arguably inevitable).

Similar things *may* happen on the latest Linux Kernels, with slightly different symptoms, due to incorporation of revised blocklayer for nVME high bandwidth multithreaded scaling. If so, I'll probably have to find some time for comparative builds, such that we can accumulate some evidence to feed back into Boinc's library and standard buildsystem practices.

---

"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.

IMO, for decades the fruit people have made their machines difficult, at best, to work with the rest of the world.

Yes, digging into the issues, I landed on a developer Blog:

The unbearable fragility of modern OSX development

... bearing in mind he's coming from a simple utility developer direction, and talking mostly about app store publication, though certainly in a similar spirit to some of the challenges we have, and may still, run into.

---

"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.

My latest version (and the previous one too) zi3f-zi3g give 99%+ similarity on tests. One guppi vlar finds an extra signal (low power, low average) and my inconclusives is falling rapidly. The old ones from earlier version do persist a month or so in the inconclusives though until they are validated by a third computer.

When there's a Windows version ready for testing on Beta i'd be more than happy to give it a run.
Or better yet, as Rastmer says, submit it to Beta for testing by as many different OS & hardware combinations as possible.

---

Grant
Darwin NT

My latest version (and the previous one too) zi3f-zi3g give 99%+ similarity on tests. One guppi vlar finds an extra signal (low power, low average) and my inconclusives is falling rapidly. The old ones from earlier version do persist a month or so in the inconclusives though until they are validated by a third computer.

When there's a Windows version ready for testing on Beta i'd be more than happy to give it a run.
Or better yet, as Rastmer says, submit it to Beta for testing by as many different OS & hardware combinations as possible.

There'll definitely be wider alpha out before that, so keep an eye out. I'll be pushing Petri code toward stock as build system and users can actually support it without having to supply fire extinguishers AMD style.

---

"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.

I'll be pushing Petri code toward stock

The sooner the better IMHO; but as I understand it so far the hardware & OSs used for testing have been limited in number & scope?
The more the merrier- look at all the fun M$ have with their 100,000s of testers; and still issues manage to get through.

If it's looking as good as it appears to be from here, time to let Beta have a go at it- particularly with the older & slower hardware & hodgepodge of OSs & drivers.
Find out just what does & doesn't work, put a line in the sand & then you can go forwards (and backwards) from there & develop it further- but at least get the present application out there (if it's good enough). It's got to start somewhere, sometime. Now would be really nice... Pretty please, with sugar on top?
:-)

---

Grant
Darwin NT

I'll be pushing Petri code toward stock

The sooner the better IMHO; but as I understand it so far the hardware & OSs used for testing have been limited in number & scope?
The more the merrier- look at all the fun M$ have with their 100,000s of testers; and still issues manage to get through.

If it's looking as good as it appears to be from here, time to let Beta have a go at it- particularly with the older & slower hardware & hodgepodge of OSs & drivers.
Find out just what does & doesn't work, put a line in the sand & then you can go forwards (and backwards) from there & develop it further- but at least get the present application out there (if it's good enough). It's got to start somewhere, sometime. Now would be really nice... Pretty please, with sugar on top?
:-)

Not quite as the 'other camp' would paint. On the nVidia/CUDA side it's sheer manpower and resources. Frankly since the Guppi change nVidia is the underdog, simply because I have to work to eat [and there is ZERO real development help]. That's always a temporary measure though. I'd like it to be different, but well ---> Buy AMD?

---

"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.

but well ---> Buy AMD?

Too late for that- recently replaced one of my GTX 750Tis with a GTX 1070, and I've still got the other GTX 750Tis.
AMD have improved, but NVidia still have the lead in GPU hardware. Just need the software to unleash it's potential.

---

Grant
Darwin NT

but well ---> Buy AMD?

Too late for that- recently replaced one of my GTX 750Tis with a GTX 1070, and I've still got the other GTX 750Tis.
AMD have improved, but NVidia still have the lead in GPU hardware. Just need the software to unleash it's potential.

Well we'd all like that, but continuously seems I need to do something.

Maybe it's time for people to start coughing up actual dollars into one or another cause. My Coffers are Dry.

---

"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.

Well, I don't have a Mac Laptop, so, it would be difficult to test. The people at Beta are showing the entries though;
http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=72386
http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24674317
That's two for two, those are the only Laptops running the App as far as I know.
I have Never seen the problem on a Desktop GPU.
The line used on the App used by those machines was;

NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_20,code=sm_20 -gencode arch=compute_20,code=sm_21 -gencode arch=compute_20,code=compute_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52

The Line used on the 'Special' Apps with Toolkit 7.5 is;

NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52

I ALWAYS use the same Line. It's the Same line used with the x41p_zi App that doesn't have any problems with the 750Ti. I ONCE compiled an App without -gencode arch=compute_50,code=sm_50 to see what would happen. The results were the Card wouldn't work AT ALL with the Special App. This is Not good for reasons I'm sure you understand. One of these days I might compile a Special App without -gencode arch=compute_52,code=sm_52 just to see what happens with the 950s. I find it interesting the Baseline CUDA42 App doesn't have any problems with the 750Ti or the 950, and the highest gencode it has is code=sm_30.

So yes, All the current Apps are using the gencode for the 750Ti, except the CUDA42 App, because it is impossible to use anything higher than 30 with Toolkit 4.2. I even use -gencode arch=compute_61,code=sm_61 when compiling with Toolkit 8.

It appears I might have to go back to Darwin 15.4 and Driver 8.0.29 to make the 750Ti happy with x41p_zi3g.

So....
That didn't work out very well. The three problems seemed to be fixed in Yosemite with x41p_zi3g, but the 750Ti was producing Invalid Overflows. I tried it in Darwin 15.4 with the cuda 8 driver, but the Extreme Autocorrelation Peaks were back.

I decided to move to Darwin 15.6 and compile a new App there with Toolkit 7.5. I also decided to try that Gencode test. I compiled 3 Apps, 1 Normal, 1 leaving out the sm52. and 1 leaving out the sm50&52. Leaving out sm52 resulted in the App still working with the 750Ti and 950s. The App without sm50&52 fails though. I believe I've seen this Error before, it's either the same, or very close to, the Error you receive when you try to compile the Special App with -gencode arch=compute_30,code=sm_30 added;

...............
WU true angle range is :  0.422162
Sigma 3
Cuda error '(cudaBindTextureToArray( dev_gauss_dof_lcgf_cache_TEX, dev_gauss_dof_lcgf_cache, channelDesc))' in file 'cuda/cudaAcc_gaussfit.cu' in line 781 : invalid texture reference.

</stderr_txt>

I'll have to track down that Error and see if it's the same.
Now, it's my understanding you should be able to run a newer card with an older App, such as running any of the new cards with the cuda50 App. But, this App will not work even though it doesn't include the older sm30. The line used in the App that fails with this Error is;

NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37

Right now I'm running the Normal compile in 15.6 with driver 7.5.30 to see if the 750Ti Overflows are still present.

Well, I don't have a Mac Laptop, so, it would be difficult to test. The people at Beta are showing the entries though;
http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=72386
http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=24674317
That's two for two, those are the only Laptops running the App as far as I know.
I have Never seen the problem on a Desktop GPU.
The line used on the App used by those machines was;

NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_20,code=sm_20 -gencode arch=compute_20,code=sm_21 -gencode arch=compute_20,code=compute_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52

The Line used on the 'Special' Apps with Toolkit 7.5 is;

NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52

I ALWAYS use the same Line. It's the Same line used with the x41p_zi App that doesn't have any problems with the 750Ti. I ONCE compiled an App without -gencode arch=compute_50,code=sm_50 to see what would happen. The results were the Card wouldn't work AT ALL with the Special App. This is Not good for reasons I'm sure you understand. One of these days I might compile a Special App without -gencode arch=compute_52,code=sm_52 just to see what happens with the 950s. I find it interesting the Baseline CUDA42 App doesn't have any problems with the 750Ti or the 950, and the highest gencode it has is code=sm_30.

So yes, All the current Apps are using the gencode for the 750Ti, except the CUDA42 App, because it is impossible to use anything higher than 30 with Toolkit 4.2. I even use -gencode arch=compute_61,code=sm_61 when compiling with Toolkit 8.

It appears I might have to go back to Darwin 15.4 and Driver 8.0.29 to make the 750Ti happy with x41p_zi3g.

So....
That didn't work out very well. The three problems seemed to be fixed in Yosemite with x41p_zi3g, but the 750Ti was producing Invalid Overflows. I tried it in Darwin 15.4 with the cuda 8 driver, but the Extreme Autocorrelation Peaks were back.

I decided to move to Darwin 15.6 and compile a new App there with Toolkit 7.5. I also decided to try that Gencode test. I compiled 3 Apps, 1 Normal, 1 leaving out the sm52. and 1 leaving out the sm50&52. Leaving out sm52 resulted in the App still working with the 750Ti and 950s. The App without sm50&52 fails though. I believe I've seen this Error before, it's either the same, or very close to, the Error you receive when you try to compile the Special App with -gencode arch=compute_30,code=sm_30 added;

...............
WU true angle range is :  0.422162
Sigma 3
Cuda error '(cudaBindTextureToArray( dev_gauss_dof_lcgf_cache_TEX, dev_gauss_dof_lcgf_cache, channelDesc))' in file 'cuda/cudaAcc_gaussfit.cu' in line 781 : invalid texture reference.

</stderr_txt>

I'll have to track down that Error and see if it's the same.
Now, it's my understanding you should be able to run a newer card with an older App, such as running any of the new cards with the cuda50 App. But, this App will not work even though it doesn't include the older sm30. The line used in the App that fails with this Error is;

NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37

Right now I'm running the Normal compile in 15.6 with driver 7.5.30 to see if the 750Ti Overflows are still present.

The bind texture to array does not work unless there is a an exiting pre compiled array address present. The sm must be specified in the code.
I noticed that when I started running 780 and cuda 6.5.

---

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

Highert gencode

-gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_30,code=compute_30

The bold item is to generate a general PTX for any sm_30 or higher.

---

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

I see. Does it have to be a multiple of 10 or can it be something like, -gencode arch=compute_37,code=compute_37 or -gencode arch=compute_52,code=compute_52

I suppose that means if someone with a 1080 tries to run an App compiled with the following line it will fail?

NVCCFLAGS = --use_fast_math --ptxas-options="-v" --compiler-options "$(AM_CXXFLAGS) $(CXXFLAGS) -fno-strict-aliasing" -m64 -gencode arch=compute_32,code=sm_32 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52

For a trial build, isolation of issues rather than distribution, I would limit the embedded binary and PTX code just to the one GPU spec, for 750ti:

-gencode arch=compute_50,code=sm_50

Then you should still get a hybrid binary, but with only 5.0 PTX code, and 5.0 binary.

If still does something weird, then possibly looking at a cuda toolkit/library bug of some sort (possible), or a problem with the generated & embedded binary, or the driver that loads it.

There is an environment variable (iirc FORCE_PTX_JIT=1, or similar), that will force drivers to compile the PTX from forward compatible embedded source in the executable. (As opposed to just on first run when no match on embedded binaries is found). From forced JIT compilation on, the binary would reside in the driver cache, and may or may not have more success than the build time embedded binaries.

If forcing JIT compilation changes nothing, then less likely a toolkit issue. If it does change the situation in any functional way, then there is a system, driver, toolkit or library problem of some sort, for which the registered developer portal might need a visit.

---

"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.

Back to the inconclusive GBT validations, could someone please post the links to these tasks that have Extreme AC Peaks?
http://setiathome.berkeley.edu/result.php?resultid=5142839275
http://setiathome.berkeley.edu/result.php?resultid=5138991329
http://setiathome.berkeley.edu/result.php?resultid=5143457034
http://setiathome.berkeley.edu/result.php?resultid=5143131338
http://setiathome.berkeley.edu/result.php?resultid=5143118882

TIA

http://boinc2.ssl.berkeley.edu/sah/download_fanout/3d2/blc5_2bit_guppi_57449_45355_HIP81348_0017.14390.416.17.26.21.vlar
http://boinc2.ssl.berkeley.edu/sah/download_fanout/1ce/21au10ag.26901.20545.14.41.41
http://boinc2.ssl.berkeley.edu/sah/download_fanout/214/blc5_2bit_guppi_57449_43932_HIP78775_0013.26700.831.18.27.53.vlar
http://boinc2.ssl.berkeley.edu/sah/download_fanout/35/11au16aa.28481.85822.12.39.56
http://boinc2.ssl.berkeley.edu/sah/download_fanout/3a/blc5_2bit_guppi_57449_45695_HIP81348_OFF_0018.29291.831.17.26.236.vlar

Thanks Richard.
BTW, the latest Error I'm getting with LibreOffice 4.2.8.2 is;

BASIC syntax error.
Unexpected symbol: (.

That's after setting the security to Low (Not Recommended)
Updating Libcurl3
Installing JAVA7

Shouldn't have any Java dependency.

Is that an exact literal copy of the (double) symbol parenthesis-period? Does it give an error line number or function name?

I'll have a scan through the code and see what I can find.