Well... LOL... I finally got a AP WU and I was pleased , I figured about 15 hours of work there... after 21 seconds it was gone... LOL... can't win for loseing it seems...

Your task exited with

In ap_remove_radar.cpp: get_indices_to_randomize:
num_ffts_forecast < 100.  Blanking too much RFI?

That's exactly the problem that WinterKnight reported, that causes problems if you get too many in a row, that they tried to fix, with the fix that introduced another problem, that was worse than the original problem.....

Nothing is GOOD all the time , Not even Ice cream... :-)

Nice quote. Just at the moment, I think I'd settle for the second-best icecream ;-)

My Mac and old P4 have work and a cache. they have no GPU. My I7 has a little Nvidia GTS 250. I have no work and havent had cache in 3 days. I have had to fight to get any work at all. Im not fighting it any more, NNT till the dust settles. Einstien will get some cpu time.
The thing is my other two machines are pretty close to what there normall RAC is.

No angst here. When work is flowing again, NNT will come off.

---

[/quote]

Old James

Well... LOL... I finally got a AP WU and I was pleased , I figured about 15 hours of work there... after 21 seconds it was gone... LOL... can't win for loseing it seems...

Your task exited with

In ap_remove_radar.cpp: get_indices_to_randomize:
num_ffts_forecast < 100.  Blanking too much RFI?

That's exactly the problem that WinterKnight reported, that causes problems if you get too many in a row, that they tried to fix, with the fix that introduced another problem, that was worse than the original problem.....

Nothing is GOOD all the time , Not even Ice cream... :-)

Nice quote. Just at the moment, I think I'd settle for the second-best icecream ;-)

Richard, just an update, maybe I am unlucky, but 20% of the last 20 AP tasks that I've had have "too much blanking"

Another thing about DCF, as Richard found out, there is a safety factor built in, if the DCF goes too low, then it restricts d/loads.

I don't know the value of too low.

0.02

Above that is fine, below it restricts downloads. I don't know what happens if you end up with exactly 0.020000.....

Richard, I just checked and my DCF is 0.015777 as I write this so I'm below the threshold you describe. About 12 hours ago my cache built up to around 145 WU's. This morning the cache was empty and the process seems to be get 1 WU, process, upload the processed WU, wait for the next WU to download.

Is modifying the app_info.xml by adding <flops> values the way to go to affect a change on DCF?

Yes, if you feel comfortable doing that, introducing a flops line would be a good medium-term solution. I'd personally think in terms of removing it again once all this is over, but there are those who advocate leaving it there for good if it seems to be working properly.

Alternatively, if you're genuinely down to one WU at a time for the whole project (which is the way it works when DCF is below 0.02), you could:

Set NNT
Wait for the current WU to finish and upload.
Click 'update' on the project tab to report it (no need to wait until any deferral is complete)
Click 'Reset project'
Allow new work, and wait the requisite 5 minutes for the comms deferral to tick down to zero.

I did that sometime this week, on a machine with an optimised CUDA app - no ill-effects, except that DCF was set back to 1.0000 and started ticking down again. That way, you can buy yourself about 200 - 300 WUs - DCF starts by adjusting very, very slowly, and it takes that long to get back down to 0.02

Obviously, the tasks start by being estimated long again, so you can't download many to start with - but none of us are getting a lot of tasks at once, just at the moment.

'Reset project' is the nearest thing I can think of to a one-click solution just at the moment - everything else involves manual editing of files. But it can't be used if you have multiple applications, and only one of them has run out of work - but in that case, your DCF wouldn't have got down as low as 0.01, so I assume it doesn't apply here.

well my DCF is still dropping... :

Today : Task duration correction factor 0.191399

Was yesterday : Task duration correction factor 0.202202

Today : Average turnaround time 0.02 days

Yesterday : Average turnaround time 0.16 days

The faster and More I do the worse it seems to get ???

Thanks Richard. I'll give your alternative approach a try first as opposed to adding <flops> values. I generally prefer not to tinker with configuration files unless absolutely necessary.

---

well my DCF is still dropping... :

Today : Task duration correction factor 0.191399

Was yesterday : Task duration correction factor 0.202202

Today : Average turnaround time 0.02 days

Yesterday : Average turnaround time 0.16 days

The faster and More I do the worse it seems to get ???

Yes, that's the way it goes.

If you're just teetering on the brink of 0.02, you may find that if you can score a longer mid-AR task (the type with a six-week deadline), running it will put your DCF back up just high enough to resume normal work requests. I've had almost exclusively VHAR shorties today, but just the very occasional mid-AR (mostly resends) has crept into the mix.

The recent CUDA apps do VHAR tasks particularly well, and drive DCF lower than any other type of work.

well my DCF is still dropping... :

Today : Task duration correction factor 0.191399

Was yesterday : Task duration correction factor 0.202202

Today : Average turnaround time 0.02 days

Yesterday : Average turnaround time 0.16 days

The faster and More I do the worse it seems to get ???

Yes, that's the way it goes.

If you're just teetering on the brink of 0.02, you may find that if you can score a longer mid-AR task (the type with a six-week deadline), running it will put your DCF back up just high enough to resume normal work requests. I've had almost exclusively VHAR shorties today, but just the very occasional mid-AR (mostly resends) has crept into the mix.

The recent CUDA apps do VHAR tasks particularly well, and drive DCF lower than any other type of work.

Well ... I guess I'll have to add one of those to my Christmas wish list...

