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)

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.

That's Boinc averaging Cpu run times with GPU run times. Since Einstein ran out of gravity waves a couple of weeks ago and I now run only seti on the CPUs there is no problem.

---

I've never run cpu tasks at either Milkyway or Einstein. Just Seti ..... just recently as an experiment I ran some cpu tasks at GPUGrid.net.

---

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.

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.

I would agree ...

---

I don't know what you guys are doing, the time estimates on both of my boxes with GTX1060s are very accurate. I run 2 at a time and they process at the rate of 4 an hour, so they estimate 30 min a task.

---

I test ran some Einstein work and it bogged my rig down so far it became totally unusable for anything else. That was during the great SETI outage of '16 and I havn't tried it since.

---

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

I was pretty sure it wasn't just the credit calculation that needed the APR

And running more than 1 WU at a time results in a significantly reduced APR value- even though you might be doing more work per hour. And rescheduling does all sorts of things to APR values.

---

Grant
Darwin NT

I don't know what you guys are doing, the time estimates on both of my boxes with GTX1060s are very accurate. I run 2 at a time and they process at the rate of 4 an hour, so they estimate 30 min a task.

But you get deadline issues on the CPU tasks?

---

Grant
Darwin NT

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.

. . Have you "kicked" the server?

Stephen

??