nm_test14 -- credits, fpops estimate

I've updated work generation a bit (it should be a lot more efficient server side, which should help keep work flowing).

also, i'm trying to dynamically generate the fpops estimate for workunits and am trying to get the credit granted for the new WUs to be around 10.

Let me know if this batch works and if credits seem about right.

---

I've updated work generation a bit (it should be a lot more efficient server side, which should help keep work flowing).

also, i'm trying to dynamically generate the fpops estimate for workunits and am trying to get the credit granted for the new WUs to be around 10.

Let me know if this batch works and if credits seem about right.

nm_test20_345_1227567420 1,524.58cpusec claimed credit=4.23 granted credit=9.97

nm_test12_293_1227537135 1,534.77cpusec claimed credit=4.26 granted credit=46.04

Milksop's 1.22 units 600cpusec claimed credit=1.6 granted credit=17.5 (those numbers are approximate)

One might argue that work units requiring 2.5 times longer to run should not receive half the credit. One might also argue that testing is beyond the normal contribution to the development of the project and might warrant a premium payment, but hardly a severely reduced payment. That simply lacks good quantum numbers!

I've updated work generation a bit (it should be a lot more efficient server side, which should help keep work flowing).

also, i'm trying to dynamically generate the fpops estimate for workunits and am trying to get the credit granted for the new WUs to be around 10.

Let me know if this batch works and if credits seem about right.

nm_test20_345_1227567420 1,524.58cpusec claimed credit=4.23 granted credit=9.97

nm_test12_293_1227537135 1,534.77cpusec claimed credit=4.26 granted credit=46.04

Milksop's 1.22 units 600cpusec claimed credit=1.6 granted credit=17.5 (those numbers are approximate)

One might argue that work units requiring 2.5 times longer to run should not receive half the credit. One might also argue that testing is beyond the normal contribution to the development of the project and might warrant a premium payment, but hardly a severely reduced payment. That simply lacks good quantum numbers!

We're reducing credit granted by milkyway to be in line with other projects. The older app was granting credit at a very high rate due to optimized applications. nm_test12 didn't have a new credit scheme involved, while nm_test20 does.

The real question is, on any other project with that machine, how many credits will be granted for 1,534 seconds of work?

---

Greetings Travis,

I understand the concept of attempting inter-project credit parity. I also have no intention whatsoever of engaging in that long running discussion.

What I question is lack of intra-project credit parity. Why would anyone opt to work 2.5 times as long for half the pay?

Best regards,
EigenState

Greetings Travis,

I understand the concept of attempting inter-project credit parity. I also have no intention whatsoever of engaging in that long running discussion.

What I question is lack of intra-project credit parity. Why would anyone opt to work 2.5 times as long for half the pay?

Best regards,
EigenState

I suppose i could reduce credit from the old app as well. Once the new app is all debugged we won't be running the old app anyways, so then it will be a non-issue.

---

Greetings Travis,

I understand the concept of attempting inter-project credit parity. I also have no intention whatsoever of engaging in that long running discussion.

What I question is lack of intra-project credit parity. Why would anyone opt to work 2.5 times as long for half the pay?

Best regards,
EigenState

Soon there won't be any "old" WUs any more. That solves the problem. :)

---

mic.