ROFL... ;-)

EDIT : What if I turned GPU work off for now ?

Set NNT
Wait for the current WU to finish and upload.
Click 'update' on the project tab to report it (no need to wait until any deferral is complete)
Click 'Reset project'
Allow new work, and wait the requisite 5 minutes for the comms deferral to tick down to zero.

That worked like a charm. DCF returned to 1 as you indicated and I got 4 new tasks to download at once followed a few minutes later by an additional 17 or so. Things are looking up. Thanks for your help.

---

Use the flops, Floyds, use the flops....:)

Fixed my problem with EstimateBad in a hurry, and I started getting work again.
I took it out prematurely and had to put it back yesterday when the estimates went haywire again.

Only have to insert a line per application in your app_info.xml file with notepad. Back that file up first - if it doesn't work, restore and you're back where you were. Several posters have given the link to Geek@Play's excellent how-to-do-it, but here it is again:

http://setiathome.berkeley.edu/forum_thread.php?id=62293#1055179

This far-from-tech type figured it out - give it a shot.

---

Another Fred
Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop.

I followed Geek's method, but for some reason I had to cut the APR in half to get the estimated times correct.

---

Ok... I am trying to figure something out...

If running the GPU tasks faster means a lower DCF , then slowing the GPU task time will increase or raise the DCF ?

Reason I am asking is I dropped the GPU tasks on my GTX 460SE from 3 back to 2 a couple days ago , if I increase it back to 3 then it will increase the time to Crunch the Cuda fermi tasks and raise the DCF back up ?

Instead of adding the flops to the app info file I mean ...

Any thoughts welcome !


EDIT: I am going to try this and I will post the results later.

I have net seen any WU for my GPU (HD6310) since 2 weeks.
May that be the same problem or somethin completely different?

The <flops> didnt help me.

I didnt change anything since the last WUs were on my Laptop.
So i wonder were the WUs are.

Internet is only sometimes a day for one hour available via mobile.
So maybe that are always the hours where no WUs are at the server?
And that is the reason why i wont reset the project, im afraid of the large data transfer that will be then.

---

Ok... I am trying to figure something out...

If running the GPU tasks faster means a lower DCF , then slowing the GPU task time will increase or raise the DCF ?

Reason I am asking is I dropped the GPU tasks on my GTX 460SE from 3 back to 2 a couple days ago , if I increase it back to 3 then it will increase the time to Crunch the Cuda fermi tasks and raise the DCF back up ?

Instead of adding the flops to the app info file I mean ...

Any thoughts welcome !


EDIT: I am going to try this and I will post the results later.

If you want to try that approach, the other obvious thing would be to downclock your GPU settings with EVGA Precision or whatever tool you use to set GPU clock speeds.
Set it to stupid slow for a few tasks and see if that boosts the DCF back into a different range.

---

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

Ok... I am trying to figure something out...

If running the GPU tasks faster means a lower DCF , then slowing the GPU task time will increase or raise the DCF ?

Reason I am asking is I dropped the GPU tasks on my GTX 460SE from 3 back to 2 a couple days ago , if I increase it back to 3 then it will increase the time to Crunch the Cuda fermi tasks and raise the DCF back up ?

Instead of adding the flops to the app info file I mean ...

Any thoughts welcome !


EDIT: I am going to try this and I will post the results later.

If you want to try that approach, the other obvious thing would be to downclock your GPU settings with EVGA Precision or whatever tool you use to set GPU clock speeds.

If the 3 at a time doesn't help much , that will be a good next step , thanks for the Idea Mark... :-)

Another thing about DCF, as Richard found out, there is a safety factor built in, if the DCF goes too low, then it restricts d/loads.

I don't know the value of too low.

0.02

Above that is fine, below it restricts downloads. I don't know what happens if you end up with exactly 0.020000.....

Not to worry, exactly 0.02 is impossible in IEEE 754 double floating point. According to http://www.binaryconvert.com/convert_double.html, the closest it can come is 0.0200000000000000004163336342344

If you hit that value exactly, it isn't considered "wacky_dcf", and on the high end 80.0 is allowed and can be exactly expressed.

                                                                  Joe

Adding <flops> has certainly help massively, I'm not sure the values are correct, but the estimated times are much better than those generated by the DCF.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Use the flops, Floyds, use the flops....:)

Fixed my problem with EstimateBad in a hurry, and I started getting work again.
I took it out prematurely and had to put it back yesterday when the estimates went haywire again.

Only have to insert a line per application in your app_info.xml file with notepad. Back that file up first - if it doesn't work, restore and you're back where you were. Several posters have given the link to Geek@Play's excellent how-to-do-it, but here it is again:

http://setiathome.berkeley.edu/forum_thread.php?id=62293#1055179

This far-from-tech type figured it out - give it a shot.

Ok I'm trying the flops idea, why not? It can't get much worse than it is now for Me, sigh. At least in regards to S@H... Oh and before I forget It, Thank You for the link. :D

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

Thanks
I'm now downloading something over a hundred tasks, and the target times look about right. I might need to do a little bit of fine tuning but its far better than it was.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Thanks
I'm now downloading something over a hundred tasks, and the target times look about right. I might need to do a little bit of fine tuning but its far better than it was.

I know have 87wu's to feed the hounds with, BT v1.20 says thats about 4 hours worth for Me, its getting better, thanks to a little help from My friends here(and not many years ago). :)

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's