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
Previous · 1 . . . 55 · 56 · 57 · 58 · 59 · 60 · 61 . . . 83 · Next
| Author | Message |
|---|---|
 Jeff Buck    Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 
|
I will have to look again at my inconclusives and analyze whether my increase is from restart reordering of the search.The ones resulting from the Restart bug are fairly easy to spot. Immediately after the restart, they show a blast of either Spikes or Triplets until an overflow condition is reached. The Triplets always seem to have "peak=-nan". I also think that all of those Invalids have come from Guppi VLARs, while all of the recent ones that started appearing since the change to 4-bit WUs appear to have been Arecibo tasks with normal ARs. ID: 1889857 ·  |
Keith Myers  Send message Joined: 29 Apr 01 Posts: 13164 Credit: 1,160,866,277 RAC: 1,873
 |
Thanks for the link, Jeff. I was thinking of experimenting. I looked in a dozen or so of my inconclusives for the NaN value which should have been tied into the burst of spikes but didn't see any. They were Arecibo though and not any BLC tasks. I've only had 4 Invalids since my 4 Sept fiasco and every one is because I lost out to the SoG or CPU runs. I have about 80 pending from around that date that are going to move to Invalid once they validate. Frustrating with the long deadlines that known bad results take so long to clear the system Seti@Home classic workunits:20,676 CPU time:74,226 hours   A proud member of the OFA (Old Farts Association) ID: 1889860 · |
|
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0
|
Here's an unusual Inconclusive with a condition that I don't think I've seen before. Both hosts (mine and Rob Smith's) are running the same version of the Special App. While Rob's GTX 1080 reported a total of 29 signals, including 25 Pulses, my GTX 960 reported one extra Pulse, which was juuussst enough to push it to the 30-signal threshold, resulting in a -9 overflow. So, not one of those extremely noisy WUs, but a -9 overflow just the same. Workunit 2676426676 (blc05_2bit_guppi_57903_52843_HIP13027_0019.8173.409.23.46.100.vlar) Task 6020750525 (S=0, A=1, P=25, T=3, G=0, BG=0) x41p_zi3t2b, Cuda 8.00 special Task 6020750526 (S=0, A=1, P=26, T=3, G=0, BG=0) x41p_zi3t2b, Cuda 8.00 special The extra is: Pulse: peak=0.09631932, time=45.81, period=0.01666, d_freq=2201930483.65, score=1.071, chirp=-74.234, fft_len=32 It hasn't been sent to a third host yet, but it should be interesting to see how the validator handles it when the next result comes in. ID: 1889868 · |
|
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0
|
And another first appearance in my Inconclusives list, a Cuda 9.00 Special App, which Petri is apparently testing. Strange, though, that neither of the Special Apps agreed with the Cuda42 on this one (or with each other). The next host to get this WU also appears to be running the Special App, x41p_zi3t2b, so I would hope that some sort of agreement will be reached when it reports. Workunit 2672910602 (22au08ad.1366.5389.8.35.255) Task 6013393581 (S=0, A=0, P=14, T=16, G=0, BG=?) v8.00 (cuda42) windows_intelx86 Task 6013393582 (S=0, A=0, P=16, T=14, G=0, BG=0) v8.22 (opencl_nvidia_SoG) windows_intelx86 Task 6018644731 (S=0, A=0, P=24, T=6, G=0, BG=0) x41p_zi3t2b, Cuda 8.00 special Task 6020179529 (S=0, A=0, P=24, T=6, G=0, BG=0) x41p_zi3x, Cuda 9.00 special EDIT: I just ran an offline test on this WU with the stock Windows 8.00 app and got counts that matched the v8.22 SoG result, 16 Pulses and 14 Triplets. ID: 1889871 · |
|
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0
|
And another first appearance in my Inconclusives list, a Cuda 9.00 Special App, which Petri is apparently testing. Strange, though, that neither of the Special Apps agreed with the Cuda42 on this one (or with each other). The next host to get this WU also appears to be running the Special App, x41p_zi3t2b, so I would hope that some sort of agreement will be reached when it reports.Oh, well, hopes are sometimes dashed. Add another task to the Inconclusives on this WU and wait for the 6th one to do its thing. Task 6021725529 (S=0, A=0, P=24, T=6, G=0, BG=0) x41p_zi3t2b, Cuda 6.50 special The signal counts reported by all 3 flavors of the Special App are the same, so the disagreement seems to be focused on 3 of the 24 Pulses reported. The other 21 match up fine. Here's what the reports are showing for each of those Pulses for: 1) Cuda 6.50 special; 2) Cuda 8.00 special; 3) Cuda 9.00 special 1) Pulse: peak=11.98681, time=101.2, period=4.03, d_freq=1419994049.07, score=1.235, chirp=0, fft_len=128 2) Pulse: peak=12.22, time=101.2, period=4.103, d_freq=1419994049.07, score=1.258, chirp=0, fft_len=128 3) Pulse: peak=12.22, time=101.2, period=4.103, d_freq=1419994049.07, score=1.258, chirp=0, fft_len=128 1) Pulse: peak=10.98659, time=18.65, period=3.899, d_freq=1419994354.25, score=1.134, chirp=0, fft_len=128 2) Pulse: peak=10.98659, time=18.65, period=3.899, d_freq=1419994354.25, score=1.134, chirp=0, fft_len=128 3) Pulse: peak=11.45281, time=18.65, period=4.089, d_freq=1419994354.25, score=1.179, chirp=0, fft_len=128 1) Pulse: peak=12.0304, time=74.56, period=3.998, d_freq=1419994354.25, score=1.24, chirp=0, fft_len=128 2) Pulse: peak=10.84199, time=74.56, period=3.854, d_freq=1419994354.25, score=1.119, chirp=0, fft_len=128 3) Pulse: peak=12.0304, time=74.56, period=3.998, d_freq=1419994354.25, score=1.24, chirp=0, fft_len=128 So, not so much a processing sequence issue as a peak value calculation/reporting issue, it would appear. I thought there might be some sort of progression from the 6..50 to the 8.00 to the 9.00, but that doesn't seem to be the case. The task is assigned to v8 v8.08 (alt) on the 6th host, so now I would expect it to match up with the host that ran SoG. It's still possible, of course, that all the tasks will be blessed as Valid, but, who knows? ID: 1890109 · |
|
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 
 |
