Message boards :
Number crunching :
Monitoring inconclusive GBT validations and harvesting data for testing
Message board moderation
Previous · 1 . . . 29 · 30 · 31 · 32 · 33 · 34 · 35 . . . 36 · Next
Author | Message |
---|---|
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
OK, try to pass then that build to Eric with explanation how to setup plan class for run on iGPU and NV. Maybe it's time for online beta indeed. BTW, what if that build will be tried on ATi card? What about speed? SETI apps news We're not gonna fight them. We're gonna transcend them. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
I don't think the Intel build will work any better than the ATI5 Build already being used. You can't use very high settings with the Intel build, it will not work correctly with just the -oclfft_tune_gr 128 cmdline. The current ATI5 build seems to be working well even though this machine is running High settings and running three tasks at once, http://setiathome.berkeley.edu/results.php?hostid=6105482. I think the current tested ATI5 App would be a better choice, ATI5r3515&CPUr3344sse41.zip |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
I don't think the Intel build will work any better than the ATI5 Build already being used. You can't use very high settings with the Intel build, it will not work correctly with just the -oclfft_tune_gr 128 cmdline. The current ATI5 build seems to be working well even though this machine is running High settings and running three tasks at once, http://setiathome.berkeley.edu/results.php?hostid=6105482. I think the current tested ATI5 App would be a better choice, ATI5r3515&CPUr3344sse41.zip OK, then either send mix you feel is good for beta testing directly to Eric or E-mail me for passing. SETI apps news We're not gonna fight them. We're gonna transcend them. |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
Just a quick note. The first day with r3548 didn't appear to yield anything significant. Of 431 r3548 results, 5 are currently showing as Inconclusive, but 4 of those are against what appear to be wayward hosts that are returning lots of Invalids. The other one is against an r3528 result, so I don't think there's any conclusion to be drawn with that one, either. EDIT: FWIW, though, here's the info on that last one. Workunit 2313958942 (blc3_2bit_guppi_57451_23871_HIP63406_OFF_0016.1842.0.18.27.93.vlar) Task 5260480445 (S=25, A=0, P=5, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86 Task 5260480446 (S=28, A=0, P=2, T=0, G=0) SSE3xj Win32 Build 3548 EDIT2: Corrected total count of r3548 results to 431. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
I don't think the Intel build will work any better than the ATI5 Build already being used. You can't use very high settings with the Intel build, it will not work correctly with just the -oclfft_tune_gr 128 cmdline. The current ATI5 build seems to be working well even though this machine is running High settings and running three tasks at once, http://setiathome.berkeley.edu/results.php?hostid=6105482. I think the current tested ATI5 App would be a better choice, ATI5r3515&CPUr3344sse41.zip One advantage with the Intel build is the Idle Wake Ups are Low. They are down to around 10-30 with an occasional 60. This is much better than with the NV/SoG builds where they are around 5000-7000+. Apple says 300 is Too High. The older NV builds had Idle Wake Ups reaching up to 40000! It would seem what ever is causing the High Idle Wake Ups is in the NV/SoG path. Also, the CPU use is lower with the Intel build. The SoG App had an average of 70% CPU use with periods of 110% CPU use. The Intel build is averaging around 35% CPU use. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
And what those values for ATi build running on NV hardware? SETI apps news We're not gonna fight them. We're gonna transcend them. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
It seems it's also high with the ATI HD5 path on the nVidia cards. I tried it with the ATI build r3515 and a build from r3551 and it was pretty close with both Apps. The Idle Wake Ups were usually around 8000-9000 with spikes up to 14000. I can't remember how the r3515 build worked on my ATI cards, But, the number 500 sounds familiar. If Chris is around maybe he can report on how r3515 runs on his d700s. I went back and looked at the old thread. It seems around 500 Idle Wake Ups per second is probably close on the ATI Card, However, Apple says it should be 150 or less. At the time though, 500 was much better than what the other Apps were producing ;-) |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
The other one is against an r3528 result, so I don't think there's any conclusion to be drawn with that one, either. Well, that r3548 from last evening is now Inconclusive against a second r3528, which is starting to make it look more interesting. Workunit 2313958942 (blc3_2bit_guppi_57451_23871_HIP63406_OFF_0016.1842.0.18.27.93.vlar) Task 5260480445 (S=25, A=0, P=5, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86 Task 5260480446 (S=28, A=0, P=2, T=0, G=0) SSE3xj Win32 Build 3548 Task 5262508797 (S=27, A=0, P=3, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86 The potential tiebreaker is now assigned to a host running stock v8.00 windows_intelx86, so I think it will be worth watching to see which, if any, of the SoG results it agrees with. Another WU worth watching, I think, is this one: Workunit 2313383895 (20ja16ab.4615.8247.3.30.97) Task 5259241898 (S=10, A=1, P=18, T=0, G=1) v8.00 windows_intelx86 Task 5259241899 (S=2, A=1, P=26, T=0, G=1) v8.19 (opencl_nvidia_SoG) windows_intelx86 Task 5260485168 (S=3, A=1, P=25, T=0, G=1) v8.10 (opencl_nvidia_SoG) x86_64-pc-linux-gnu Task 5261912074 (S=0, A=1, P=28, T=0, G=1) v8.19 (opencl_nvidia_SoG) windows_intelx86 The potential tiebreaker is assigned to my host that's running r3548 and should run sometime tonight. Ideally, I suppose it should match with the stock Windows CPU result, which appears to come from a reliable host. We'll see. On another track, I also noticed a Petri Special x41p_zi3k result that disagrees with a stock Windows CPU result. The counts are the same, so figuring out what the difference is would probably require someone running an offline test to find out the details of what the stock app is reporting. Workunit 2314163650 (blc3_2bit_guppi_57451_24929_HIP63406_0019.6510.831.18.27.140.vlar) Task 5260902641 (S=3, A=0, P=8, T=3, G=0) v8.00 windows_intelx86 Task 5260902642 (S=3, A=0, P=8, T=3, G=0) x41p_zi3k, Cuda 8.00 special The potential tiebreaker will run on one of my hosts under Cuda50. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
It's non-overflow one. x41p_zi3k results are: Pulse: peak=1.226719, time=45.86, period=1.49, d_freq=1668592615.71, score=1.001, chirp=-11.481, fft_len=1024 Pulse: peak=6.817526, time=45.86, period=17.76, d_freq=1668589891.72, score=1.051, chirp=-23.846, fft_len=1024 Spike: peak=24.15228, time=5.727, d_freq=1668594582.93, chirp=26.807, fft_len=128k Spike: peak=24.9091, time=5.727, d_freq=1668594582.92, chirp=26.821, fft_len=128k Spike: peak=24.9591, time=5.727, d_freq=1668594582.93, chirp=26.822, fft_len=128k Pulse: peak=1.082263, time=45.84, period=1.235, d_freq=1668594359.79, score=1.04, chirp=-30.734, fft_len=512 Triplet: peak=10.06536, time=50.06, period=25.57, d_freq=1668594490.91, chirp=46.808, fft_len=512 Triplet: peak=11.66693, time=34.18, period=3.579, d_freq=1668599352.79, chirp=-48.729, fft_len=4k Pulse: peak=6.493984, time=45.9, period=15.39, d_freq=1668597587.71, score=1.03, chirp=48.884, fft_len=2k Pulse: peak=6.051346, time=46.17, period=15.39, d_freq=1668597119.45, score=1.011, chirp=76.46, fft_len=8k Pulse: peak=4.242765, time=45.99, period=9.962, d_freq=1668598651.91, score=1.004, chirp=85.049, fft_len=4k Triplet: peak=11.845, time=51.19, period=19.02, d_freq=1668599959.19, chirp=-89.73, fft_len=128 Pulse: peak=2.303323, time=45.9, period=4.217, d_freq=1668594260.01, score=1.051, chirp=92.159, fft_len=2k Pulse: peak=4.356801, time=45.9, period=10.14, d_freq=1668598243.86, score=1.005, chirp=95.073, fft_len=2k Best spike: peak=24.9591, time=5.727, d_freq=1668594582.93, chirp=26.822, fft_len=128k Best autocorr: peak=16.87552, time=74.45, delay=5.2873, d_freq=1668595826.5, chirp=19.694, fft_len=128k Best gaussian: peak=0, mean=0, ChiSq=0, time=-2.123e+11, d_freq=0, score=-12, null_hyp=0, chirp=0, fft_len=0 Best pulse: peak=6.817526, time=45.86, period=17.76, d_freq=1668589891.72, score=1.051, chirp=-23.846, fft_len=1024 Best triplet: peak=11.845, time=51.19, period=19.02, d_freq=1668599959.19, chirp=-89.73, fft_len=128 SETI apps news We're not gonna fight them. We're gonna transcend them. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Maybe you could speedup its arrival by some micromanaging of that host? SETI apps news We're not gonna fight them. We're gonna transcend them. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
10-1-18-1 so matched CPU. Seems we are ready to start new beta. SETI apps news We're not gonna fight them. We're gonna transcend them. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
The potential tiebreaker will run on one of my hosts under Cuda50. And cause CUDA 5 zi has no signal printing that gave us nothing. All 3 validated eventually and got credits. So bug if any was hided. Offline re-run (by smth more debug-friendly than zi) required in this case and then comparison with saved signal printing. SETI apps news We're not gonna fight them. We're gonna transcend them. |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
10-1-18-1 so matched CPU. Seems we are ready to start new beta. Excellent! For the other WU I mentioned in that post, 2313958942, the stock CPU app also reported a match to the r3548 (S=28, A=0, P=2, T=0, G=0), not the two r3528 results (although they also got credit). That's only two examples, or course, but it seems that both got exactly the desired results. That's very encouraging. |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
I had been focusing on how r3548 matched up against the stock Windows CPU app, but just now took a little time to go back and look at how it measured up against a few of the other stock apps. In WU 2314812653, r3528 (S=11, A=0, P=19, T=0, G=0) disagreed with a Mac stock v8.03 x86_64-apple-darwin (S=16, A=0, P=14, T=0, G=0). My r3548 result agreed with the stock Mac counts, not with r3528. In WU 2314750568, r3528 (S=19, A=1, P=8, T=2, G=0) disagreed with a Linux stock v8.00 x86_64-pc-linux-gnu (S=20, A=1, P=7, T=2, G=0). Again, my r3548 result agreed with the stock Linux counts, not with r3528. That looks very positive to me. |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
Here's another one of those very subtle Inconclusives with the x41p_zi3k special app, similar to the one I had posted a couple weeks ago in Message 1825787. Workunit 2316205882 (blc3_2bit_guppi_57451_27034_HIP69732_0025.16354.831.17.26.69.vlar) Task 5265227923 (S=0, A=0, P=29, T=1, G=0) v8.19 (opencl_ati5_nocal) windows_intelx86 Task 5265227924 (S=0, A=0, P=29, T=1, G=0) x41p_zi3k, Cuda 8.00 special The counts are identical and the "best" signals are essentially the same. All but one of the Pulses show peaks that match to 3 decimal places, with identical periods and scores. Only the very last Pulse seems to be off kilter ever so slightly. x41p_zi3k: Pulse: peak=10.72607, time=45.86, period=27.2, d_freq=1647270240.2, score=1.08, chirp=84.573, fft_len=1024 opencl_ati5_nocal: Pulse: peak=10.78494, time=45.86, period=27.25, d_freq=1647270240.2, score=1.086, chirp=84.573, fft_len=1024 One of my hosts has the potential tiebreaker, but that will run as Cuda50 so it won't provide any signal detail. I also have an r3548 that's Inconclusive against the stock Windows app, but it's more of an "instant" overflow, not one of the Late Stage ones. Workunit 2316218881 (01fe09ac.3129.481.5.32.12) Task 5265255473 (S=18, A=12, P=0, T=0, G=0) SSE3xj Win32 Build 3548 Task 5265255474 (S=21, A=9, P=0, T=0, G=0) v8.00 windows_intelx86 On first look, those were the only two WUs that caught my eye on this evening's list. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Only the very last Pulse seems to be off kilter ever so slightly. Same signature of the issue as before - difference in periods. It's more severe than just difference in peak powers if peak power strong enough.
These ones don't affected last changes cause both spikes and autocorrs are in SoG area. SETI apps news We're not gonna fight them. We're gonna transcend them. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14671 Credit: 200,643,578 RAC: 874 |
One of my hosts has the potential tiebreaker, but that will run as Cuda50 so it won't provide any signal detail. Signals are signals, and the cuda app will certainly provide them - that's the whole point of the exercise. It simply doesn't write a duplicate copy into stderr. First, make that task run at a time when you're around to manage things. Then disable networking while it's running, and copy the result file somewhere else before it uploads. Then set BOINC back to normal and let it do its thing. Second, I once wrote a little tool which I called a 'Summariser' - it should be somewhere in the downloads area at Lunatics. It takes a result file in scientific (XML) format, and spits out the (limited subset of) values in a layout more easily comparable with Raistmer's stderr summary - using text manipulation only, so it doesn't introduce any additional maths errors (though that does mean that over-length values are truncated, not rounded). That certainly leaves enough data to spot the >1% validator-busting discrepancies. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14671 Credit: 200,643,578 RAC: 874 |
A rather different problem, but it's my thread, and since this is where most of the discussion is... Found one of my SoG machines chewing on task 5266682445 just now. This is what BOINC thought it was doing: - but notice no checkpoint. In reality, it hadn't even reached first base. Here is stderr.txt, complete and unedited: Priority of worker thread raised successfully Priority of process adjusted successfully, below normal priority class used OpenCL platform detected: NVIDIA Corporation BOINC assigns device 0 Info: BOINC provided OpenCL device ID used By comparison, here's a more normal display for a task approaching completion: but note it is 'waiting to run' - I suspect it got interrupted by a driver restart. This machine currently hosts my original GTX 470 Fermi card - the BIOS wouldn't accept a GTX 750 Ti when I tried to upgrade a couple of years ago. I had to update the driver to match minimum SoG requirements - I'm currently using v350.12, which is frankly too new for an ordinary Fermi without gaming, and it's been troublesome ever since I installed it - I've had another driver crash since I started typing this note, and I usually have to snooze SoG processing simply to get any work done at all. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
so what is wrong here? driver restart leads to context destruction. If Runtime would return last call to it app would do temporary exit. But there is no return from last call to runtime hence app never got control back. Nothing new, such behavior observed since first OpenCL app introduction many years ago. SETI apps news We're not gonna fight them. We're gonna transcend them. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Here https://cloud.mail.ru/public/2G3G/aj9aBpWaY is update for ATi and NV SoG builds that pass last overflow testcase versus Akv8 CPU. Spike: peak=27.31194, time=41.94, d_freq=1420115137.4, chirp=0, fft_len=32k Spike: peak=25.00008, time=3.355, d_freq=1420115137.4, chirp=0, fft_len=64k Spike: peak=25.94571, time=30.2, d_freq=1420114782.9, chirp=0, fft_len=64k Spike: peak=27.34232, time=36.91, d_freq=1420115491.9, chirp=0, fft_len=64k Spike: peak=34.62092, time=43.62, d_freq=1420115137.4, chirp=0, fft_len=64k Spike: peak=25.59552, time=70.46, d_freq=1420114782.9, chirp=0, fft_len=64k Spike: peak=30.29927, time=77.18, d_freq=1420114782.9, chirp=0, fft_len=64k Spike: peak=26.13545, time=90.6, d_freq=1420114782.9, chirp=0, fft_len=64k Spike: peak=36.72305, time=97.31, d_freq=1420114782.9, chirp=0, fft_len=64k Spike: peak=25.87768, time=104, d_freq=1420114428.4, chirp=0, fft_len=64k Spike: peak=49.95021, time=6.711, d_freq=1420113648.55, chirp=0, fft_len=128k Autocorr: peak=28.35732, time=6.711, delay=0.33853, d_freq=1420117187.5, chirp=0, fft_len=128k Spike: peak=32.8986, time=20.13, d_freq=1420113294.05, chirp=0, fft_len=128k Autocorr: peak=25.26725, time=20.13, delay=0.64881, d_freq=1420117187.5, chirp=0, fft_len=128k Spike: peak=40.69257, time=33.55, d_freq=1420113648.55, chirp=0, fft_len=128k Autocorr: peak=28.97728, time=33.55, delay=0.67707, d_freq=1420117187.5, chirp=0, fft_len=128k Spike: peak=44.54146, time=46.98, d_freq=1420113294.05, chirp=0, fft_len=128k Autocorr: peak=26.62384, time=46.98, delay=2.8492, d_freq=1420117187.5, chirp=0, fft_len=128k Spike: peak=47.76031, time=60.4, d_freq=1420113294.05, chirp=0, fft_len=128k Autocorr: peak=23.55849, time=60.4, delay=0.028262, d_freq=1420117187.5, chirp=0, fft_len=128k Spike: peak=55.79382, time=73.82, d_freq=1420114782.9, chirp=0, fft_len=128k Spike: peak=45.39939, time=87.24, d_freq=1420114782.9, chirp=0, fft_len=128k Autocorr: peak=22.59298, time=87.24, delay=3.1877, d_freq=1420117187.5, chirp=0, fft_len=128k Spike: peak=46.46297, time=100.7, d_freq=1420114782.9, chirp=0, fft_len=128k Autocorr: peak=26.174, time=100.7, delay=1.8618, d_freq=1420117187.5, chirp=0, fft_len=128k Spike: peak=47.66999, time=6.711, d_freq=1420113648.55, chirp=0.00092426, fft_len=128k Autocorr: peak=28.4676, time=6.711, delay=0.33853, d_freq=1420117187.51, chirp=0.00092426, fft_len=128k Spike: peak=32.71175, time=20.13, d_freq=1420113294.07, chirp=0.00092426, fft_len=128k Autocorr: peak=25.06184, time=20.13, delay=0.64881, d_freq=1420117187.52, chirp=0.00092426, fft_len=128k Spike: peak=38.69695, time=33.55, d_freq=1420115491.85, chirp=0.00092426, fft_len=128k OpenCL queue synchronized SETI@Home Informational message -9 result_overflow NOTE: The number of results detected equals the storage space allocated. Best spike: peak=55.79382, time=73.82, d_freq=1420114782.9, chirp=0, fft_len=128k Best autocorr: peak=28.97728, time=33.55, delay=0.67707, d_freq=1420117187.5, chirp=0, fft_len=128k Best gaussian: peak=2.695171, mean=0.6666403, ChiSq=1.315266, time=39.43, d_freq=1420115566.25, score=-8.416527, null_hyp=1.685485, chirp=0, fft_len=16k Best pulse: peak=4.163178, time=65.89, period=1.258, d_freq=1420118560.79, score=0.9425, chirp=0, fft_len=64 Best triplet: peak=0, time=-2.121e+011, period=0, d_freq=0, chirp=0, fft_len=0 Flopcounter: 10790871916.090950 Spike count: 21 Autocorr count: 9 Pulse count: 0 Triplet count: 0 Gaussian count: 0 Please, test more thoroughly. SETI apps news We're not gonna fight them. We're gonna transcend them. |
©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.