...
Astropulse, on the other hand, has a very consistent processing cycle on all WUs (no AR variation, as I said before). So consistent, that the developers have resorted to the bluntest of blunt instruments:

#define TOTAL_FLOPS 6.21524e+14

(thanks to Urs Echternacht for discovering and reporting this)

Cool. Since this is a straight define, I suspect that whatever "multiplier" might be needed is buried in the #define -- but either way, it's either the right number, or it isn't, and if it isn't, then the self-adjusting credit that Dr. Korpela implemented will handle it.

Using the fixed value is in effect a commitment that they're not going to change any of the WU header parameters which would affect the amount of processing. I suspect if they'd had more time they would have added a calculation almost exactly like what the ap_splitter uses for calculating total flops:

    // Calculate the number of floating point operations
    boinc_wu.rsc_fpops_est = FFT_LEN;                           // Coadd loops
    boinc_wu.rsc_fpops_est += FFT_OPS+FFT_LEN*6+FFT_LEN/2*4;    // The dechirp function
    boinc_wu.rsc_fpops_est *= 2;                                // Pos/neg dispersion measures
    boinc_wu.rsc_fpops_est *= DM_CHUNK_SMALL;                   // Inner dm loop
    boinc_wu.rsc_fpops_est += FFT_OPS;                          // forward_fft function
    boinc_wu.rsc_fpops_est *= N_BLOCK*data_size/FFT_LEN;        // Raw data loop
    boinc_wu.rsc_fpops_est *= DM_CHUNK_LARGE / DM_CHUNK_SMALL;  // small dm chunk loop
    boinc_wu.rsc_fpops_est += DM_CHUNK_LARGE*FFT_LEN*2*6;       // build_chirp_table function
    boinc_wu.rsc_fpops_est *= (DM_HIGH-DM_LOW)/DM_CHUNK_LARGE;  // Outer two dm loops

There is a constant scaling factor applied after that, currently 6.2, and obviously a different scaling would be needed in the app. Still it's an exact parallel of what setiathome_enhanced does for flop counting.

As a related note, the progress calculations in AstroPulse are quite linear so if the app exits early the constant can simply be scaled by the fractional progress to make a reasonable credit basis. AP does have a non-error early exit like result_overflow.

                                                                 Joe

Sorry, but I am still quite confused as you can see:
1. How often does SETI@home adjust the credit multiplier?
2. How about other BOINC projects?
3. Is a "constant RAC" model possible? I mean constant in that sense that one does not have to buy a new super cruncher two times a year to keep it constant.
4. Did SETI@home adjust the credit multiplier e.g. four years ago?
5. When was the first time they adjusted the multiplier?

Henri.

---

Manned mission to Mars in 2019 Petition <-- Sign this, please.

1. How often SETI@home "fixes" the credit multiplier?

Whenever an adjustment needs to be made. Its not a "fix", but an adjustment or variable to even out the credit given.

2. How about other BOINC projects?

They are supposed to be doing the same.

3. Is a "constant RAC" model possible? I mean constant in that sense that one does not have to buy a new super cruncher two times a year to keep it constant.

Not really. Of course, SETI doesn't ask that you build a new cruncher just because you care about credits more than anyone should. Likewise, it has been stated that a computer using the stock application will still receive the same credit it did six months ago.

4. Did SETI@home "fix" the credit multiplier e.g. four years ago?

When SETI@Home Enhanced came out, the credit multiplier was adjusted because the gains in speed meant that people would be receiving more credit per hour than they should.

5. When was the first time they fixed the multiplier?

They aren't really trying to "fix" the multiplier, they are trying to move it on a sliding scale so that its consistent with the mean machine.

Sorry, but I am still quite confused as you can see:
1. How often SETI@home "fixes" the credit multiplier?
2. How about other BOINC projects?
3. Is a "constant RAC" model possible? I mean constant in that sense that one does not have to buy a new super cruncher two times a year to keep it constant.
4. Did SETI@home "fix" the credit multiplier e.g. four years ago?
5. When was the first time they fixed the multiplier?

