where can i find information how the RAC is calculated?
My i5 and my i7 gets round about 250 credits per 8h task. The i5 mostly a bit more than the i7.
At least no big difference visible.
The i7 have 8 cores the i5 4 cores.
I would guess the RAC from the i5 should be half of the RAC from the i7 due to the double amount of cores / tasks per time..
But the i7 gets around 5 times more RAC than the i5.


i would like to know where my mistake is.
Thanks a lot.

where can i find information how the RAC is calculated?
My i5 and my i7 gets round about 250 credits per 8h task. The i5 mostly a bit more than the i7.
At least no big difference visible.
The i7 have 8 cores the i5 4 cores.
I would guess the RAC from the i5 should be half of the RAC from the i7 due to the double amount of cores / tasks per time..
But the i7 gets around 5 times more RAC than the i5.


i would like to know where my mistake is.
Thanks a lot.

The missing factor is time. It takes about a month for the RAC to fully stabilise, the I7 is higher because it’s had a few more days to build up.

ok, thanks a lot!

if i look at the float calculation speed
the i5 is with 5400 (4 cores) faster than the i7 with 3500 (8cores) per core.
So i would think the i5 should have a RAC much higher than the half of the i7.

However, right now the RAC is just around 500 (i5) to 2000 (i7)...
Does not fit for me.

Do you know how the RAC is calculated exactly.
What the RAC represents (lets say after 1 month uninterrupted operation)?

Thanks

if i look at the float calculation speed
the i5 is with 5400 (4 cores) faster than the i7 with 3500 (8cores) per core.
So i would think the i5 should have a RAC much higher than the half of the i7.

However, right now the RAC is just around 500 (i5) to 2000 (i7)...
Does not fit for me.

Do you know how the RAC is calculated exactly.
What the RAC represents (lets say after 1 month uninterrupted operation)?

Thanks

The RAC is a weighted average, unfortunately there are several versions each with different rules depending on which system is calculating it (Boinc itself or one of the account managers) and I cannot give you a dot and comma definition of the algorithms used.

Another unfortunate aspect is that the calculation does not take account of start up. It would be reasonable for the date of first result to be subtracted from the current date and the difference used as a maximum for the averaging period but this is not done.

after a month of continuous work the RAC should approximate to the daily total.

If Rosetta is using the standard calculation, RAC is an exponential moving average of credit granted per day. The large discrepancy you see today is due to the effect of the calculation’s very heavy weighting (‘half life’ of 7 days) on the relatively short, and significantly different, histories of the two machines. Over time (measured in weeks), all else being equal, the i7 should end up with roughly 30% higher RAC than the i5 (8 × 3500 vs. 4 × 5400), as you expect.

See also BOINC Computation credit and the implementation in the server source code.

If Rosetta is using the standard calculation, RAC is an exponential moving average of credit granted per day. The large discrepancy you see today is due to the effect of the calculation’s very heavy weighting (‘half life’ of 7 days) on the relatively short, and significantly different, histories of the two machines. Over time (measured in weeks), all else being equal, the i7 should end up with roughly 30% higher RAC than the i5 (8 × 3500 vs. 4 × 5400), as you expect.

See also BOINC Computation credit and the implementation in the server source code.

Why on Earth use such a scheme? It is computationally heavy and, as we are seeing, produces inaccurate results during spin-up.

The far simpler moving average of :-

Today’s Average = Today’s Value * a + Yesterday’s Average * (1 - a)

Gives an equivalent result with a fraction of the overhead and no spin-up problem.

In practice I tend to use a value for a of 0.15 which depreciates each input to less than 1% after 30 days.

far simpler

Doesn’t that formula only work with a fixed update interval? RAC is updated every time credit is granted (at task validation), so BOINC needs to factor the time since the previous calculation into the weighting to cope with variable task durations. (Not saying there isn’t a better way – just speculating about rationale…)

thank you all very much. Now RAC is much better understandable.
So i will just wait.
I just wanted to be sure that there is nothing wrong.

I use the I7 and i5 only for reference.
Iam placing 15xOdroidC4.

The first one is running and the performance is compared as expected very good.
.. and without any noise (no cooling, no fan) and less power consumption.

