Where do you get the FLOP actually done figure?

---

I guess the point is not if the new system is more fair that the old one.
I guess the question is, if the new system is fair in itself.

if i look at the last 2 results from an old AMD Duron 900Mhz i see that he requested for 33,503.07sec. of crunching 64.59Credits = 6.94 Credits/hour and he
requested for 73,335.99sec. of crunching 64.22Credits = 3,15 Credits/hour

That cant be right :-)
If he gets for the last one ~32Credits as Granted Credit the comparisson between other clients is also more or less not that what it should supposed to be.

i dont know if i could say much with about 50 seti-enhanced crunched wu's so far with my fastest client, but if i look at this stat for my p4:
http://www.egzb.de/bilder/C.per.h.over.sec.p4.jpg
it seems that crunching with diffrent AR is not very balanced.

Well, lets see...

---

http://www.boincstats.com/signature/user_357263.gif

Hi,

it seems that crunching with diffrent AR is not very balanced.

That's a known problem. They will try to fix it when they have enough data.

Regards,
Carsten

if i look at the last 2 results from an old AMD Duron 900Mhz i see that he requested for 33,503.07sec. of crunching 64.59Credits = 6.94 Credits/hour and he
requested for 73,335.99sec. of crunching 64.22Credits = 3,15 Credits/hour

The per hour quotient is removed with the new system. It's a per flop. So, since it is the same WU, it gets the same credit. The faster machine gets more credit per hour, because it is faster, and can do more flops per hour. Time no longer makes a different in the crunching of a result.

I guess the point is not if the new system is more fair that the old one.
I guess the question is, if the new system is fair in itself.

if i look at the last 2 results from an old AMD Duron 900Mhz i see that he requested for 33,503.07sec. of crunching 64.59Credits = 6.94 Credits/hour and he
requested for 73,335.99sec. of crunching 64.22Credits = 3,15 Credits/hour

That cant be right :-)
...

Guess that is about right my P3 933 MHz is getting 4.17cr/hr on a unit of ar=0.413

A slow computer is not going to get many cr/hr because it can only do 2 or 3 units a day. A fast computer is going to do a lot more units/day and therefore get a lot more cr/hr.

Andy

The athlon 64x2 4200+ has only 512 K of cache per cpu; S@H is incredibly sensitive to cache size!

If you wish make more credits per hour now the only way is to bring more cpu's to the party.

Of use a client that is able to do more calculations per hour.

Yes, in theory... but I'm confused.

Take a look at this result for enhanced.
http://setiathome.berkeley.edu/workunit.php?wuid=79097680
My machine is 1924541 - athlon 64x2 4200+ running crunch3r's 5.12 sse3
This is not a slow machine, and yet it comes out with the slowest time in the set.
The credit system with enhanced seems to work the same as setiathome with the middle claim awarded.

I'm completely mystified!
Andy.

---

The per hour quotient is removed with the new system. It's a per flop. So, since it is the same WU, it gets the same credit. The faster machine gets more credit per hour, because it is faster, and can do more flops per hour. Time no longer makes a different in the crunching of a result.

time should no longer make a diffrence, thats true.
and thats why on the same machine the self calculated credits/hour should be everytime almost the same and not diffrent.

if you didnt noticed it, i didnt compared diffrent machines or machines with a diffrent cpu-load during crunching.
but i must correct myself. i didnt noticed that the displayed time for those posted 2 results was diffrent because i changed during calculation the boinc-client from balancing to to normal on all my machines.
sorry for that, there is nothing wrong as far as i can see because the real cpu-time was almost the same.

time should no longer make a diffrence, thats true.
and thats why on the same machine the self calculated credits/hour should be everytime almost the same and not diffrent.

Well, that is a good theory, but in practice I have noticed it is not the case. On my Athlon 4200 X2, I have two back-to-back workunits completed that were awarded almost identical credits but have vastly different completion times. The first unit completed in just over 17,000 secs (about 63.7 credits, AR=0.41) and the second completed in more than 22,000 secs (about 64.5 credits, AR=.042). Both units were completed overnight with nothing but BOINC running on the machine. Given the very similar AR's, I don't understand the extra hour and twenty minutes on the second unit for a whole .8 credits extra.