Henri.

1) The "credit multiplier" is to scale FLOPs to Cobblestones. It did not exist before BOINC 5 (and it is the reason BOINC 4 returns highly variable credits).

Until now, it could only be adjusted by the release of a new app. (i.e. Enhanced 5.27).

2) To the best of my knowledge, most BOINC projects still use benchmark * time, which isn't very accurate, but does not need adjusting.

3) RAC should be constant now. The definition of a "decent RAC" should increase as better computers become available.

In other words, a machine with a RAC around 250 might be pretty decent today, but in 3 years, it may be considered "slow."

4) I'm pretty sure BOINC 5 is less than 4 years old, so it could not have been adjusted before the BOINC 5 release.

5) If the new system is running, the multipliers (there are now two) are being adjusted daily. The multiplier should be steady unless we get a big burst of high-paying or low-paying work units.

---

Ok. Thanks.

---

Manned mission to Mars in 2019 Petition <-- Sign this, please.

I think some of this needs clarifying before it becomes codified as an urban myth.

4) I'm pretty sure BOINC 5 is less than 4 years old, so it could not have been adjusted before the BOINC 5 release.

What you're saying here is that none of this had any meaning before there was a flop count reporting mechanism built into BOINC - which happened around BOINC v5.2.7.

SETI made use of the flop reporting mechanism in setiathome_enhanced, by 'counting' (actually aggregating block estimates of) flops, and then multiplying the result by a fudge factor. In the early days, this was buried within the code: it became the subject of public discussion almost exactly 12 months ago with the release of the Multibeam application, at which point it theoretically became a variable which could be adjusted for every WU split (and visible in the WU header). However, in practice it has remained fixed at 2.85 throughout the last 12 months.

I'm not sure that this multiplier has any meaning for any project, or application, apart from setiathome_enhanced. Astropulse, for instance, doesn't use it.

5) If the new system is running, the multipliers (there are now two) are being adjusted daily. The multiplier should be steady unless we get a big burst of high-paying or low-paying work units.

The new system is automatic and self-regulating, and could in theory be applied at any project - it isn't SETI-specific as the one we've discussed at (4) is.

There are two application-wide multipliers at SETI: one for Astropulse, and one for setiathome_enhanced. But they don't get adjusted because of, or to influence, any single individual WU: they are much broader tools, operating uniformly across the project as a whole, and adjusted according to the average (median) of the project's daily output.

5) If the new system is running, the multipliers (there are now two) are being adjusted daily. The multiplier should be steady unless we get a big burst of high-paying or low-paying work units.

The new system is automatic and self-regulating, and could in theory be applied at any project - it isn't SETI-specific as the one we've discussed at (4) is.

There are two application-wide multipliers at SETI: one for Astropulse, and one for setiathome_enhanced. But they don't get adjusted because of, or to influence, any single individual WU: they are much broader tools, operating uniformly across the project as a whole, and adjusted according to the average (median) of the project's daily output.

Is for this a min. version of BOINC required?

---

5) If the new system is running, the multipliers (there are now two) are being adjusted daily. The multiplier should be steady unless we get a big burst of high-paying or low-paying work units.

The new system is automatic and self-regulating, and could in theory be applied at any project - it isn't SETI-specific as the one we've discussed at (4) is.

There are two application-wide multipliers at SETI: one for Astropulse, and one for setiathome_enhanced. But they don't get adjusted because of, or to influence, any single individual WU: they are much broader tools, operating uniformly across the project as a whole, and adjusted according to the average (median) of the project's daily output.

Is for this a min. version of BOINC required?

No, it works on the median of the whole 300,000 (or what ever it is) active computers on the project.

