Linux CUDA 'Special' App finally available, featuring Low CPU use

Message boards : Number crunching : Linux CUDA 'Special' App finally available, featuring Low CPU use
Message board moderation

To post messages, you must log in.

Previous · 1 . . . 65 · 66 · 67 · 68 · 69 · 70 · 71 . . . 83 · Next

AuthorMessage
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1896973 - Posted: 22 Oct 2017, 22:34:10 UTC
Last modified: 22 Oct 2017, 22:35:01 UTC

The New and Improved CUDA 6.0 App is available at Crunchers Anonymous;
http://www.arkayn.us/forum/index.php?topic=197.msg4499#msg4499

The CUDA 6.0 Special App is for the older Kepler CC 3.5 GPUs that might not work well with CUDA 8 and above. The CUDA 6.0 libraries are included, place them and the other files in the setiathome.berkeley.edu folder. Read the README_x41p_zi3v.txt file in Docs for best use.
Download CUDA 6.0 Special App CUDA6.0_zi3v-Special App
It's likely this will be the Last CUDA App for the cc 3.5 Kepler GPUs, enjoy.
ID: 1896973 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1897221 - Posted: 24 Oct 2017, 3:13:34 UTC

I'm posting this Inconclusive because it's the type which is ripe for cross-validation by nothing but hosts running the Special App.

Workunit 2720373814 (blc04_2bit_guppi_57976_03521_HIP73925_0015.26557.0.22.45.65.vlar)
Task 6112549300 (S=0, A=0, P=29, T=1, G=0, BG=0) x41p_zi3x, Cuda 9.00 special
Task 6112549301 (S=0, A=0, P=29, T=1, G=0, BG=0) x41p_zi3t2b, Cuda 8.00 special

The first two hosts are one of Laurent's, running zi3x, Cuda 9.00, and one of mine, running zi3t2b, Cuda 8.00. Both hosts are reporting 29 Pulses and 1 Triplet, and you have to look real hard to find the one reported signal that the two disagree on. All the "Best" signals seem to match, also.

Pulse: peak=10.35791, time=45.84, period=27.16, d_freq=7550543387.61, score=1.018, chirp=47.257, fft_len=512
vs.
Pulse: peak=10.31991, time=45.84, period=27.18, d_freq=7550543387.61, score=1.014, chirp=47.257, fft_len=512

The thing that concerns me is that the Pulses reported from both hosts look suspiciously like the ones that we've seen in other bogus overflows from various flavors of the Special App, with all of them displaying a time value of 45.84. If that's what's happened here, it might be expected that a tiebreaker would report a completely different set of signals and then yet another host would have to take a crack at the WU.

The potential problem is that the first tiebreaker has been sent to........wait for it..........Petri33! So it will be up to the zi3xs3, Cuda 9.00 Special App to maintain the integrity of the results for this WU. Frankly, I don't think that's a good way for things to work out, even if it turns out that the Pulses are legitimate. One of those "fox guarding the chicken coop" type of situations, I'd have to say.

I'm currently running a bench test with the stock Windows CPU app to see what it comes up with but, since it's not an instant overflow, I would expect it to take several hours on my slow CPU, so I'll probably be off to bed before it finishes. At least I should have some results to post tomorrow following the outage.
ID: 1897221 · Report as offensive
Profile Wiggo
Avatar

Send message
Joined: 24 Jan 00
Posts: 34744
Credit: 261,360,520
RAC: 489
Australia
Message 1897228 - Posted: 24 Oct 2017, 4:26:00 UTC

....
I'm currently running a bench test with the stock Windows CPU app to see what it comes up with...

The result of that will tell if there's a deal breaker there or not. ;-)

Cheers.
ID: 1897228 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1897237 - Posted: 24 Oct 2017, 4:59:29 UTC - in response to Message 1897228.  
Last modified: 24 Oct 2017, 5:10:37 UTC