time should no longer make a diffrence, thats true.
and thats why on the same machine the self calculated credits/hour should be everytime almost the same and not diffrent.

Well, that is a good theory, but in practice I have noticed it is not the case. On my Athlon 4200 X2, I have two back-to-back workunits completed that were awarded almost identical credits but have vastly different completion times. The first unit completed in just over 17,000 secs (about 63.7 credits, AR=0.41) and the second completed in more than 22,000 secs (about 64.5 credits, AR=.042). Both units were completed overnight with nothing but BOINC running on the machine. Given the very similar AR's, I don't understand the extra hour and twenty minutes on the second unit for a whole .8 credits extra.

You answer your own question. TIME DOES NOT MAKE A DIFFERENCE. The two angle ranges were close enough and got close to the same amount of credit.
AR - cpu-time (h) - Deadline (days)
0.41 - 3.92 - 26.11
0.42 - 3.81 - 25.33

See the difference in CPU time isn't much different, but if you are also using TRUX with the time adjuster on, so your mileage is going to vary differently than others.

You answer your own question. TIME DOES NOT MAKE A DIFFERENCE. The two angle ranges were close enough and got close to the same amount of credit.
AR - cpu-time (h) - Deadline (days)
0.41 - 3.92 - 26.11
0.42 - 3.81 - 25.33

See the difference in CPU time isn't much different, but if you are also using TRUX with the time adjuster on, so your mileage is going to vary differently than others.

Well i also see that his posted result with 17,000sec was calibrated and the true cpu-time was about 24000sec, so the diffrence is not very big and ok.

but can you explain me this result?
http://setiathome.berkeley.edu/workunit.php?wuid=79021453

---

http://www.boincstats.com/signature/user_357263.gif

time should no longer make a diffrence, thats true.
and thats why on the same machine the self calculated credits/hour should be everytime almost the same and not diffrent.

Well, that is a good theory, but in practice I have noticed it is not the case. On my Athlon 4200 X2, I have two back-to-back workunits completed that were awarded almost identical credits but have vastly different completion times. The first unit completed in just over 17,000 secs (about 63.7 credits, AR=0.41) and the second completed in more than 22,000 secs (about 64.5 credits, AR=.042). Both units were completed overnight with nothing but BOINC running on the machine. Given the very similar AR's, I don't understand the extra hour and twenty minutes on the second unit for a whole .8 credits extra.

For AR=0.41 there are 4.9 beam widths in the WU, crunching does all the signal types; this is a fairly typical WU. For AR=0.042 the telescope was hardly moving, everything is within one beam width so Pulse and Triplet finding are worked very hard but Gaussian fitting isn't done. The ARs are quite different, not similar.

Relative crunch time for AR=0.083 and below WUs (single beam width) seems to be sensitive to system type; some systems crunch those slightly faster than "typical" AR=0.4xx WUs, some slower. It may be related to L2 cache size or simply memory bandwidth.

                                                 Joe

but can you explain me this result?
http://setiathome.berkeley.edu/workunit.php?wuid=79021453

The machines that claimed the highest credit are running Boinc versions 4.25 and 4.45. These versions do not calculate credit by FPOP method and so claim credit that is too high. In this case everyone got the high credit awarded.

Berkeley really should lock out these early versions of Boinc that do not award credits based on FPOPS.

---

Boinc....Boinc....Boinc....Boinc....

Sorry, link broken. Hope this one works:

<img src="http://www.boincstats.com/stats/project_graph3.php?pr=sah&table=credits">

---

Well i also see that his posted result with 17,000sec was calibrated and the true cpu-time was about 24000sec, so the diffrence is not very big and ok.

but can you explain me this result?
http://setiathome.berkeley.edu/workunit.php?wuid=79021453

If you're referring to the two 90+ CC values, if you look at the results, you'll see that they were run with 4.25 and 4.45 versions of BOINC.

The minimum recommended version is something like 5.2.6.

The old versions are not Enhanced aware and think that they should determine the credits instead of the application. This doesn't work very well.

---

[quote]Sorry, link broken. Hope this one works:


[quote]
You can always look a the BBCode tags to sort how images are supposed to work