Because it looks at the middle, the occasional BOINC v3 (which claims nothing) gets left off one edge, and the occasional self-compiled 'optimised' (i.e. overclaiming) BOINC gets left off the other edge.

I think some of this needs clarifying before it becomes codified as an urban myth.

4) I'm pretty sure BOINC 5 is less than 4 years old, so it could not have been adjusted before the BOINC 5 release.

What you're saying here is that none of this had any meaning before there was a flop count reporting mechanism built into BOINC - which happened around BOINC v5.2.7.

SETI made use of the flop reporting mechanism in setiathome_enhanced, by 'counting' (actually aggregating block estimates of) flops, and then multiplying the result by a fudge factor. In the early days, this was buried within the code: it became the subject of public discussion almost exactly 12 months ago with the release of the Multibeam application, at which point it theoretically became a variable which could be adjusted for every WU split (and visible in the WU header). However, in practice it has remained fixed at 2.85 throughout the last 12 months.

I'm not sure that this multiplier has any meaning for any project, or application, apart from setiathome_enhanced. Astropulse, for instance, doesn't use it.

What I'm saying here is: If a project is running benchmark * time, and it compares the theoretical median credit to the median machine, the multiplier is going to turn out to be incredibly close to 1.

It is only when the project uses a different method (like counting FLOPs, or just using a constant) that we start seeing a "meaningful" direction.

5) If the new system is running, the multipliers (there are now two) are being adjusted daily. The multiplier should be steady unless we get a big burst of high-paying or low-paying work units.

The new system is automatic and self-regulating, and could in theory be applied at any project - it isn't SETI-specific as the one we've discussed at (4) is.

There are two application-wide multipliers at SETI: one for Astropulse, and one for setiathome_enhanced. But they don't get adjusted because of, or to influence, any single individual WU: they are much broader tools, operating uniformly across the project as a whole, and adjusted according to the average (median) of the project's daily output.

My thought here is that we occasionally get a run of VLAR and/or VHAR work that deviates quite a bit from the "average" WU. If we got a batch of "high paying" or "low paying" work, that would definitely show up in the sample for that day, and since it often lasts a few days, the average would move.

Then the run of unusually good or unusually bad work would finish, and the multiplier would reflect a "true" value.

I don't think it'd move much (2%??), but I do think angle range will influence it a little.

---

5) If the new system is running, the multipliers (there are now two) are being adjusted daily. The multiplier should be steady unless we get a big burst of high-paying or low-paying work units.

The new system is automatic and self-regulating, and could in theory be applied at any project - it isn't SETI-specific as the one we've discussed at (4) is.

There are two application-wide multipliers at SETI: one for Astropulse, and one for setiathome_enhanced. But they don't get adjusted because of, or to influence, any single individual WU: they are much broader tools, operating uniformly across the project as a whole, and adjusted according to the average (median) of the project's daily output.

Is for this a min. version of BOINC required?

No, it works on the median of the whole 300,000 (or what ever it is) active computers on the project.

Because it looks at the middle, the occasional BOINC v3 (which claims nothing) gets left off one edge, and the occasional self-compiled 'optimised' (i.e. overclaiming) BOINC gets left off the other edge.

Uhh.. sorry.. my school-english..

So I can go further with Crunch3r's V6.1.0 ?

Or I must go with the newest officially version?

---

5) If the new system is running, the multipliers (there are now two) are being adjusted daily. The multiplier should be steady unless we get a big burst of high-paying or low-paying work units.

The new system is automatic and self-regulating, and could in theory be applied at any project - it isn't SETI-specific as the one we've discussed at (4) is.

There are two application-wide multipliers at SETI: one for Astropulse, and one for setiathome_enhanced. But they don't get adjusted because of, or to influence, any single individual WU: they are much broader tools, operating uniformly across the project as a whole, and adjusted according to the average (median) of the project's daily output.

Is for this a min. version of BOINC required?

No, it works on the median of the whole 300,000 (or what ever it is) active computers on the project.

