Credit-Screw is giving me 54 to 60 credits for these blc WUs. That is really pitiful. I am running 2 WUs on my GPU and each WU is taking about 13 minutes to process. That works out to a WU every 6.5 minutes. Not using the CPU for seti but for theSkyNet POGS. I also started to split my time with on the GPU with Milkyway and Eisenstein as I would like to get both those to the million credit mark.

I have a feeling most will start to see a drop in RAC in the next few days. We will see ow that affects things. Remember the mantra

We are not in it for the credits but the science - Still a decent amount credits for the WUs would go a long way.

Cactus Bob

. . Start to see a drop in RAC? My RAC has been plummeting for the last several days. And it's still going down :(

. . CreditScrew is only giving about half to 2/3 credit for these tasks :( I am getting from 45 to 60 credits even though all the jobs are taking the same time and same amount of work. Aint it wonderful? :)

Stephen

:(

And with only one type of work now, it will not take that long before we get negative credit/task.
CreditScrew will award you for not crunching, Those with multiple machines and GPU, will lose credit faster
than others.

LOL

. . My statistics graphs instead of being a varying horizontal waveform are now just almost vertical lines leading down, down, down :(

Stephen

:(

My RAC was working its way up after a week of forced downtime. And now this....
Before long, I'll lose my gold badge on this mediocre machine, too.
A general crunch strike comes to mind... haha..

...Ghia...

---

Humans may rule the world...but bacteria run it...

My RAC was working its way up after a week of forced downtime. And now this....
Before long, I'll lose my gold badge on this mediocre machine, too.
A general crunch strike comes to mind... haha..

...Ghia...

Everyone else's RAC will be going down too, so you should keep your gold badge.

These WU 'farts' make it a really easy decision to stop 24/7/365 processing.

When I get up in the mornings I will turn on my main rig and process. Occasionally I may fire up my other machine for a few hours.

No sense paying the same for power and getting 1/2 or less of the credit formerly awarded for the same CPU and GPU time. If some WUs time out well..........I'll care 1/2 as much........or less.

---

"Sour Grapes make a bitter Whine." <(0)>

2 minor thoughts ...

And with only one type of work now, it will not take that long before we get negative credit/task.

1) Back before credit-new (long time ago)I once got negative credit. it was "-10,675,007.77" so things could be worse.

2) if credit is assigned per flop ... they have to count flops ... slowing things down so we can be assigned a meaningless number ...

Ed F

Having issues getting work on the Linux cruncher for the past half hour. Triple Update isn't working. Toggling preferences isn't working. If it goes on much longer I will try the ghost recovery protocol.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

My RAC was working its way up after a week of forced downtime. And now this....
Before long, I'll lose my gold badge on this mediocre machine, too.
A general crunch strike comes to mind... haha..

...Ghia...

. . Well it wouldn't have any impact if we called a "go slow action" because the way RACs are now, no-one would notice ... :(

Stephen

:)

My RAC was working its way up after a week of forced downtime. And now this....
Before long, I'll lose my gold badge on this mediocre machine, too.
A general crunch strike comes to mind... haha..

...Ghia...

Everyone else's RAC will be going down too, so you should keep your gold badge.

. . This is no time for being logical ... :)

Stephen

:)

2 minor thoughts ...

And with only one type of work now, it will not take that long before we get negative credit/task.

1) Back before credit-new (long time ago)I once got negative credit. it was "-10,675,007.77" so things could be worse.

2) if credit is assigned per flop ... they have to count flops ... slowing things down so we can be assigned a meaningless number ...

Ed F

. . They are counting FLops. How else do they determine the APR?

Stephen

??

Having issues getting work on the Linux cruncher for the past half hour. Triple Update isn't working. Toggling preferences isn't working. If it goes on much longer I will try the ghost recovery protocol.

. . As usual, my two slower rigs are keeping topped up. It is only the "Big hitter" rig that is being punished with constant "project has no tasks available" responses. I guess that is just a symptom these days of hitting the servers so often. The server end needs an upgrade methinks! SO much for needing/wanting more volunteer crunching ... it would only result in greater and more frequent work starvation.

Stephen

:(

APR is an "artifact" that is only required by CreditScrew - if one goes to a data based credit system it become redundant.

---

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

APR is an "artifact" that is only required by CreditScrew - if one goes to a data based credit system it become redundant.

I was under the impression that APR was a determining factor in the task allotment calculation, in order to determine how many tasks it takes to fill the "Store at least nn days of work" requirement. (At least for those who aren't already maxing out the 100 + 100 limits.) Is that not correct?

APR is an "artifact" that is only required by CreditScrew - if one goes to a data based credit system it become redundant.

I was under the impression that APR was a determining factor in the task allotment calculation, in order to determine how many tasks it takes to fill the "Store at least nn days of work" requirement. (At least for those who aren't already maxing out the 100 + 100 limits.) Is that not correct?

Certainly. When work is needed, the client requests, as a given number of seconds. It's a pretty fundamental requirement that the server, and the client, are working to the same conversion factor (i.e. speed) when calculating how many tasks to send to fill the number of seconds requested.

The client estimate is controlled by APR (directly, for stock applications: indirectly, by manipulating the task size, when running anonymous platform). And the server does the same, and it does work.

The one fly in the ointment is for those semi-upgraded projects which still allow their hosts to use DCF (though I haven't actually noticed one of those for a while). The servers don't consider DCF at all any more: client DCF is much more responsive to short-term changes in workunit performance than the replacement server code, which can lead to "interesting" runtime estimates and work fetch decisions.

Edit: pre-post correction: GPUGrid still allows DCF, but has APR as well.

APR is an "artifact" that is only required by CreditScrew - if one goes to a data based credit system it become redundant.

I was under the impression that APR was a determining factor in the task allotment calculation, in order to determine how many tasks it takes to fill the "Store at least nn days of work" requirement. (At least for those who aren't already maxing out the 100 + 100 limits.) Is that not correct?

. . That is my understanding too.

Stephen

??

Thanks for that confirmation, Richard. I was pretty sure it wasn't just the credit calculation that needed the APR, but would have been hard-pressed to verify that assumption myself. ;^)

The one fly in the ointment is for those semi-upgraded projects which still allow their hosts to use DCF (though I haven't actually noticed one of those for a while). The servers don't consider DCF at all any more: client DCF is much more responsive to short-term changes in workunit performance than the replacement server code, which can lead to "interesting" runtime estimates and work fetch decisions.

Edit: pre-post correction: GPUGrid still allows DCF, but has APR as well.

The worst offender is Einstein which still uses DCF and DOESN'T use APR.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

I still am unable to keep my cache filled on the Linux machine. Down a hundred gpu tasks. Nothing but no work is available messages upon work requests.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

The worst offender is Einstein which still uses DCF and DOESN'T use APR.

Yeah, but Einstein works well.

---

The worst offender is Einstein which still uses DCF and DOESN'T use APR.

Yeah, but Einstein works well.

I would not agree with statement at all ..... not in a month of Sundays. Einstein sends WAY TOO WORK when requested since its estimate of how much work requested is completely out to lunch. I have to abort 2/3 of the tasks it sends me at every request.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)