The C4 makes around 80 credits per 8h task per core. The other both computer around 240 credits.
That makes 3xC4 equal to my i5 MacBook or 6xC4 equal to my i7NUC.
...so the 15x C4 will do some nice work. :-)

Just waiting for the switch and some parts....the C4s are already here.

far simpler

Doesn’t that formula only work with a fixed update interval? RAC is updated every time credit is granted (at task validation), so BOINC needs to factor the time since the previous calculation into the weighting to cope with variable task durations. (Not saying there isn’t a better way – just speculating about rationale…)

Easy enough to update a hidden field each day but only update the output on days with non-zero input.

far simpler

Doesn’t that formula only work with a fixed update interval? RAC is updated every time credit is granted (at task validation), so BOINC needs to factor the time since the previous calculation into the weighting to cope with variable task durations. (Not saying there isn’t a better way – just speculating about rationale…)

Easy enough to update a hidden field each day but only update the output on days with non-zero input.

No, I’ve just checked and that does not work. I’ll investigate further.

far simpler

Doesn’t that formula only work with a fixed update interval? RAC is updated every time credit is granted (at task validation), so BOINC needs to factor the time since the previous calculation into the weighting to cope with variable task durations. (Not saying there isn’t a better way – just speculating about rationale…)

Easy enough to update a hidden field each day but only update the output on days with non-zero input.

No, I’ve just checked and that does not work. I’ll investigate further.

OK, maintain a count of zero days then on non-zero day perform the calculation using input value / count. This would give a high spin up time but this could be alleviated by holding a table of weightings indexed by count for use in the calculation. Easy to code and the spin-up should be no worse than the current method.

If Rosetta is using the standard calculation, RAC is an exponential moving average of credit granted per day. The large discrepancy you see today is due to the effect of the calculation’s very heavy weighting (‘half life’ of 7 days) on the relatively short, and significantly different, histories of the two machines. Over time (measured in weeks), all else being equal, the i7 should end up with roughly 30% higher RAC than the i5 (8 × 3500 vs. 4 × 5400), as you expect.

See also BOINC Computation credit and the implementation in the server source code.

Why on Earth use such a scheme? It is computationally heavy and, as we are seeing, produces inaccurate results during spin-up.

The far simpler moving average of :-

Today’s Average = Today’s Value * a + Yesterday’s Average * (1 - a)

Gives an equivalent result with a fraction of the overhead and no spin-up problem.

In practice I tend to use a value for a of 0.15 which depreciates each input to less than 1% after 30 days.

The original formula has been around a long time but I'm sure the Boinc Developers would LOVE to hear your idea if you indeed have a better plan.
You can join the Boinc Developers mailing list
An easier way might be to find Richard Haselgrove on one of the Projects and PM him about your ideas and how to present them to the Developers.

The Developers are now purely voluntary since the funding ran out but they do still come out with and constantly evaluate the various version of Boinc of both the Server and Client sides.

It takes about a month for the RAC to fully stabilise, the I7 is higher because it’s had a few more days to build up.

Actually, it's more like 2 months.

It falls quickly, but climbs very slowly.

---

Grant
Darwin NT

If Rosetta is using the standard calculation, RAC is an exponential moving average of credit granted per day. The large discrepancy you see today is due to the effect of the calculation’s very heavy weighting (‘half life’ of 7 days) on the relatively short, and significantly different, histories of the two machines. Over time (measured in weeks), all else being equal, the i7 should end up with roughly 30% higher RAC than the i5 (8 × 3500 vs. 4 × 5400), as you expect.

See also BOINC Computation credit and the implementation in the server source code.

Why on Earth use such a scheme? It is computationally heavy and, as we are seeing, produces inaccurate results during spin-up.

The far simpler moving average of :-

Today’s Average = Today’s Value * a + Yesterday’s Average * (1 - a)

Gives an equivalent result with a fraction of the overhead and no spin-up problem.

In practice I tend to use a value for a of 0.15 which depreciates each input to less than 1% after 30 days.

The original formula has been around a long time but I'm sure the Boinc Developers would LOVE to hear your idea if you indeed have a better plan.
You can join the Boinc Developers mailing list
An easier way might be to find Richard Haselgrove on one of the Projects and PM him about your ideas and how to present them to the Developers.