Because it looks at the middle, the occasional BOINC v3 (which claims nothing) gets left off one edge, and the occasional self-compiled 'optimised' (i.e. overclaiming) BOINC gets left off the other edge.

Uhh.. sorry.. my school-english..

So I can go further with Crunch3r's V6.1.0 ?

Or I must go with the newest officially version?

Please can someone translate in easy english words Richard's post for the not mother-language english spoken people..

Thanks! :-)

---

5) If the new system is running, the multipliers (there are now two) are being adjusted daily. The multiplier should be steady unless we get a big burst of high-paying or low-paying work units.

The new system is automatic and self-regulating, and could in theory be applied at any project - it isn't SETI-specific as the one we've discussed at (4) is.

There are two application-wide multipliers at SETI: one for Astropulse, and one for setiathome_enhanced. But they don't get adjusted because of, or to influence, any single individual WU: they are much broader tools, operating uniformly across the project as a whole, and adjusted according to the average (median) of the project's daily output.

Is for this a min. version of BOINC required?

No, it works on the median of the whole 300,000 (or what ever it is) active computers on the project.

Because it looks at the middle, the occasional BOINC v3 (which claims nothing) gets left off one edge, and the occasional self-compiled 'optimised' (i.e. overclaiming) BOINC gets left off the other edge.

Uhh.. sorry.. my school-english..

So I can go further with Crunch3r's V6.1.0 ?

Or I must go with the newest officially version?

Please can someone translate in easy english words Richard's post for the not mother-language english spoken people..

Thanks! :-)

Well, IMHO you can use any BOINC, just try to keep it running 24/7 and use latest optimised apps ;)

Uhh.. sorry.. my school-english..

So I can go further with Crunch3r's V6.1.0 ?

Or I must go with the newest officially version?

Please can someone translate in easy english words Richard's post for the not mother-language english spoken people..

Thanks! :-)

This is a change to the BOINC servers.

You don't have to change anything.

---

Why, I have to ask, is why anyone would want to compare credits, or anything else, to benchmark scores.

As I pointed out on Beta, two computers, a Q6600 and a Athlon X2 6000+ on same OS, have similar benchmark scores BUT the Q6600 completes an AP unit in under half the time of the AMD. Similar performance is also observed doing MB units.

Please correct me if I go wrong.
If Q6600 has the same benchmark as Athlon X2 but do WU twice faster, it will claim only half of credit that Athlon will claim for the same WU.
So, if it just happened to be the same WU sent to both hosts, Athlon recived only half of claimed credit (cause lowest claimed credit will be used).
Poor AMD user. It will spend twice more time to get twice less credit %).

And what about situation with opt app in this case... It will underclaiming credit (cause it complete result faster than expected by benchmark) and stock app user will go angry to recive less credit for longer calculations... But, maybe it will stimulate him to install opt app? ;)

Why, I have to ask, is why anyone would want to compare credits, or anything else, to benchmark scores.

As I pointed out on Beta, two computers, a Q6600 and a Athlon X2 6000+ on same OS, have similar benchmark scores BUT the Q6600 completes an AP unit in under half the time of the AMD. Similar performance is also observed doing MB units.

Please correct me if I go wrong.
If Q6600 has the same benchmark as Athlon X2 but do WU twice faster, it will claim only half of credit that Athlon will claim for the same WU.
So, if it just happened to be the same WU sent to both hosts, Athlon recived only half of claimed credit (cause lowest claimed credit will be used).
Poor AMD user. It will spend twice more time to get twice less credit %).

And what about situation with opt app in this case... It will underclaiming credit (cause it complete result faster than expected by benchmark) and stock app user will go angry to recive less credit for longer calculations... But, maybe it will stimulate him to install opt app? ;)

Because (at least on SETI) credit is based on floating-point operations, and not on benchmarks, the Q6600 and the Athlon will claim the same credit.

