Well.... I do have a nicely working copy of x41p_zi3k+ for OSX. In fact, it seems to be working slightly better than the Linux version. Just finishing testing on the CUDA 75 version so it will work with Yosemite. The problem is it will need the CUDA 7.5 Libraries, there is a noticeable difference between the CUDA 6.5 and 7.5 Libraries with the App. So, unless someone can Host the 7.5 Libraries, everyone is going to have to download the 7.5 Toolkit and Extract the Libraries. Right now setiathome_x41p_zi3k+_x86_64-apple-darwin_cuda75 is working well in El Capitan with the CUDA 8.0 driver.

Well.... I do have a nicely working copy of x41p_zi3k+ for OSX. In fact, it seems to be working slightly better than the Linux version. Just finishing testing on the CUDA 75 version so it will work with Yosemite. The problem is it will need the CUDA 7.5 Libraries, there is a noticeable difference between the CUDA 6.5 and 7.5 Libraries with the App. So, unless someone can Host the 7.5 Libraries, everyone is going to have to download the 7.5 Toolkit and Extract the Libraries. Right now setiathome_x41p_zi3k+_x86_64-apple-darwin_cuda75 is working well in El Capitan with the CUDA 8.0 driver.

Can double check the legals and look at hosting the large files on the weekend (compressed or otherwise). Wrestling with work, though will likely want to be comparing WIn/Linux/Mac performance with the 980 myself in due course.

---

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

...Can double check the legals and look at hosting the large files on the weekend (compressed or otherwise). Wrestling with work, though will likely want to be comparing WIn/Linux/Mac performance with the 980 myself in due course.

I just checked at C.A. and there is a copy of libcufft.7.5.dylib in the Alpha section bundled with the old "Baseline App". I think it has the RT file included. I haven't tested it yet, perhaps that file can be used even if it does has the old App included. The way I remember, the only problem I had running the Special App in Yosemite with the 7.5 driver was a few Overflows with the 750Ti. I don't have the 750Ti in the Mac now, so, I don't expect any problems in Yosemite. I was going to swap over to Yosemite later tonight.

...Can double check the legals and look at hosting the large files on the weekend (compressed or otherwise). Wrestling with work, though will likely want to be comparing WIn/Linux/Mac performance with the 980 myself in due course.

I just checked at C.A. and there is a copy of libcufft.7.5.dylib in the Alpha section bundled with the old "Baseline App". I think it has the RT file included. I haven't tested it yet, perhaps that file can be used even if it does has the old App included. The way I remember, the only problem I had running the Special App in Yosemite with the 7.5 driver was a few Overflows with the 750Ti. I don't have the 750Ti in the Mac now, so, I don't expect any problems in Yosemite. I was going to swap over to Yosemite later tonight.

Yes, will be a juggle here as well. At least I preserved my el Capitan install alongside Sierra. Unfortunately I did not preserve the Yosemite install that came on the machine, and don't have installation media for that. Are media available for older versions via Apple ? Bootcamp on el Capitan and Sierra seems to not work or be supported on this older Mac Pro, so have been using rEFInd instead (fine). Would not mind have some physical media in case of emergency anyhow (whichever versions)

---

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

Yes, will be a juggle here as well. At least I preserved my el Capitan install alongside Sierra. Unfortunately I did not preserve the Yosemite install that came on the machine, and don't have installation media for that. Are media available for older versions via Apple ? Bootcamp on el Capitan and Sierra seems to not work or be supported on this older Mac Pro, so have been using rEFInd instead (fine). Would not mind have some physical media in case of emergency anyhow (whichever versions)

The last time I dealt with that situation it was easy to download the Older OS Installer if you are registered as having "purchased" your Free copy earlier. Just go to the App Store App and Download it from your Purchased Tab. If you never Downloaded the Older Installer back when it was current it's worse than pulling teeth to get a copy now. That was well over a year ago. I also found they have Time Limits on the Installers, some of my older Downloaded OS Installers don't work anymore, I had to download a new copy.

Yes, will be a juggle here as well. At least I preserved my el Capitan install alongside Sierra. Unfortunately I did not preserve the Yosemite install that came on the machine, and don't have installation media for that. Are media available for older versions via Apple ? Bootcamp on el Capitan and Sierra seems to not work or be supported on this older Mac Pro, so have been using rEFInd instead (fine). Would not mind have some physical media in case of emergency anyhow (whichever versions)