The Developers are now purely voluntary since the funding ran out but they do still come out with and constantly evaluate the various version of Boinc of both the Server and Client sides.

I do realise the difficulties in developing changes to Boinc and I wouldn’t see this as important in the scale of changes required. I was just very surprised a the complexity of the method chosen and the overhead it must impose on the system.

If Rosetta is using the standard calculation, RAC is an exponential moving average of credit granted per day. The large discrepancy you see today is due to the effect of the calculation’s very heavy weighting (‘half life’ of 7 days) on the relatively short, and significantly different, histories of the two machines. Over time (measured in weeks), all else being equal, the i7 should end up with roughly 30% higher RAC than the i5 (8 × 3500 vs. 4 × 5400), as you expect.

See also BOINC Computation credit and the implementation in the server source code.

Why on Earth use such a scheme? It is computationally heavy and, as we are seeing, produces inaccurate results during spin-up.

The far simpler moving average of :-

Today’s Average = Today’s Value * a + Yesterday’s Average * (1 - a)

Gives an equivalent result with a fraction of the overhead and no spin-up problem.

In practice I tend to use a value for a of 0.15 which depreciates each input to less than 1% after 30 days.

The original formula has been around a long time but I'm sure the Boinc Developers would LOVE to hear your idea if you indeed have a better plan.
You can join the Boinc Developers mailing list
An easier way might be to find Richard Haselgrove on one of the Projects and PM him about your ideas and how to present them to the Developers.

The Developers are now purely voluntary since the funding ran out but they do still come out with and constantly evaluate the various version of Boinc of both the Server and Client sides.

I do realise the difficulties in developing changes to Boinc and I wouldn’t see this as important in the scale of changes required. I was just very surprised a the complexity of the method chosen and the overhead it must impose on the system.

I don't disagree with you and THAT could be a good reason to suggest a conversation with the Developers about making some changes, slimmer and faster can be a good thing.

If Rosetta is using the standard calculation, RAC is an exponential moving average of credit granted per day. The large discrepancy you see today is due to the effect of the calculation’s very heavy weighting (‘half life’ of 7 days) on the relatively short, and significantly different, histories of the two machines. Over time (measured in weeks), all else being equal, the i7 should end up with roughly 30% higher RAC than the i5 (8 × 3500 vs. 4 × 5400), as you expect.

See also BOINC Computation credit and the implementation in the server source code.

Why on Earth use such a scheme? It is computationally heavy and, as we are seeing, produces inaccurate results during spin-up.

The far simpler moving average of :-

Today’s Average = Today’s Value * a + Yesterday’s Average * (1 - a)

Gives an equivalent result with a fraction of the overhead and no spin-up problem.

In practice I tend to use a value for a of 0.15 which depreciates each input to less than 1% after 30 days.

The original formula has been around a long time but I'm sure the Boinc Developers would LOVE to hear your idea if you indeed have a better plan.
You can join the Boinc Developers mailing list
An easier way might be to find Richard Haselgrove on one of the Projects and PM him about your ideas and how to present them to the Developers.

The Developers are now purely voluntary since the funding ran out but they do still come out with and constantly evaluate the various version of Boinc of both the Server and Client sides.

I do realise the difficulties in developing changes to Boinc and I wouldn’t see this as important in the scale of changes required. I was just very surprised a the complexity of the method chosen and the overhead it must impose on the system.

I don't disagree with you and THAT could be a good reason to suggest a conversation with the Developers about making some changes, slimmer and faster can be a good thing.

I reacted initially to the idea that Boinc / Rosetta was using an exponential moving average as defined in the linked Wiki page without reading the code that Brian had kindly also included a link to. (In my defence I do not know C++ and generally find it hard to read).

However, before making an official approach to anybody it is important to know what is there and how much work is involved for what proposed benefit so I’ve bitten the bullet and dived into the code provided. It is not as per the Wiki, it is a straight weighted average with allowance made for multi-day gaps in the processing that’s neater than my suggested cludge.

So I apologise for kicking off without checking my facts more thoroughly, score one to the developers :-)