Thanks Jason, two machines working and crunching again, third waiting new GPU.

Yes, just need to include an app_info in the package.
Incidentally, the file doesn't appear to be true xml if the order of entries are significant - the containers don't appear to be very hierarchical.

yeah, lol, It's boinc's 'special' xml format so that we don't have to use well hardened and optimised xml libraries from third parties.

---

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

Hey Jason, Will there ever be an optimized installer for LINUX?

---

I Desire Peace and Justice, Jim Scott (Mod-Ret.)

Hey Jason, Will there ever be an optimized installer for LINUX?

Perhaps, though it may look a bit different. As Linux and OSX come more into line build-wise, non-stock packaging and deployment to the website will become more or less automated. Once I can press a button, build all the flavours on the platforms, regression test, and deploy, probably some kindof opt-in autoupdate checker + manual check for updates button needs to go somewhere.

Naturally working applications trump infrastructure for the time being, but definitely getting closer to the point where I can put up a roadmap of where X-branch is headed. Last predictive roadmap I did for Lunatics worked out pretty well on point with what actually ended up happening across the developers involved, but now with v8's sudden appearance we're well off the edge of this old diagram:

http://lunatics.kwsn.info/index.php/topic,1085.msg36185.html#msg36185

---

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

Update: an initial build went to Eirc, with big questionmarks as to what the minimum kernal / library requirements would be. He's pushed it on Beta as a probe, and found the expected library issues with RHEL4. I've responded I'll do some research this weekend and work out how to minimise the build count but maximise the distro coverage, using the available hosts + VMs.

---

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

Thanks Jason.

---

I Desire Peace and Justice, Jim Scott (Mod-Ret.)

Is there a preferred driver for the x41zi app?

I seem to be seeing a lot more invalids (-9 result_overflow) since I started using x41zi. I am currently using version 355.06 of the driver which seemed to work fine with the MB-V7 app.

@dsh

x41zi with Nvidia driver version 352.41 running smoothly so far. 80+ valid with 0 invalid. Yes, I notice (perhaps) a few more result_overflow instances but those are not necessarily "invalid" if the wingman reports the same. The few that I spot-checked were exiting with spike count > 30 .

---

Indeed, Shouldn't be getting any invalids (which ís not the same as -9 overflow results).

---

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

358.16 also works with Ubuntu 15.10 and x41zi

Indeed, Shouldn't be getting any invalids (which ís not the same as -9 overflow results).

I have not checked every result but the ones I have checked all show -9 overflow with spike counts around 30 while the two results that were marked as valid had low spike counts. Perhaps they are not the same as invalids but I would think the results could certainly be called non valid :).


Thank you Jamie and Gene. I will start with the newer version first and see what happens.

Oh certainly something odd going on if you see spike overflows and your wingmen don't, no argument there.

---

"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've been running a GTX 750Ti and GTS 250 with driver 337.25 in Ubuntu 14.4 and they seem to be working. The GTS 250 is running about the same as it did in OSX with the old CUDA 5.0 & 5.5 though, about twice as slow as it should be running. The 750Ti seems to be working normally though, http://setiathome.berkeley.edu/results.php?hostid=7258715&offset=40

Yes anything PreFermi will suffer a pretty big penalty after Cuda 3.2, where it will work at all. With Eric have been trying to establish the most appropriate Cuda versions, and looks like it might be 3.2 and 4.2 as with Windows Legacy support. Comprehensive support may mean setting up a bunch of VM's in Due course, since it seems both environments are a bit sensitive to dependencies.

---

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

...With Eric have been trying to establish the most appropriate Cuda versions...

Well, when using the real OS, you don't have much of a choice in OSX. Every CUDA between CUDA 4.2 and 6.5 Fails with the NVCC Error concerning the option -dumpspecs, you simply can't compile any CUDA version in between using Xcode. I think there is a little more going on than just environments. In my testing with the GTS 250 using the same version of OSX, the very similar CUDA 5.0 takes Twice as long to finish the tasks as the 4.2 version that was complied using Xcode. My attempts with CUDA 5.0 Fails when using Xcode with the fatal -dumpspecs Error. I suspect the old 5.0 App (and 5.5) wasn't compiled using Xcode, and takes twice as long to run as the App compiled with Xcode. I vote to simply using the Real OSX with Xcode, seems to work better and there just happens to be a couple OSX Apps already tested that seem to work almost perfectly. There is a reason I've posted CUDA 4.2 and 6.5, it's what works using the real OSX and Xcode. Meanwhile, a large number of Apple nVidia Laptops continue to submit work results with very high rates of Inconclusive judgements. Also, I think I've found over a dozen avx machines running Darwin 11.4.2 that are submitting invalid CPU tasks at a rate exceeding what would be expected when considering the penalties....thousands of invalid CPU results to go along with those nVidia results.

Well, here it is; setiathome_x41zi_x86_64-pc-linux-gnu_cuda42
http://setiathome.berkeley.edu/result.php?resultid=4763488393
Seems to be working fine on both cards;
http://setiathome.berkeley.edu/result.php?resultid=4763488378
http://setiathome.berkeley.edu/result.php?resultid=4763487976
http://setiathome.berkeley.edu/result.php?resultid=4763488368

Definitely 2,265.99 secs is better than 4,315.15 secs on the GTS 250.
It's still Slow, but not Slow x2 ;-)

It was compiled in Ubuntu 11.04 and now working in Ubuntu 14.04 with driver 337.25. It appears both cards are running around 85% GPU load. We'll see how it does...

Yeah It's looking like Cuda 4.2 might well be the version of choice for older Linux Kernels too (even if 3.2 may be a better choice for the Compute capability 1.0-1.3 cards, We'll see, will have to weight the cost/benefits of extra builds). Brings us a little closer to having the 3 main platforms in line. Then it's open season on build automation, Petri's and other optimisations into mainstream.

With the Cuda Streams to go in, Cuda and driver versions should matter less, though there will always remain the compute capability 1.0 8800's that will work with none of the big new stuff, so will have to keep some old version codepath for the time being.

Roadmap will make sense next (when I can get to that). Petri's aware of parts of where X-Branch is going next (in x42) having given things a big boost on the multibeam-Cuda app side. Illustrating the scope so that others can pitch in and lend a hand is probably going to be next priority.

---

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

One of the advantages to using the CUDA 4.2 App is it works on the Maxwell cards whereas the CUDA 3.2 App will produce bad results when run on a Maxwell. If some Maxwell happens upon the 4.2 App it won't cause any harm. It appears the 4.2 App is running about a minute slower on the 250 in Ubuntu than in OSX, otherwise All looks well. In fact, the GTX 750Ti appears to be running about the same as it did with the CUDA 6.0 App, the GTS 250 is around Twice as fast as with 6.0, and both cards have run All day without producing a single Inconclusive result, http://setiathome.berkeley.edu/results.php?hostid=7258715&state=3

Maybe I should post it in the usual location and see how it works on other machines.

Maybe I should post it in the usual location and see how it works on other machines.

Good idea. With as many unknowns to tie up, as there are, before build system and deployment automation becomes real, probing what works and what doesn't helps polishing things to the point release becomes easier (particularly release documentation). Probably more gaps will appear, but getting closer.

---

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

The CUDA 4.2 App is posted here; http://www.arkayn.us/forum/index.php?topic=197.0
So far it has been working perfectly in Ubuntu 14.04 with driver 337.25 from here;
http://www.nvidia.com/object/linux-amd64-display-archive.html