Edit:
Normally if you insert a graph such as this you would/should define what people are looking at... the specific graph extracted from BOINCStats.com is a subset of
http://www.boincstats.com/stats/project_graph.php?pr=sah the Seti@home Project Stats... the specific graph you point out is the Credits Granted over the last 60 days. So in spite of the outage and three days of catching up... You are attempting to point to a "decline" in average granted credit?

I would have to point out that there has been a decline in "active users" over the last month tht could account for a part of the decline in "granted credit"
http://www.boincstats.com/stats/project_graph.php?pr=sah&view=users

that decline is approximately 8,000 users and uncounted computers...

---

Please consider a Donation to the Seti Project.

the specific graph you point out is the Credits Granted over the last 60 days. So in spite of the outage and three days of catching up... You are attempting to point to a "decline" in average granted credit?

I would have to point out that there has been a decline in "active users" over the last month tht could account for a part of the decline in "granted credit"
http://www.boincstats.com/stats/project_graph.php?pr=sah&view=users

that decline is approximately 8,000 users and uncounted computers...

Pappa,

the decline in users is roughly 4.3%. The decline in hosts is even less: 3.8%. But the decline in credits is almost 50%! Keep on cheerleading...

---

Hello,
I think that the real weak point of logic used for the calibration has been mentioned by Paolo.
The move to Seti Enhanced has meant that now we all are using similar optimised code and are increasing science output the ones that were not using it before.

It is not fair to reward an increase in productivity with the same or less credit!
(think how would yourself feel like if it were you, your profession and your boss not corresponding to you improving your work, efficiency,...)

This is to my view the result of using not optimised apps as reference for the new and well optimised Seti Enhanced.

Across the different projects, the system should grant equal credit for equal work (equal flops). In case the application of a project is not well optimized, why has to get the same credit/hour as other better developed?
(better optimisation = more efficient use of energy = something to reward)


Nikor

...
Now with the enhanced you will inject quite 3 times the science into Boinc and claim, again, the same amount of credit.
...

Ciao. Paolo, at1839

EDIT: Btw, it's not mere chance we need a re-calibration. I suspect that many many project run quite obsolete, unefficient code. NOW Seti run optimised. This is exactly where open source show the real power.

---

Well i also see that his posted result with 17,000sec was calibrated and the true cpu-time was about 24000sec, so the diffrence is not very big and ok.

but can you explain me this result?
http://setiathome.berkeley.edu/workunit.php?wuid=79021453

If you're referring to the two 90+ CC values, if you look at the results, you'll see that they were run with 4.25 and 4.45 versions of BOINC.

The minimum recommended version is something like 5.2.6.

The old versions are not Enhanced aware and think that they should determine the credits instead of the application. This doesn't work very well.

Yes, have to get rid of 4.4x clients! I am surprised that they are still available for download :-( Mods, please remove.

http://setiathome.berkeley.edu/workunit.php?wuid=78901888 another case where 4.4x clients are underclaiming. So much for fixed credit per WU, the results are still decided after quorum.

Ver 5.4.9 is well worth upgrading to - the statistics are much better than the original mickey mouse attempt!

Andy.

As long as there is no new BOINC client for Solaris/SPARC, I take it Seti will allow the lowest minimum client to be 4.19

---

Well i also see that his posted result with 17,000sec was calibrated and the true cpu-time was about 24000sec, so the diffrence is not very big and ok.

but can you explain me this result?
http://setiathome.berkeley.edu/workunit.php?wuid=79021453

If you're referring to the two 90+ CC values, if you look at the results, you'll see that they were run with 4.25 and 4.45 versions of BOINC.

The minimum recommended version is something like 5.2.6.

The old versions are not Enhanced aware and think that they should determine the credits instead of the application. This doesn't work very well.

Yes, have to get rid of 4.4x clients! I am surprised that they are still available for download :-( Mods, please remove.

http://setiathome.berkeley.edu/workunit.php?wuid=78901888 another case where 4.4x clients are underclaiming. So much for fixed credit per WU, the results are still decided after quorum.

Ver 5.4.9 is well worth upgrading to - the statistics are much better than the original mickey mouse attempt!

Andy.

To be a little of topic :)

but there's something of interest to me in that particular result.
Result 328849846 (No.1) and result 328849848 (No.3). allmost 40% difference in time.

@Andy Haveland-Robinson,

is your system overclocked ?

---

Join BOINC United now!