Someone who wished to do a little research would first look to see how prevalent that pulse time is with the current BLC4s. It only takes a few minutes.
Hint, as usual, I've already looked at how prevalent pulse time=45.84 is with the BLC4s...before I posted.
I'll let others check it out for themselves.
ID: 1897237 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1897275 - Posted: 24 Oct 2017, 22:59:32 UTC - in response to Message 1897237.  

Someone who wished to do a little research would first look to see how prevalent that pulse time is with the current BLC4s. It only takes a few minutes.
Hint, as usual, I've already looked at how prevalent pulse time=45.84 is with the BLC4s...before I posted.
I'll let others check it out for themselves.
And if someone took a little more time to look into the previous reports of bogus Pulses that I referred to, rather than trying to find ways to come up with smug, self-serving responses, he might find out that "time=45.84" is also frequently the pulse time that shows up in those reports. See Message 1864874 for just one example. If I recall correctly, Petri has posted similar.

And all I said was that these "look suspiciously like the ones that we've seen in other bogus overflows", not there was yet any proof that they were the same. As it turns out, my Windows CPU benchmark run (which is what I chose to spend my time on), has confirmed that for this WU, those are, indeed, legitimate Pulses. For that one odd Pulse, the benchmark matches the x41p_zi3x result.

So, for this WU, having 3 Special Apps end up patting each other on the back worked out just fine. That doesn't mean that it's a good situation. There are still enough nagging little inconsistencies and inaccuracies in the Special App that this kind of cross-validation could manage to squeeze out legitimate results, and as use of the Special App becomes more widespread, that sort of scenario becomes more likely.
ID: 1897275 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1897277 - Posted: 24 Oct 2017, 23:19:38 UTC - in response to Message 1897275.  
Last modified: 24 Oct 2017, 23:24:55 UTC

Let me Explain this to you again. Instant overflows are just a Tiny fraction of the entire WU. When the App finds 30 Pulses all with time=45.84 THEY ARE NOT BOGUS, THEY REALLY ARE THERE. The problem is the other App DOESN'T Look Long Enough to Find Them. If BOTH APPS Looked at the Entire WU They Would Find the SAME SIGNALS.
SETI DOESN'T USE A TINY FRACTION OF THE WU. Those Overflows ARE NOT USED BECAUSE THEY ARE JUST A TINY FRACTION OF THE ENTIRE WU.
Now if I'm wrong about that, I'm sure Richard will be along to correct it.

You linked to a post about a 780, Please look above where you will see it is Common Knowledge the Kepler CC 3.5 GPUs DO NOT WORK CORRECTLY with anything above CUDA 6.0.
I just went through a Lot of work to Build a CUDA 6.0 App for those GPUs, Nothing Lower than CC 5.0 will be supported in future Apps. If you have a CC 3.5 GPU, use the CUDA 6.0 App, anything higher will give increased Invalids.
ID: 1897277 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1897288 - Posted: 25 Oct 2017, 0:13:56 UTC - in response to Message 1897277.  

Oh, give it a rest, your High and Mightyness. First of all, this was not an instant overflow, it was a late overflow. And I just said in my last post that the Pulses reported were confirmed by the Windows CPU app, so they are not bogus in this WU. Now, if another established app doesn't report the same Pulses as the Special App, I hardly think it's the other app which is failing and whose results should be dismissed. I rather think it's the new app which still has a number of frequently reported kinks that need to be worked out. That's just common sense.

Yes, I know the referenced post concerned a 780. It was my 780. That's why that particular time value caught my eye. But, while backtracking from Cuda 8.0 to 7.5 to 6.5 to 6.0 may get around whatever the problem is that generates those bogus pulses, I don't believe I've ever seen anything written that pointed to exactly what the problem is in the newer Cuda apps. If it hasn't actually been identified, who's to say that it isn't still lurking somewhere in the code. In which case, surfacing with GPUs other than 780s and Titans is still a possibility.