The last time I dealt with that situation it was easy to download the Older OS Installer if you are registered as having "purchased" your Free copy earlier. Just go to the App Store App and Download it from your Purchased Tab. If you never Downloaded the Older Installer back when it was current it's worse than pulling teeth to get a copy now. That was well over a year ago. I also found they have Time Limits on the Installers, some of my older Downloaded OS Installers don't work anymore, I had to download a new copy.

Oh well, yeah will cross that bridge if and when I need to (probably won't need to bother). For now I'm surprised that I got the IOMMU cooperating under Linux, so enough juggling for the weekend.

---

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

TBar and Jason,

On TonyMacx86.com there were questions about not being able to reinstall older OS X versions that had been successfully downloaded prior... The answer, (for the Hackintosh community), was to set the BIOS date back on the computer to "trick" the OS to install again. Once the OS was successfully reinstalled, the Hack user just changes the date back to the current/correct date and runs the system as normal. This works for all Hackintoshes; but, don't know if you can do this on a real MAC due to MACs not having a BIOS...


TL

---

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

Hmm, Interesting theory. Sure it has EFI rather than BIOS, though setting the system clock should conceivably do the same thing. Most likely I'll end up virtualising both Win10 and OSX (some version), and passing through alternate GPUs at leisure anyway. A lot will depend on what happens with this weekend's round of fiddling. I quite like Sierra and ElCapitan (for what they are) and will preserve their native installs. It's really only the development automation where it would be nice to be able to use near identical setups on each OS simultaneously. That'll hopefully work passing through the 980, we'll see . Worst case on failure will just mean running 3 separate machines with different quirky hardware. Either way nothing insurmountable.

---

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

That's strange. The CUDA 75 zi3k+ App I built a couple days ago worked fine in Yosemite, but the Inconclusive results started increasing. I switched back to El Capitan and now they are up to 70 instead of the high 40s. I used the same files to build the zi3k+ 75 version as I did the CUDA 80 version, and the CUDA 80 version is set to use the same 7.5 Libraries. I just switched back to the CUDA 80 zi3k+ version to see if the Inconclusive number will go back down. The CUDA 80 version will only work in El Capitan and higher. It'd be nice when all these False overflows it racked up with zi3t1b finish working through the system, I think it still has a couple to go.

The usual delays my end, though am running down the Linux/Mac host at the moment for the GPU switchover and passthrough experiments. Will likely end up updating the alpha in svn to Petri's latest supplied sources, at least once the 980 is operational natively in Ubuntu and Sierra and/or El Capitan. Platform cross comparison and migration to Gradle automation will occur gradually, a pulsefind reduction patch likely priority before integration (depending on the inner changes).

---

"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, it appears the increase in Inconclusives was a result of the return of the BLCs. Seems everyones numbers went up, including my 2 Linux machines. So, I decided to give zi3t1e another try even though it produced False Overflows on the Linux machines the last time. I never did get False overflows on the Mac with zi3t1e, it just didn't seem any better than zi3k+ at the time and I expected False overflows just as with the Linux version. I did make a change in confsettings.cpp this time with the new build of zi3t1e, since the autotune seems to be setting -pfp to the unroll number I changed it to pfPeriodsPerLaunch = 8; down near the bottom instead of 128. I don't have a clue if it will make a difference, I just felt I needed to change something from the build that produced the Linux False overflows.

The two 3 GPU machines are running the new build of zi3t1e. It will probably take a couple days to see any real changes, but it does seem most of the Inconclusives are the Normal Unmatched Overflows. I haven't seen any False overflows...yet.

Hmmm, will need to remember to check if the pulsefind launches have a tail on the unroll, in case the number of periods is not divisible by pfPeriodsPerLaunch * unroll . If it's missing a tail, or there is a bug in it, then yes a lower value would be less likely to cause an issue. Ultimately we'll need to stick some timers around those launches, and aim for < ~20ms or so between synchs. Probably Linux/Mac will adopt the Windows style driver optimisations (such as kernel fusion in the streams), which means automatic scaling there may become necessary sooner rather than later.

---

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

Oh well, first False overflow on the Linux machine, https://setiathome.berkeley.edu/workunit.php?wuid=2482791582
Another Linux machine is having the same trouble with zi3t1e, yesterday it had a few False overflows that turned invalid and disappeared, https://setiathome.berkeley.edu/workunit.php?wuid=2480586800.

My other Linux machine is just getting over the zi3t1e False overflows from a few days ago, it wasn't using the autotune, http://setiathome.berkeley.edu/results.php?hostid=6906726&state=5

Still No False overflows on the Mac with zi3t1e, although this is a strange one, http://setiathome.berkeley.edu/workunit.php?wuid=2482791515 The other machine did Overflow....eventually.

Oops, Finally a False Overflow on the Mac, http://setiathome.berkeley.edu/workunit.php?wuid=2482383846
I suppose it's back to zi3k+ which doesn't produce False Overflows, just lottsa Inconclusives.

heh, spike overflows at 0 chirp. That's weird, since that's just a copy, fft and powerspectrum (normally). Perhaps there's a silent failure or incomplete kernel launch. Will give something to poke at early in the piece.

---

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

Yes, it seems all of the zi3t1e False overflows are at 0 chirp. This task mentioned earlier has them at differing chirps where zi3t1e had them all at chirp=0, http://setiathome.berkeley.edu/result.php?resultid=5616173398
So, how do we fix that? It does appear zi3t1e produces fewer inconclusives otherwise.

Starting with zi3l I noticed the BLC tasks would run normally as long as they weren't the First task run at BOINC Startup. If the First task at Startup was an Arecibo task, the following BLC would run normally. If the First task at startup was a BLC it would immediately Overflow, and keep overflowing all the BLCs until it found an Arecibo task. After the Arecibo task ran, the following BLC tasks would run normally. Yes, Very strange. It would appear something wasn't starting correctly. That was when I built zi3k+, because, it didn't/doesn't have that problem.

heh, spike overflows at 0 chirp. That's weird, since that's just a copy, fft and powerspectrum (normally). Perhaps there's a silent failure or incomplete kernel launch. Will give something to poke at early in the piece.

That is one probable cause. Another is a buffer overflow before the copy.

---

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

Yes, it seems all of the zi3t1e False overflows are at 0 chirp. This task mentioned earlier has them at differing chirps where zi3t1e had them all at chirp=0, http://setiathome.berkeley.edu/result.php?resultid=5616173398
So, how do we fix that? It does appear zi3t1e produces fewer inconclusives otherwise.

Starting with zi3l I noticed the BLC tasks would run normally as long as they weren't the First task run at BOINC Startup. If the First task at Startup was an Arecibo task, the following BLC would run normally. If the First task at startup was a BLC it would immediately Overflow, and keep overflowing all the BLCs until it found an Arecibo task. After the Arecibo task ran, the following BLC tasks would run normally. Yes, Very strange. It would appear something wasn't starting correctly. That was when I built zi3k+, because, it didn't/doesn't have that problem.

Sounds like an uninitialized buffer/buffer overflow.

---

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

Thank you guys,

You can read the code and I definitely will a couple of next days. I'll reserve a stack of paper and a pencil and do some calculations ... and test runs.
You could insert a cudaMemsetAsync(SomeParams_and, streamThatProcessesTheTask) to zero out the result buffers way ahead (like before chirp) on your platforms, since I can not reproduce the error.

Petri

---

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

Can you give me an exact line and location to paste it? I'll see how it goes. Right now I don't have much else to do, zi3k+ looked good back with mostly Arecibo tasks and running around 1000 pendings to less than 50 Inconclusives. Now it doesn't look so good. Might as well try something different.

Can you give me an exact line and location to paste it? I'll see how it goes. Right now I don't have much else to do, zi3k+ looked good back with mostly Arecibo tasks and running around 1000 pendings to less than 50 Inconclusives. Now it doesn't look so good. Might as well try something different.

Yes,
you'll just have to wait. This is family night. Tomorrow is the outage (starting at 18 pm here) so then I'll have time to dust my computer and GPUs and the code.

However if you are feeling impatient you can try to find the first call to cudaAcc...dfts() in analyzeFuncs.cpp. Right before or after that.
The parameters to cudaMemsetAsync are in the CUDA documentation and the size of the reserved mem buffer can be found in cudaAcceleration.cu where the buffer is allocated using CUDA device memory allocation function. The size is in bytes and one float (short and fast form of decimal number) takes four bytes (4 chunks of 8 bit integers, totalling of 32 bits i.e. four bytes)

There is a possibility of an error either in allocation size or fetching of the result or another stage of signal finding overwriting. I know that one can get blind to his own errors. That's why I need a third eye or seventh sense.

Petri

---

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