Speaking of Blanked APs, this batch split since the weekly maintenance is highly blanked :( So much for batch helping with the WOW event.

Speaking of Blanked APs, this batch split since the weekly maintenance is highly blanked :( So much for batch helping with the WOW event.

That's why I am asking the questions. Trying to figure if it's the way the new app handles things, or if the AP splitting errors shown on the SSP are related to the blanking issue.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Mark my main rig has the new version and that's a big NO it doesn't . Well just have to hope the version 7 for the ap does

I can tell you that the blanking is causing me big problems . It caused the PSU to well have problems . I have to keep a eye on it and shut cores off if the units are to highly blanked

Or to put it this way last PSU i bought i bought on Sunday got AP's on Wednesday PSU died Thursday night a few hours after it started to do them .

---

Um i better add i'm not blameing seti it the dam FX chip and Board my intel is also doing AP's and not blowing PSU's and it's only a 400 watt although the GPU is a GT 220 and does not need a power connector to it , it gets the power from the board but run flat out no prob's with the PSU not dieing or overheating

---

Dont mix things up please Glenn.
Software doesn`t destroy Hardware.
Buy appropriate hardware and you wont have Trouble.
You are not the only one crunching on a FX.

---

With each crime and every kindness we birth our future.

Mike as i said it's the fx chip and BOARD . I have had to slow the chip to 3.6 gig and only run 4 units on the cpu if there highly blanked the power drops to 11.54 volt and starts to over heat .At 4 gig the standard speed i can't run any more than 2 if they are highly blanked .

Others that have said there running the FX have different BOARDS

And why i left the second post saying i don't blame the project

The board i have is not on the recommended list at AMD's site

The PSU's i have been using are way over what i have been told by gigabyte to use .
If money was not a problem i would go by another board with a power design of 8+2 and then i mite not be experiencing these problems

EDIT: I can run 7 cores and 2 GPU's doing 2 units doing MB without a problem so you tell me ??

---

Your "only a 400 watt" PSU is probably good brand/model (and powers less demanding system)
Your PSUs of "850 watt" are not (that have to be the problem, not the FX CPU)

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Your "only a 400 watt" PSU is probably good brand/model (and powers less demanding system)
Your PSUs of "850 watt" are not (that have to be the problem, not the FX CPU)

+1

Cheers.

Realy the PSU in the Intel machine is old and not a bought one . IE not a brand name .

I just had a look but the sticker is on the other side and i can't see it but it's the type without a power switch on it and a output plug for a monitor so you are wrong on that account

---

That's why I am asking the questions. Trying to figure if it's the way the new app handles things, or if the AP splitting errors shown on the SSP are related to the blanking issue.

I'm probably going to stir up a hornet's nest with this but.....
I actually don't mind too much (outside of the WOW challenge) when I get work units that eventually get highly blanked. Why, you ask? After all the reading the discussions on just what is going on when the data gets analyzed, I came to appreciate just what is going on. There is talk that v7 "will fix" the blanking problem. Well, not really. It actually just "replaces" the problem. I understand why it is being done. But sacrificing sensitivity for improve specificity leaves a lot of potential signals out of the mix. I know I'm late to the party on this and v7 is well underway in testing in Beta. I guess it just rubs me wrong way when someone says that v7 "fixes" the problem. It doesn't fix it, rather to try to find a signal in a mess of noise, it replaces that entire area with a blanket noise that easier to skip over. I really appreciate all the effort and time that has being put in over the years by everyone that has worked on this project. It's not easy to find people willing to donate their time and expertise in helping this project. I guess I posted this just so people are aware that in order to get a "Faster" AP we do so with the knowledge that might be "throwing out the baby with the bath water." Just my 2 pesos...lol

Zalster

I still don´t understand why they don´t do like the Vlars on NV GPU´s, simply not sending High % Braked WU to GPU´s hosts who can´t realy handle them, sending then instead to CPU hosts who crunch this WU without loss of eficiency. Simple better use of the avaiable resources.

My 2 cents

---

I still don´t understand why they don´t do like the Vlars on NV GPU´s, simply not sending High % Braked WU to GPU´s hosts who can´t realy handle them, sending then instead to CPU hosts who crunch this WU a lot faster. Simple better use of the avaiable resources.

My 2 cents

As it has been said several times now. Blanking is not known previous to processing. Unlike AR which is known before.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

But if the data is changed as explained by Zalters to blank data then there are a way to know that, or change the data will be allmost impossible too.

---

Juan, the areas that we would call blanked data are areas of high frequency (many frequencies) or high background noise when it is analyzed. The program has to remove that noise to look for a signal. Problem is, is that signal that is seen after removal of the "noise" original or was it created by the removal of the background noise. To make the process faster they intend to removal all of the data from that section where lots of "noise" is and replace it with a constant frequency (known to them so they can ignore it), one that can easily be scanned over so that the rest of the data can be looked. That is what I was pointing out

Zalster

Edit.. of course we won't know how much "blanking" will be needed until the data is looked at by the users computer.

Blank data, pink noise, whatever is a waste of resources send this type of WU to our GPU´s. I´m sure you see that clearely, just see the numbers, a normal WU crunch on a host here in less than 1 hr (3k secs), the high % blanked WU crunch in up to 10k secs or more. Don´t mention it´s hard when you see your GPU usage near zero.

OK After the WOW events ends i will follow Raistmer call and switch some of my hosts to test V7 on beta to see if we could give them a hand with the tests. Hope their "fix" realy fix the problem and not realy create a new one.

---

But if the data is changed as explained by Zalters to blank data then there are a way to know that, or change the data will be allmost impossible too.

Your machine is where this will happen. There is not a new server process to do this. Again blanking is only known after you get the data and your machine looks at it.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

That's why I am asking the questions. Trying to figure if it's the way the new app handles things, or if the AP splitting errors shown on the SSP are related to the blanking issue.

I'm probably going to stir up a hornet's nest with this but.....
I actually don't mind too much (outside of the WOW challenge) when I get work units that eventually get highly blanked. Why, you ask? After all the reading the discussions on just what is going on when the data gets analyzed, I came to appreciate just what is going on. There is talk that v7 "will fix" the blanking problem. Well, not really. It actually just "replaces" the problem. I understand why it is being done. But sacrificing sensitivity for improve specificity leaves a lot of potential signals out of the mix. I know I'm late to the party on this and v7 is well underway in testing in Beta. I guess it just rubs me wrong way when someone says that v7 "fixes" the problem. It doesn't fix it, rather to try to find a signal in a mess of noise, it replaces that entire area with a blanket noise that easier to skip over. I really appreciate all the effort and time that has being put in over the years by everyone that has worked on this project. It's not easy to find people willing to donate their time and expertise in helping this project. I guess I posted this just so people are aware that in order to get a "Faster" AP we do so with the knowledge that might be "throwing out the baby with the bath water." Just my 2 pesos...lol

Zalster

I would just say "wrong approach".
Wait if Joe will describe it in more details maybe. AP v7 has better "science", not just better speed on GPU.

But if the data is changed as explained by Zalters to blank data then there are a way to know that, or change the data will be allmost impossible too.

Your machine is where this will happen. There is not a new server process to do this. Again blanking is only known after you get the data and your machine looks at it.

If that is the case i could ask why the fix was not made before, but try to do that when V7 is to close is sure a waste of time/resources.

So let´s wait for V7

---

;) I'm planning on doing that as well. Not all of them but maybe 1 of my 2 big rigs for beta

Zalster

But if the data is changed as explained by Zalters to blank data then there are a way to know that, or change the data will be allmost impossible too.

Your machine is where this will happen. There is not a new server process to do this. Again blanking is only known after you get the data and your machine looks at it.

If that is the case i could ask why the fix was not made before, but try to do that when V7 is to close is sure a waste of time/resources.

So let´s wait for V7

I would guess that the change was only recently devised.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[