Look, I'm just as eager as anyone to see the Special App become as trusted and widely used as any of the Cuda and OpenCL apps that are already established. The increase in productivity for the project would be tremendous. But the only way to get there is to identify, nail down, and, above all, fix these nagging inaccuracies and inconsistencies that keep cropping up with the Special App, not to just ignore them because they're such a tiny part of the product. Now perhaps you don't mind a tiny percentage of arsenic in your coffee and a tiny bit of rat poop in your burger, but this is a scientific project and accuracy and consistency should be a paramount concern. Tiny bits of results that are wrong, as determined by the established standards, simply don't belong.

Some of those nagging problems that keep cropping up, as you yourself have stated, have pretty much been there since the app's inception. Instead of focusing on squeezing more speed out of the app, a far better use of development time would to address the issues which simply aren't going to go away by themselves.
ID: 1897288 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1897296 - Posted: 25 Oct 2017, 0:55:13 UTC - in response to Message 1897288.  

I don't believe I've ever seen anything written that pointed to exactly what the problem is in the newer Cuda apps. If it hasn't actually been identified, who's to say that it isn't still lurking somewhere in the code. In which case, surfacing with GPUs other than 780s and Titans is still a possibility.
I've mentioned the problems with the Newer CUDA and Older GPUs a couple of times. I built a CUDA 7.5 BASELINE App, i.e. NOT Special, for the Mac, you can see it here, 8.11 (cuda75_mac) : 16 Nov 2016, 1:55:03 UTC : 265 GigaFLOPS. The App was actually built Before the BLCs were released, back then it was a Good App. That App works perfectly Fine on my CC 5.0 and higher GPUs, However, it has the SAME problem with the Older CC 3.5 GPUs, the older GPUs Fail with that App even though it is a Baseline App. So, the problem with the Older GPUs and Newer CUDAs have Nothing to do with the Special App, and I doubt it will be fixed anytime soon. nVidia says you should use the version of CUDA that was current when the GPU was released, for the older GPUs that will be CUDA 6.0.

My problem is you keep harping on the Overflows, which are NOT used, and insinuating that because the Special App finds a different 30 signals in that tiny fraction of a WU it is somehow Flawed on the Normal WUs that don't overflow. As your CPU test just proved, that is Not the case. When there are only 30 signals in the entire WU, both Apps find the same 30 signals.
ID: 1897296 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1897307 - Posted: 25 Oct 2017, 2:40:44 UTC - in response to Message 1897296.  

I've mentioned the problems with the Newer CUDA and Older GPUs a couple of times. I built a CUDA 7.5 BASELINE App, i.e. NOT Special, for the Mac, you can see it here, 8.11 (cuda75_mac) : 16 Nov 2016, 1:55:03 UTC : 265 GigaFLOPS. The App was actually built Before the BLCs were released, back then it was a Good App. That App works perfectly Fine on my CC 5.0 and higher GPUs, However, it has the SAME problem with the Older CC 3.5 GPUs, the older GPUs Fail with that App even though it is a Baseline App. So, the problem with the Older GPUs and Newer CUDAs have Nothing to do with the Special App, and I doubt it will be fixed anytime soon. nVidia says you should use the version of CUDA that was current when the GPU was released, for the older GPUs that will be CUDA 6.0.
So really, then, the CC 3.2 cutoff that was originally touted for the Special App will need some additional refinement. Okay. Ultimately, though, it's the code in the science app that reports the bogus pulses, so I would think that it would be helpful to know just exactly how that happens and what call(s) to the Cuda routines end up identifying those signals at some Cuda levels and not others. Such knowledge might possibly lead to a better way of making those calls that could reduce the fragmentation that's currently necessary. Or it might not, of course, but it would seem prudent to me.

...the Overflows, which are NOT used,
Once again, where's your attribution for this claim? You keep accusing others of making unsubstantiated claims (calling B.S. is the way you put it, I believe), yet you repeatedly do the same. Please direct us all to a statement from a project scientist that confirms that overflow results are not used, or get one to make such a definitive statement now. That would resolve the whole issue. In the meantime, rather than repeat myself, I'll just quote my argument from an earlier post (Message 1890278):