That won't change.

What changes is the scaling between floating-point ops and cobblestones. The scaling factor will adjust to keep the two credit systems "lined up" on average.

... and it won't be based on finding some computer "in the middle" but by finding a mathematical "middle computer" and a "middle wu" and using those two numbers to adjust the scaling.

Optimized applications claim the same number of floating point operations as the non-optimized versions, so that all stays the same. The optimized application still does the same "flop count" as standard, but does it in half the time.

---

Why, I have to ask, is why anyone would want to compare credits, or anything else, to benchmark scores.

As I pointed out on Beta, two computers, a Q6600 and a Athlon X2 6000+ on same OS, have similar benchmark scores BUT the Q6600 completes an AP unit in under half the time of the AMD. Similar performance is also observed doing MB units.

Please correct me if I go wrong.
If Q6600 has the same benchmark as Athlon X2 but do WU twice faster, it will claim only half of credit that Athlon will claim for the same WU.
So, if it just happened to be the same WU sent to both hosts, Athlon recived only half of claimed credit (cause lowest claimed credit will be used).
Poor AMD user. It will spend twice more time to get twice less credit %).

And what about situation with opt app in this case... It will underclaiming credit (cause it complete result faster than expected by benchmark) and stock app user will go angry to recive less credit for longer calculations... But, maybe it will stimulate him to install opt app? ;)

If I understand correctly, we'll be using the same server side credit multiplier at WU issue (as the wingman), and same flop count at our end should match, so same credits.

As I understand the benchmark based calculation is involved with the 'median machine', so once stabilised, only a freak day where the majority of reporting hosts sporting Q6600's could have influence, and I presume it's a sliding figure by nature of numbers, that will creep with average processing performance slowly, rather than lurch around all over the shop.

I think this means also that 'freak' machines like the 'Frozen Penny' don't come into the equation yet until a significant number of similar performance per core make it online. (and by then Mark won't be able to resist the upgrade I reckon)

Jason

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I think this means also that 'freak' machines like the 'Frozen Penny' don't come into the equation yet until a significant number of similar performance per core make it online. (and by then Mark won't be able to resist the upgrade I reckon)

Jason

LOL.....you callin' my Frozen Penny a freak??
I must admit it is a little 'outside of the box', eh?

---

"Time is simply the mechanism that keeps everything from happening all at once."

LOL.....you callin' my Frozen Penny a freak??
I must admit it is a little 'outside of the box', eh?

Oy! Nothing wrong with being a freak! [I hope ;)] Besides, the circus came to town last week, and the freaks tell me the pay, and other perks, are really good! :D [Except of course 'the freak' from the old Australian TV series 'Prisoner' ... *Shudders* ]

Back on topic: I haven't really seen much change in my RAC, is everyone sure something changed ? (Mind you my first AP units are still sitting way down the queue, maybe things'll take a hit then]

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Back on topic: I haven't really seen much change in my RAC, is everyone sure something changed ? (Mind you my first AP units are still sitting way down the queue, maybe things'll take a hit then]

I am down about 25% on my RAC since AP came out and they implemented the new adjustment.

~4200 down to ~3300, exact same 2 machines.

---

To my knowledge.. from what I read here..

For every AP-result you get 715.15 credits.
On a Core2 Quad @ 4 x ~ 3 GHz you will crunch 4 AP-WUs/day..
This would mean a RAC of 2860.6

Before the adj. of the creditsystem I had at well days a RAC of 6,400 with my QX6700 @ 4 x 3.14 GHz. [only Enhanced-WUs]
After around 5,800 [only Enhanced-WUs]
Difference between old and new creditsystem for to now less 10 %.
But the RAC need a month for to be stable..?!

[But the running times wasn't 24/7 so the RACs are not very accurate]

On the other hand.. this would mean a difference of 50 % between Astropulse and Enhanced!! OOoopsss..

---