Message boards :
Number crunching :
blanked AP tasks
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 · Next
Author | Message |
---|---|
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
OK, good. It's based on my analysis from many years ago at SETI Beta About Radar Blanking. Blanking is the process of removing data which is unsuitable for processing. The AP v5 through v6 method has been to replace that data with random data shaped to match the frequency distribution of the parts of the WU which are good. Production of that shaped random data has to be done on CPU, so run time of GPU tasks has been strongly impacted. Even on CPU, it has extended run time significantly. AP v7 does two things differently: 1. It does not look for single pulses in the bad sections, so no replacement data is needed there. 2. It replaces bad data sections for repetitive pulse searching with a constant value representing the average power which would be produced by clean data with no RFI or other disturbance. This means that v7 processing for a WU with a lot of RFI requires fewer calculations than a clean WU. For CPU processing, heavily blanked tasks will run a lot faster than clean ones. The parallel nature of GPU processing means that often some good data and some bad data need to be handled simultaneously, so that increased speed cannot be fully realized, but not having to produce shaped random noise means heavily blanked tasks run at essentially the same speed as clean tasks. A corollary is that performance tuning can work the same for both clean and blanked tasks. I don't think I can get any closer to a layman's view than that. Joe |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14653 Credit: 200,643,578 RAC: 874 |
Look this post from Richard, it´s explain a lot about: http://setiathome.berkeley.edu/forum_thread.php?id=75391&postid=1561564 My apologies to Joe for omitting his contribution to the story when I wrote that post. |
merle van osdol Send message Joined: 23 Oct 02 Posts: 809 Credit: 1,980,117 RAC: 0 |
Josef Segur Yes, I can understand at least parts of what you said. Thanks. I think I'll reread that a few times though. I could ask more questions but it might take more time than you have available. |
juan BFP Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 |
V7 is comming so maybe it´s a waste of time ask but why not treat the high % blank WU in the same way the VLARS are treated? IE No VLAR is sended to NV GPU´s. Why not do the same and send High % Blank WU only to CPU crunchers and not to GPU´s crunchers? That will avoid a lot of troubles and optimize the project resources. |
HAL9000 Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 |
V7 is comming so maybe it´s a waste of time ask but why not treat the high % blank WU in the same way the VLARS are treated? IE No VLAR is sended to NV GPU´s. Why not do the same and send High % Blank WU only to CPU crunchers and not to GPU´s crunchers? That will avoid a lot of troubles and optimize the project resources. Where VLAR tasks could error on some systems. Highly blanked AP tasks just run longer. Increased run time of some types of tasks is not a detriment to the project & doesn't cause any difficulty for it. Also I am not sure that the % blanking is known until the task is processed. So work would have to be prescreened to find blanking % if that is the case. I don't think mucking up the scheduler with another special case for NV cards with the release of AP v7 on the way would be fruitful. I recall it took much work to get it to work correctly, then it would break and need more work. Where that time could be spent getting AP v7 ready. SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[ |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
V7 is comming so maybe it´s a waste of time ask but why not treat the high % blank WU in the same way the VLARS are treated? IE No VLAR is sended to NV GPU´s. Why not do the same and send High % Blank WU only to CPU crunchers and not to GPU´s crunchers? That will avoid a lot of troubles and optimize the project resources. For the client blanking the detection of what areas need blanking is done by the client application. So until the application starts on your host and checks the data, the amount of blanking which will be needed is not known. Redesigning the server side preprocessing to do the same kind of checking is of course possible. With the very thin funding volunteers are supplying I doubt it's practical, though. Joe |
kittyman Send message Joined: 9 Jul 00 Posts: 51468 Credit: 1,018,363,574 RAC: 1,004 |
V7 is comming so maybe it´s a waste of time ask but why not treat the high % blank WU in the same way the VLARS are treated? IE No VLAR is sended to NV GPU´s. Why not do the same and send High % Blank WU only to CPU crunchers and not to GPU´s crunchers? That will avoid a lot of troubles and optimize the project resources. Let's not ask the servers to do more than they already do, shall we? LOL. "Freedom is just Chaos, with better lighting." Alan Dean Foster |
juan BFP Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 |
Thanks for the answers, let´s wait for AP7 and see how it handles the blanks, by the test data i was abble to see they are promissing. |
HAL9000 Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 |
Thanks for the answers, let´s wait for AP7 and see how it handles the blanks, by the test data i was abble to see they are promissing. On my hardware the run times are similar between AP v6 on main and AP v7 on Beta. The AP v7 app is a bit faster. Looks like 5-7% for the same amount of blanking. However the build I am using on Beta is between versions. It was needed to troubleshoot some types of hardware not working. So there may be debug code that causes it to run a bit slower than the final version app. SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[ |
Mike Send message Joined: 17 Feb 01 Posts: 34258 Credit: 79,922,639 RAC: 80 |
Thanks for the answers, let´s wait for AP7 and see how it handles the blanks, by the test data i was abble to see they are promissing. I had a task with 90% blanking at beta. Finnished in 28 minutes. It would take over 3 hours on my host with AP6 app. http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=17455299 With each crime and every kindness we birth our future. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Thanks for the answers, let´s wait for AP7 and see how it handles the blanks, by the test data i was abble to see they are promissing. Here's Device 1 Running V6, Computer 7258715 Here's Device 1 Running V7, Computer 72013 Around 3200 secs in V6, 3300 in V7... |
merle van osdol Send message Joined: 23 Oct 02 Posts: 809 Credit: 1,980,117 RAC: 0 |
the beginner (so be gentle into that goodnight :-) ) What average amount of blanking is there on a wu? Ah, come on, guess. |
HAL9000 Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 |
Thanks for the answers, let´s wait for AP7 and see how it handles the blanks, by the test data i was abble to see they are promissing. I had forgotten that with this system I can run CPU or GPU work on it without it bursting into flames. So currently I'm running 1 GPU & 0 CPU tasks. AP v6 CPU times run about 10 hours. Two of the tasks I completed on Beta are over 90% blanked. http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=17490643 http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=17490645 They finished in the 5.5-6 hour window the HD6370m normally takes for v6 tasks. I had a 45% blanked v6 task I was using to compare to the 48% blanked one on Beta. It looks to have been purged. The times were similar for the two. Maybe one of the v6 tasks I have on hand will be over 90% blanked for a better comparison. SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[ |
HAL9000 Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 |
the beginner (so be gentle into that goodnight :-) ) Most of the tasks I seem to get are in the 0-12% range for blanking. The last batch of work we had there were more tasks with higher blanking. We could get a batch of work that contained mostly 80%+ blanked tasks. EDIT: Looking at the first 100 valid AP tasks I had 4 early exist from 30/30 pulses, 1 45%, 1 60%, 1 70%, & the rest were < 10% blanked. Mostly 0% and 5%. SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[ |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
the beginner (so be gentle into that goodnight :-) ) The amount of Blanking depends on how much noise the SETI machine decides to 'remove'. It varies. So, I just looked at your dual ATI machine. I see problems. Are you willing to change a few things? http://setiathome.berkeley.edu/results.php?hostid=7304674&offset=280&show_names=0&state=0&appid=12 1) Make sure the cards are not overheating, the Turks card has errors associated with overheating. 2) Update to the latest AMD Beta driver. I've have issues on different machines with 1348 & 1445. 14.6/14.7 works better on my machines. 3) Find the ap_cmdline_win_x86_SSE2_OpenCL_ATI.txt file in your setiathome.berkeley.edu folder and paste the following line in the file; -unroll 10 -ffa_block 4096 -ffa_block_fetch 2048 -sbs 256 Try that for starters... |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
So, I just looked at your dual ATI machine. I see problems. Are you willing to change a few things? Before the outage, I was about to add; 4) Delete the Binary files ending in .bin, .bin_V6, .bin_V7, and .wisdom from your setiathome.berkeley.edu folder so new ones can be compiled. This should be done after changing Drivers. But, then I realized both your cards appear to be excessively overclocked. My Factory overclocked 7750 comes at 880mhz, yours is 1000. The Turks card comes at either 650 or 800, yours is 1000. So, the first thing I would do is reduce the clocks to at most 50mhz above stock. My stock DDR3 7750 comes at 800mhz, it’s set for 850. I have never overclocked the factory OCed card. The memory shouldn’t be overclocked at all. I had to reduce the stock memory setting on a 6770 to avoid an occasional overflow invalid. An occasional error from excessive overclocking can be fatal in science applications and should be avoided. So...try that. |
merle van osdol Send message Joined: 23 Oct 02 Posts: 809 Credit: 1,980,117 RAC: 0 |
Thanks to all, TBar thanks, it will take me some time to go thru all of that. I have been watching my temp constantly and have never had them over 61C. My 7770 stock clock is supposed to be 1000MHz. For temp I use Both SIV64 and MSI afterburner. --edit-- As far as I know I haven't had either Turks card over 675MHz and then only for a short period of time before I set it back to it's standard of 650MHz. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
If that's a 7770 then 1000 should be stock. Your latest task reports the Turks is set for 1000; Number of devices: 2 Max compute units: 6 Max work group size: 256 Max clock frequency: 1000Mhz Max memory allocation: 536870912 Cache type: None Cache line size: 0 Cache size: 0 Global memory size: 1073741824 Constant buffer size: 65536 Max number of constant args: 8 Local memory type: Scratchpad Local memory size: 32768 Queue properties: Out-of-Order: No Name: Turks Vendor: Advanced Micro Devices, Inc. Driver version: 1348.5 (VM) Version: OpenCL 1.2 AMD-APP (1348.5) Those Run-Times are slow for a 7770, are you running more than one task at a time? On the lower end cards the cmdline settings can be used to increase GPU load so running multiple tasks is not needed. Another thing to check is that you have at least 1 free CPU core to feed the GPUs. It would be best if you had at least 2 free cores when running 2 GPUs. You can accomplish that by opening the Tools/Computing preferences Menu and setting the Processor usage 'On multiprocessor systems, use at most' to 75.00%. |
juan BFP Send message Joined: 16 Mar 07 Posts: 9786 Credit: 572,710,851 RAC: 3,799 |
Thanks for the answers, let´s wait for AP7 and see how it handles the blanks, by the test data i was abble to see they are promissing. Did you check the CPU usage, or now the blank is processed at the GPU? |
merle van osdol Send message Joined: 23 Oct 02 Posts: 809 Credit: 1,980,117 RAC: 0 |
TBar, Both SIV64 and MSI Afterburner report my 6570 running at 650MHZ and my 7770 running at 1000MHZ? I am running 3 tasks at a time. --edit-- I leave one thread open for the 2 gpu's. |
©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.