As far as I know, the 30 signal threshold was chosen solely based on storage considerations, not on WU "value". A -9 overflow may, indeed, be wall-to-wall noise with thousands of detected signals. But it may also be one that just meets the minimum 30-signal threshold, such as the one I reported on just a couple days ago in Message 1889868. In that WU, one host reported 29 signals, the other 30, the difference being a single Pulse. So a "noisy" WU is a relative term and again, not to be arbitrarily dismissed as "a waste". As it happened, the 3rd host also reported 30 signals and so a -9 overflow was designated as the canonical result which, to the best of my knowledge, is still stored in the database for later analysis.
By your claim, if the host reporting 29 signals was validated, the WU would be valuable and kept in the database, but if the host reporting 30 signals got the nod (as it did for the WU I mentioned) it's worthless and would be thrown away. That just doesn't wash.
ID: 1897307 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1897312 - Posted: 25 Oct 2017, 3:03:05 UTC

Although TBar seems to think I'm focused only on Overflows, in fact right now I'm more focused on Inconclusives involving the latest Cuda 9.0 apps showing up in my list which, although they frequently involve Overflows, don't always, to wit:

Workunit 2720620318 (21mr08aa.30945.51301.11.38.152)
Task 6113064652 (S=2, A=1, P=4, T=0, G=1, BG=3.751645) x41p_zi3t2b, Cuda 8.00 special
Task 6113064653 (S=2, A=1, P=4, T=0, G=1, BG=3.751645) x41p_zi3x, Cuda 9.00 special

All the reported signals line up nicely between the two reports, but in this case the x41p_zi3x reported a bogus Best Spike:

Best spike: peak=-nan, time=1.678, d_freq=1418984342.92, chirp=-19.121, fft_len=32k

This appears to have resulted from a restart of the task, even though the 2 legitimate Spikes appear in the Stderr both before and after the restart.
ID: 1897312 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1897316 - Posted: 25 Oct 2017, 3:22:29 UTC - in response to Message 1897307.  
Last modified: 25 Oct 2017, 3:27:59 UTC

...the Overflows, which are NOT used,
Once again, where's your attribution for this claim? You keep accusing others of making unsubstantiated claims (calling B.S. is the way you put it, I believe), yet you repeatedly do the same. Please direct us all to a statement from a project scientist that confirms that overflow results are not used, or get one to make such a definitive statement now. That would resolve the whole issue. In the meantime, rather than repeat myself, I'll just quote my argument from an earlier post (Message 1890278)....That just doesn't wash.

Once again, SETI IS THE ONE THAT STOPS THE PROCESSING AFTER 30 Signals.
I HAVE ABSOLUTELY NOTHING To Do With it. What part of that don't you understand?
How is SETI going to use just a Fraction of the WU??? Are they going to try and figure out just how much processing was done in those few seconds and add that as a note??
I mean Jesus, can't you understand that when the processing is stopped after just a few seconds the results are useless?
ID: 1897316 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1897323 - Posted: 25 Oct 2017, 3:49:11 UTC - in response to Message 1897316.  

...the Overflows, which are NOT used,
Once again, where's your attribution for this claim? You keep accusing others of making unsubstantiated claims (calling B.S. is the way you put it, I believe), yet you repeatedly do the same. Please direct us all to a statement from a project scientist that confirms that overflow results are not used, or get one to make such a definitive statement now. That would resolve the whole issue. In the meantime, rather than repeat myself, I'll just quote my argument from an earlier post (Message 1890278)....That just doesn't wash.