Pulses are selected based on score, not peak. The peaks are different since the pulses are from different time and have different period. SoG reports on chirp 0, fft_len 64 first 3 pulses. Then triplets, and then it continues reporting fft_len 64 pulses. Weird. My program does not seem to find all triplets in a noisy packet. SoG: Pulse: peak=12.134, time=31.07, period=3.903, d_freq=1419994354.25, score=1.221, chirp=0, fft_len=64 D: threshold 0.04234767; unscaled peak power: 0.0508454 exceeds threshold for 20.07% Pulse: peak=11.97337, time=37.28, period=3.437, d_freq=1419994354.25, score=1.21, chirp=0, fft_len=64 D: threshold 0.04227359; unscaled peak power: 0.05034287 exceeds threshold for 19.09% Pulse: peak=9.939013, time=74.56, period=3.205, d_freq=1419994354.25, score=1.007, chirp=0, fft_len=64 D: threshold 0.04170371; unscaled peak power: 0.04197075 exceeds threshold for 0.6403% Triplet: peak=12.35035, time=59.05, period=0.06881, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=12.29125, time=59.06, period=0.07209, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=15.29185, time=59.06, period=0.07537, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=12.35035, time=59.06, period=0.06554, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=12.29125, time=59.06, period=0.06881, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=11.94211, time=59.05, period=0.06881, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=11.88497, time=59.06, period=0.07209, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=14.78638, time=59.06, period=0.07537, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=11.94211, time=59.06, period=0.06554, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=11.88497, time=59.06, period=0.06881, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=10.61269, time=83.04, period=0.06881, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=10.63719, time=83.04, period=0.06881, d_freq=1419994659.42, chirp=0, fft_len=64 Pulse: peak=8.354126, time=31.07, period=2.604, d_freq=1419994812.01, score=1.077, chirp=0, fft_len=64 D: threshold 0.03311493; unscaled peak power: 0.03537508 exceeds threshold for 6.825% Pulse: peak=11.06911, time=80.77, period=4.135, d_freq=1419994812.01, score=1.111, chirp=0, fft_len=64 D: threshold 0.04165395; unscaled peak power: 0.04587023 exceeds threshold for 10.12% Pulse: peak=11.26827, time=86.98, period=4.063, d_freq=1419994812.01, score=1.132, chirp=0, fft_len=64 D: threshold 0.04045896; unscaled peak power: 0.04531526 exceeds threshold for 12% Here's what I get at home: WU true angle range is : 0.432160 Sigma 3 Thread call stack limit is: 1k Pulse: peak=12.13399, time=31.07, period=3.903, d_freq=1419994354.25, score=1.221, chirp=0, fft_len=64 Pulse: peak=11.97333, time=37.28, period=3.437, d_freq=1419994354.25, score=1.21, chirp=0, fft_len=64 Pulse: peak=9.939015, time=74.56, period=3.205, d_freq=1419994354.25, score=1.007, chirp=0, fft_len=64 Pulse: peak=8.354123, time=31.07, period=2.604, d_freq=1419994812.01, score=1.077, chirp=0, fft_len=64 Pulse: peak=11.06909, time=80.77, period=4.135, d_freq=1419994812.01, score=1.111, chirp=0, fft_len=64 Pulse: peak=11.26821, time=86.98, period=4.063, d_freq=1419994812.01, score=1.132, chirp=0, fft_len=64 Triplet: peak=12.35032, time=59.05, period=0.06881, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=12.35032, time=59.06, period=0.06554, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=11.9421, time=59.05, period=0.06881, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=11.9421, time=59.06, period=0.06554, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=10.61266, time=83.04, period=0.06881, d_freq=1419994659.42, chirp=0, fft_len=64 Triplet: peak=10.63715, time=83.04, period=0.06881, d_freq=1419994659.42, chirp=0, fft_len=64 Pulse: peak=10.16576, time=6.219, period=4.096, d_freq=1419994049.07, score=1.047, chirp=0, fft_len=128 Pulse: peak=8.964704, time=12.43, period=2.731, d_freq=1419994049.07, score=1.183, chirp=0, fft_len=128 Pulse: peak=10.93904, time=31.07, period=4.07, d_freq=1419994049.07, score=1.127, chirp=0, fft_len=128 Pulse: peak=11.21205, time=37.28, period=3.88, d_freq=1419994049.07, score=1.157, chirp=0, fft_len=128 Pulse: peak=3.858159, time=68.35, period=1.106, d_freq=1419994049.07, score=1.058, chirp=0, fft_len=128 Pulse: peak=12.22, time=101.2, period=4.103, d_freq=1419994049.07, score=1.258, chirp=0, fft_len=128 Pulse: peak=11.72956, time=6.219, period=3.749, d_freq=1419994354.25, score=1.212, chirp=0, fft_len=128 Pulse: peak=11.8636, time=12.43, period=3.808, d_freq=1419994354.25, score=1.225, chirp=0, fft_len=128 Pulse: peak=11.45281, time=18.65, period=4.089, d_freq=1419994354.25, score=1.179, chirp=0, fft_len=128 Pulse: peak=10.91566, time=24.86, period=3.788, d_freq=1419994354.25, score=1.127, chirp=0, fft_len=128 Pulse: peak=10.41317, time=49.71, period=3.65, d_freq=1419994354.25, score=1.077, chirp=0, fft_len=128 Pulse: peak=11.6762, time=68.35, period=3.172, d_freq=1419994354.25, score=1.214, chirp=0, fft_len=128 Pulse: peak=12.0304, time=74.56, period=3.998, d_freq=1419994354.25, score=1.24, chirp=0, fft_len=128 Pulse: peak=11.88064, time=80.77, period=3.355, d_freq=1419994354.25, score=1.232, chirp=0, fft_len=128 Pulse: peak=11.01753, time=86.99, period=4.057, d_freq=1419994354.25, score=1.135, chirp=0, fft_len=128 Pulse: peak=7.3104, time=43.5, period=2.412, d_freq=1419994659.42, score=1.156, chirp=0, fft_len=128 Pulse: peak=8.824402, time=49.71, period=2.608, d_freq=1419994659.42, score=1.166, chirp=0, fft_len=128 Pulse: peak=10.01854, time=55.92, period=3.382, d_freq=1419994659.42, score=1.039, chirp=0, fft_len=128 SETI@Home Informational message -9 result_overflow NOTE: The number of results detected equals the storage space allocated. Best spike: peak=22.32756, time=107, d_freq=1419994049.07, chirp=0, fft_len=128 Best autocorr: peak=0, time=-2.121e+11, delay=0, d_freq=0, chirp=0, fft_len=0 Best gaussian: peak=0, mean=0, ChiSq=0, time=-2.121e+11, d_freq=0, score=-12, null_hyp=0, chirp=0, fft_len=0 Best pulse: peak=5.707928, time=37.28, period=1.497, d_freq=1419994354.25, score=1.284, chirp=0, fft_len=64 Best triplet: peak=12.35032, time=59.05, period=0.06881, d_freq=1419994659.42, chirp=0, fft_len=64 Spike count: 0 Autocorr count: 0 Pulse count: 24 Triplet count: 6 Gaussian count: 0 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 ID: 1890137 · |
|
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0
|
For that WU, I was really trying to point out the differences between the 3 versions of the Special App more so than the differences with SoG. For those 3 Pulses, it really doesn't matter whether you look at the Peak value or the score, those 3 Pulses have the same discrepancies. And the time value is the same, too, although you're right about the period being different. Those 3 Pulses are reported in the same sequence on all 3 reports, however, so it would seem as if the same Pulse is being identified each time. Your "at home" run appears to match the results from the Cuda 9.00 special, which certainly would be expected, if that's the latest version. ID: 1890201 · |
Wiggo  Send message Joined: 24 Jan 00 Posts: 34763 Credit: 261,360,520 RAC: 489 
|
Well I'm feeling ripped off this morning, http://setiathome.berkeley.edu/workunit.php?wuid=2675588936, as a x41p_zi3t2b Cuda 8.00 special agreed with a rig that can't return anything but invalids. :-( Cheers. ID: 1890247 · |
Mike  Send message Joined: 17 Feb 01 Posts: 34258 Credit: 79,922,639 RAC: 80 
|
Well I'm feeling ripped off this morning, http://setiathome.berkeley.edu/workunit.php?wuid=2675588936, as a x41p_zi3t2b Cuda 8.00 special agreed with a rig that can't return anything but invalids. :-( Yep, fast not precise. We know that. With each crime and every kindness we birth our future. ID: 1890254 · |
Zalster  Send message Joined: 27 May 99 Posts: 5517 Credit: 528,817,460 RAC: 242
|
Well I'm feeling ripped off this morning, http://setiathome.berkeley.edu/workunit.php?wuid=2675588936, as a x41p_zi3t2b Cuda 8.00 special agreed with a rig that can't return anything but invalids. :-( +1  
ID: 1890259 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
Actually it is precise, there are in fact 30 triples in that overflow, probably 1000s. If the Apps would have been allowed to continue the results would probably be the same, just as they are in the NON-Overflows. That Machine running the Special App shows; State: All (933) · In progress (200) · Validation pending (343) · Validation inconclusive (17) · Valid (371) · Invalid (0) · Error (2) Perfectly acceptable numbers. Overflows ARE NOT USED BY SETI. Overflows are basically a waste of Time & Energy, for everyone. Someone lost 0.5 credits? I've lost 1000s to those Windows ATI machines that trash perfectly good APs, and those False Valid APs ARE USED BY SETI. ID: 1890260 · |
|
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0
|
Perfectly acceptable numbers. Overflows ARE NOT USED BY SETI. Overflows are basically a waste of Time & Energy, for everyone.And when, exactly, were YOU delegated the authority to make that determination? If all overflows had no value, then why do they need to report signals at all, and pass validation? Perhaps because the project scientists felt there could actually be some value in some of them, so they felt they needed to be reported, stored in the database, and then run through a post-processor when one was available? Unless, and until, that decision is reversed at the project level, all apps need to report signals in the same way. If developers take it upon themselves to arbitrarily decide otherwise, then the project slowly slips into anarchy and chaos. ID: 1890263 · |
Stephen "Heretic"  Send message Joined: 20 Sep 12 Posts: 5557 Credit: 192,787,363 RAC: 628
|
Well I'm feeling ripped off this morning, http://setiathome.berkeley.edu/workunit.php?wuid=2675588936, as a x41p_zi3t2b Cuda 8.00 special agreed with a rig that can't return anything but invalids. :-( . . Did you send him a little thank you card? :) . . I noticed that WU and his only other valid were with CUDA32, Stephen ?? ID: 1890264 · |
|
Wiggo Send message Joined: 24 Jan 00 Posts: 34763 Credit: 261,360,520 RAC: 489
|
. . Did you send him a little thank you card? :) Yes I did. ;-) What version were the video drivers for pre-fermi cards again? Any driver prior to 340.xx, but this excludes the Win10 OS altogether as it only uses drivers onwards from 340.xx. Cheers. ID: 1890271 · |
|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768
|
Perfectly acceptable numbers. Overflows ARE NOT USED BY SETI. Overflows are basically a waste of Time & Energy, for everyone.And when, exactly, were YOU delegated the authority to make that determination? If all overflows had no value, then why do they need to report signals at all, and pass validation? Perhaps because the project scientists felt there could actually be some value in some of them, so they felt they needed to be reported, stored in the database, and then run through a post-processor when one was available? I didn't make that decision, SETI did. You should check it out, it's in previous discussions. I had Nothing to do with it, thanks for the accusations though ;-) They are Not used, hence they are a waste. It isn't that difficult, what would you suggest they do with them? They don't know they are Overflows until they are run. ID: 1890272 · |
|
Stephen "Heretic" Send message Joined: 20 Sep 12 Posts: 5557 Credit: 192,787,363 RAC: 628
|
Perfectly acceptable numbers. Overflows ARE NOT USED BY SETI. Overflows are basically a waste of Time & Energy, for everyone.And when, exactly, were YOU delegated the authority to make that determination? If all overflows had no value, then why do they need to report signals at all, and pass validation? Perhaps because the project scientists felt there could actually be some value in some of them, so they felt they needed to be reported, stored in the database, and then run through a post-processor when one was available? . . Actually Jeff, the reason they have to be reported and validated is the same reason all other results have to be, to confirm that it is not an error on that particular host. Once confirmed as an overflow I am not sure that the results are stored with the others, but TBar refers to a previous discussion that indicated they are in fact discarded. I think it safe to say that noisy WUs are not at this time of any significant use to the project. . . But it is important that there is consistency among the different apps so that such results can be confirmed quickly and not waste server time and resources being resent to other hosts to confirm the overflow. Results that require a third or fourth host to achieve validation are a drag on the system and part of the database bloat. Stephen .. ID: 1890275 · |
|
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0
|
I didn't make that decision, SETI did. [citation needed] They are Not used, hence they are a waste.[citation needed] ID: 1890276 · |
|
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0
|
I think it safe to say that noisy WUs are not at this time of any significant use to the project.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. ID: 1890278 · |
|
Wiggo Send message Joined: 24 Jan 00 Posts: 34763 Credit: 261,360,520 RAC: 489
|
That looks like the SoG checks first for pulses and then for triplets. My version checks first for triplets and then for pulses. On a normal packet that does not matter. On a noisy packet the total count goes over 30 and it matters which is checked first. Of cause scientifically it does not matter since the packet is full of c**p anyway. I can change the order of checking but it may slow things down a couple of seconds or so per WU. Now TBar, Petri has already admitted that his app does not record results in the same way as the SoG app (or the CPU apps for that matter) and it should (no matter whether they're full of c**p or not) so technically it compromises the science here until that order is fixed. So that needs fixing and the sooner the better as I detest getting any invalid results here at all (more so when they shouldn't have been invalid in the first place). Cheers. ID: 1890279 · |
|
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13736 Credit: 208,696,464 RAC: 304
|
Yep, fast not precise. They are precise, just not accurate. It doesn't matter how precise something is, unless it's also accurate. Grant Darwin NT ID: 1890283 · |
©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.