OK, good.

Can you give me a laymen's view of how v7 works differently?

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

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.

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.

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.

---

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[

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

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

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

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.

---

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[

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.

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.

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.

Here's Device 1 Running V6, Computer 7258715
Here's Device 1 Running V7, Computer 72013

Around 3200 secs in V6, 3300 in V7...

the beginner (so be gentle into that goodnight :-) )

What average amount of blanking is there on a wu?

Ah, come on, guess.

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.

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

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[

the beginner (so be gentle into that goodnight :-) )

What average amount of blanking is there on a wu?

Ah, come on, guess.

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[

the beginner (so be gentle into that goodnight :-) )

What average amount of blanking is there on a wu?

Ah, come on, guess.

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

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

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.

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.

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

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.

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

Did you check the CPU usage, or now the blank is processed at the GPU?

---

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.