Once again, SETI IS THE ONE THAT STOPS THE PROCESSING AFTER 30 Signals.
I HAVE ABSOLUTELY NOTHING To Do With it. What part of that don't you understand?
How is SETI going to use just a Fraction of the WU??? Are they going to try and figure out just how much processing was done in those few seconds and add that as a note??
I mean Jesus, can't you understand that when the processing is stopped after just a few seconds the results are useless?
Sigh......pointless, just absolutely pointless. I guess I'll just have to call B.S. and let it go at that. Cogent arguments are wasted on you.
ID: 1897323 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1897326 - Posted: 25 Oct 2017, 4:02:59 UTC - in response to Message 1897323.  
Last modified: 25 Oct 2017, 4:09:30 UTC

...the Overflows, which are NOT used,
Once again, where's your attribution for this claim? You keep accusing others of making unsubstantiated claims (calling B.S. is the way you put it, I believe), yet you repeatedly do the same. Please direct us all to a statement from a project scientist that confirms that overflow results are not used, or get one to make such a definitive statement now. That would resolve the whole issue. In the meantime, rather than repeat myself, I'll just quote my argument from an earlier post (Message 1890278)....That just doesn't wash.

Once again, SETI IS THE ONE THAT STOPS THE PROCESSING AFTER 30 Signals.
I HAVE ABSOLUTELY NOTHING To Do With it. What part of that don't you understand?
How is SETI going to use just a Fraction of the WU??? Are they going to try and figure out just how much processing was done in those few seconds and add that as a note??
I mean Jesus, can't you understand that when the processing is stopped after just a few seconds the results are useless?
Sigh......pointless, just absolutely pointless. I guess I'll just have to call B.S. and let it go at that. Cogent arguments are wasted on you.

Why don't you e-mail Eric and ask him what he does with Aborted WUs? That 's what it is, a WU that was NEVER finished. How can you use something that was Never finished?
Cogent arguments are wasted on you.

BTW, I'm still waiting for evidence that a certain GPU is Twice as fast as everyone else's when using the same App. I actually provided Evidence...numerous times.
ID: 1897326 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1897327 - Posted: 25 Oct 2017, 4:17:22 UTC - in response to Message 1897326.  

Cogent arguments are wasted on you.
I haven't noticed any yet, just a lot of SHOUTING as a substitute for actually providing, or directing us to, evidence of your claims.

BTW, I'm still waiting for evidence that a certain GPU is Twice as fast as everyone else's when using the same App. I actually provided Evidence...numerous times.
?????? What's this, just classic misdirection to an unrelated topic?
ID: 1897327 · Report as offensive
Stephen "Heretic" Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 20 Sep 12
Posts: 5557
Credit: 192,787,363
RAC: 628
Australia
Message 1897330 - Posted: 25 Oct 2017, 4:37:56 UTC - in response to Message 1897316.  

...the Overflows, which are NOT used,
Once again, where's your attribution for this claim? You keep accusing others of making unsubstantiated claims (calling B.S. is the way you put it, I believe), yet you repeatedly do the same. Please direct us all to a statement from a project scientist that confirms that overflow results are not used, or get one to make such a definitive statement now. That would resolve the whole issue. In the meantime, rather than repeat myself, I'll just quote my argument from an earlier post (Message 1890278)....That just doesn't wash.

Once again, SETI IS THE ONE THAT STOPS THE PROCESSING AFTER 30 Signals.
I HAVE ABSOLUTELY NOTHING To Do With it. What part of that don't you understand?
How is SETI going to use just a Fraction of the WU??? Are they going to try and figure out just how much processing was done in those few seconds and add that as a note??
I mean Jesus, can't you understand that when the processing is stopped after just a few seconds the results are useless?


. . Perhaps he is making the distinction between noise bombs (early overflows) and late overflow tasks when most or almost all of the signal sample has been analysed??

Stephen
ID: 1897330 · Report as offensive
Stephen "Heretic" Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 20 Sep 12
Posts: 5557
Credit: 192,787,363
RAC: 628
Australia
Message 1897331 - Posted: 25 Oct 2017, 4:41:03 UTC - in response to Message 1897326.  


BTW, I'm still waiting for evidence that a certain GPU is Twice as fast as everyone else's when using the same App. I actually provided Evidence...numerous times.


. . No, you didn't. You have yet to furnish any evidence that the examples you referred to were run as single GPU tasks. If/when you do I would have to accept that they have very slow units. But such is life ...

Stephen

:)
ID: 1897331 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1897333 - Posted: 25 Oct 2017, 4:53:33 UTC - in response to Message 1897330.  

...the Overflows, which are NOT used,
Once again, where's your attribution for this claim? You keep accusing others of making unsubstantiated claims (calling B.S. is the way you put it, I believe), yet you repeatedly do the same. Please direct us all to a statement from a project scientist that confirms that overflow results are not used, or get one to make such a definitive statement now. That would resolve the whole issue. In the meantime, rather than repeat myself, I'll just quote my argument from an earlier post (Message 1890278)....That just doesn't wash.

Once again, SETI IS THE ONE THAT STOPS THE PROCESSING AFTER 30 Signals.
I HAVE ABSOLUTELY NOTHING To Do With it. What part of that don't you understand?
How is SETI going to use just a Fraction of the WU??? Are they going to try and figure out just how much processing was done in those few seconds and add that as a note??
I mean Jesus, can't you understand that when the processing is stopped after just a few seconds the results are useless?


. . Perhaps he is making the distinction between noise bombs (early overflows) and late overflow tasks when most or almost all of the signal sample has been analysed??

Stephen

I suggest you e-mail Eric and ask him what qualifiers he's going to use to differentiate which unfinished WU he will use and which unfinished WU he won't use. I'd like to hear that myself.
ID: 1897333 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1897336 - Posted: 25 Oct 2017, 5:06:05 UTC - in response to Message 1897331.  


BTW, I'm still waiting for evidence that a certain GPU is Twice as fast as everyone else's when using the same App. I actually provided Evidence...numerous times.


. . No, you didn't. You have yet to furnish any evidence that the examples you referred to were run as single GPU tasks. If/when you do I would have to accept that they have very slow units. But such is life ...

Stephen

:)

I see, EVERY example I provided the host just happened to be running doubles...in your world.
It's easy Stephen. If the run-times are equal to the time between reports then he is running singles. If the machine were running doubles there would be twice as many reports, there weren't. Especially on the last example where the only reports were from the GPU and the difference in report times matched the run-times. I can provide many examples, anyone can. Why don't you provide an example to support your claim?
ID: 1897336 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1897355 - Posted: 25 Oct 2017, 9:55:02 UTC - in response to Message 1897275.  


So, for this WU, having 3 Special Apps end up patting each other on the back worked out just fine. That doesn't mean that it's a good situation. There are still enough nagging little inconsistencies and inaccuracies in the Special App that this kind of cross-validation could manage to squeeze out legitimate results, and as use of the Special App becomes more widespread, that sort of scenario becomes more likely.

And correct way to solve this would be to send tiebreaker to distinct plan class device, preferably, CPU device.
In case of anonymous platform this would mean "to send to stock CPU".
I'll attempt to rise this issue with Eric.
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1897355 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1897356 - Posted: 25 Oct 2017, 10:22:37 UTC - in response to Message 1897312.  


Best spike: peak=-nan, time=1.678, d_freq=1418984342.92, chirp=-19.121, fft_len=32k

This appears to have resulted from a restart of the task, even though the 2 legitimate Spikes appear in the Stderr both before and after the restart.

Hm.... such not a number values better to catch by app's sanity checks.
AFAIK Petri implemented same sanity checks as OpenCL and CPU apps have currently. So, probably they all don't check for "not a number" condition... It's TODO for checking...
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1897356 · Report as offensive
Previous · 1 . . . 65 · 66 · 67 · 68 · 69 · 70 · 71 . . . 83 · Next

Message boards : Number crunching : Linux CUDA 'Special' App finally available, featuring Low CPU use


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.