Cheating is no longer possible (To avoid misunderstanding: using the optimized BOINC client was never considered cheating from the project team, ]

Nice one.

MOD.DE I posted by accident in the other thread explaining the credit system and am sorry. had the 2 windows open! sorry delete as necessary!

---

I love Mr. Smith. He keeps us safe from Alien Scum. He's probably good a Rosetta too.

Thanks Hoelder1in,

I guess I know little about the problem faced. If I knew more, I might be able to help, though the database could prove to be a limitation.

I think things will work out over the long run.

-Bradford

---

Many new users and hosts have arrived over the past day... a good sign!

Users (last day ) : 78,055 (+377)
Hosts (last day ) : 172,223 (+709)

Though there's been a drop of active users (and about 10% drop of active hosts)

Yes, there has been quite a dramatic drop in active users and hosts over the last two months - not just in Rosetta but in all of BOINC. But since yesterday active hosts and users seem to be on the rise again in Rosetta while the numbers for all of BOINC are still low. It seems people are voting with their feet (or rather their mouse and keyboard) for the new credit system.

i think thatb the recent BS over all this intra boinc stuff in the past few weeks has given BOINC a very very bad name. there are people out there who won't go near boinc anymore cos of the BS that went on.

---

I love Mr. Smith. He keeps us safe from Alien Scum. He's probably good a Rosetta too.

Many new users and hosts have arrived over the past day... a good sign!

Users (last day ) : 78,055 (+377)
Hosts (last day ) : 172,223 (+709)

Though there's been a drop of active users (and about 10% drop of active hosts)

Yes, there has been quite a dramatic drop in active users and hosts over the last two months - not just in Rosetta but in all of BOINC. But since yesterday active hosts and users seem to be on the rise again in Rosetta while the numbers for all of BOINC are still low. It seems people are voting with their feet (or rather their mouse and keyboard) for the new credit system.

I had written a longer one before with graphs, but my connection dropped.

The problem with the graphs is we will not see the effect until a month or so. Since it is a graph of granted in last 30 days. So what you are really seeing is the people that stopped a month ago.

Not to quarrel, but the Rosetta graph linked to above has data current as of 8/23. The oldest data is a month in age, but an upturn in the last week or so is visible, very similar to those found (at least) in graphs for Einstein@home and SETI. If one looks very closely in the BOINC graph, there also seems to be the beginnings of a late-summer upturn (*very* closely...). ;-)

It's a bit easier to explain downturn/upturn in terms of vacations and summer travel (in the N. hemisphere!)... "Occam's Razor! Occam's Razor!" :-o
Time will tell... :-)

Happy crunching!

Ah well.

On the day my E6700 retail finally turned up, I've pulled my rigs from distributed computing. The x2 4600+ @ 3GHz, 3000+ @ 2.55GHz and 3700+ are having a nice rest and my electricity bills will fall. It has been fun thanks to Xtreme Systems, Free-DC and the Dutch Power Cows, but I think the DC community (and perhaps the technology) needs to mature a little longer. I have other, very expensive things to do now involving horsepower and acceleration... so it's over here for me. :)

Good luck all.

Cuurent system : Calculate a new rolling average, then assign average points
My idea : assign averige points, then calculate new rolling average.

That's really elegant! :-)

This fact has now been confirmed in the 'The new credit system explained' thread.

Actually I put this in after I read your post. ;-)

OK :-) I tweaked the prior post to say it was 'reported'... ;-)

Update: The project has reported that the Validator system failed sometime last night (that would be around 1123UTC, by scanning results!).
No new validation procedure implied; just "pending" while waiting for the Validator to wake up...

It's a bit easier to explain downturn/upturn in terms of vacations and summer travel (in the N. hemisphere!)... "Occam's Razor! Occam's Razor!"

Agreed, I hadn't checked the Einstein and SETI graphs. So the upturn doesn't only happen in Rosetta. And yes, I am a big fan of Occam's Razor. ;-)

---

Team betterhumans.com - discuss and celebrate the future - hoelder1in.org

Cuurent system : Calculate a new rolling average, then assign average points
My idea : assign averige points, then calculate new rolling average.

That's really elegant! :-)

Humorous too. Looks like the message boards need a bit more of that.

Question: as a relatively new contributor, I've not been able to see
if the (new) RAC is calculated over a thirty day period, or some other
timeframe. Anyone know this off the tip of their tongue?

---

Cuurent system : Calculate a new rolling average, then assign average points
My idea : assign averige points, then calculate new rolling average.

That's really elegant! :-)

Humorous too. Looks like the message boards need a bit more of that.

Question: as a relatively new contributor, I've not been able to see
if the (new) RAC is calculated over a thirty day period, or some other
timeframe. Anyone know this off the tip of their tongue?

The new RAC is calculated like the old one. It's complicated and I never understood it. The description is here

---

I am a forum moderator! Am I?

The new RAC is calculated like the old one. It's complicated and I never understood it. The description is here

I think there is an error on the wiki page you linked to: the formula given in the text does not agree with the computer code that is listed on the page. To agree with the computer code the formula should be

RAC(new)=RAC(old)*d(t) + (1-d(t))*credit(new)/(t/86400)

which I think makes more sense: the new RAC is a weighted mean between the old RAC and the new credit/(time in days since the last update) where the weighting function decays the old RAC with a half-time of one week. Well, I agree it is somewhat confusing... ;-)

---

Team betterhumans.com - discuss and celebrate the future - hoelder1in.org

The new system is Lotto. My last 2 results:
CPU-time: 10,061.41 GC: 68.19
CPU-time: 9,951.78 GC: 105.76

So much more points for less work? This been discussed up and down already but users need credits based on how much CPU-time they contribute, when the variation can be as big for same CPU as what i just experienced then something is seriously wrong. "Even out over time", wish those who wrote that also would realize how mongoloid that sounds. I understand it wasnt possible to stop the cheating with the previous credit system but this is a poor substitute. Sorry guys, i cant accept that someone will decide how much work my PC has done, this IS the computing power i contribute and i expect to receive credit based on that, not based on what some other computer estimates, then that computer can do my WUs instead and see how much that will benefit the project.

---

The new system is Lotto. My last 2 results:
CPU-time: 10,061.41 GC: 68.19
CPU-time: 9,951.78 GC: 105.76

So much more points for less work? This been discussed up and down already but users need credits based on how much CPU-time they contribute, when the variation can be as big for same CPU as what i just experienced then something is seriously wrong. "Even out over time", wish those who wrote that also would realize how mongoloid that sounds. I understand it wasnt possible to stop the cheating with the previous credit system but this is a poor substitute. Sorry guys, i cant accept that someone will decide how much work my PC has done, this IS the computing power i contribute and i expect to receive credit based on that, not based on what some other computer estimates, then that computer can do my WUs instead and see how much that will benefit the project.

I would agree there is something fishy there. Both results had 11 decoys, and expended roughly the same amount of time, on the same PC. The scores should have been comparable. It looks like the average for one of those WU types is wacko.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

The new system is Lotto. My last 2 results:
CPU-time: 10,061.41 GC: 68.19
CPU-time: 9,951.78 GC: 105.76

Sorry guys, i cant accept that someone will decide how much work my PC has done, this IS the computing power i contribute and i expect to receive credit based on that, not based on what some other computer estimates, then that computer can do my WUs instead and see how much that will benefit the project.

No no, you're wrong, this new credit-system is as fair as possible, please don't criticise the new system. We are all glad with it :)



Sorry,sorry, I go straight to my room, without diner :')

---

I'm new to this forum, it seems this is a major thorn for many people, and I
know you are all gentle & patient folks [not], so I'll be naive and ask a
silly question..... Unless there is a wide variance in the tasks downloaded,
why can't the simplest possible scoring system be implemented? Something like:

number of finished results (per) last seven days

a) displays the real work for science being done;
b) accounts for processor (& overclocked), OS, rosetta/boinc client;
c) seven days is familiar; accounts for downtime, work-days

Now, throw stones, suggest better, or let's call Occam.


[/quote]
No no, you're wrong, this new credit-system is as fair as possible, please don't criticise the new system. We are all glad with it :)

Sorry,sorry, I go straight to my room, without diner :')[/quote]

---

The new system is Lotto. My last 2 results:
CPU-time: 10,061.41 GC: 68.19
CPU-time: 9,951.78 GC: 105.76

So much more points for less work? ...

:-) At last, someone concerned about getting too many points... ;-)

In a more serious vein, there seem to be two items of concern:
1. Variation in the amount of points between problems that appear to be similar.
2. A seeming lack of correlation between CPU time and points.

For (1.), this is my impression of the process: The calculations required to develop a trajectory--a decoy-- are enormously complex. These are not closed-form direct calculations as in finding the answer with a direct formula. Rather, there are numerous random choices ("Monte Carlo" methods). In addition, the "landscape" over which the search is being made for a "deep valley" of low energy is apparently extremely irregular, with huge thin walls, spikes, wide valleys at high elevation, and perhaps small deep holes on otherwise high terrain. Then calculations are trying to find the deepest point on a very large landscape by hunting around, much like one in total darkness, testing the nearby terrain to see of it gets lower. This is done
by randomly poking around. But just because the terrain gets higher doen't mean that there isn't a beautiful deep valley just over the rise. The calculations are also guided by heuristics, or scientific guesses, to allow the search to continue uphill for a while. Other methods allow the search to hop over a relaively long distance in a random direction just to see if there are lower spots not too far away. It's conceivable that in this terrain, the very lowest point--the global minimum--may be an extremely deep golf hole on a green at the top of a mountain. (Forget about getting your ball back!) With the terrain being so ragged and onpredictable, with different starting points for the search, and with the moves or jumps being random, it seems reasonable that the CPU time to get to some localized deep point--a local minimum--could vary of an extremely wide range.

For (2.), one has to consider the probability that the mix of instructions actually executed during these extremely complex random guided searches does not mirror the mix of instructions used in some benchmark, including the "benchmark" consisting of the average across a number of other computers with different instructio sets. For example, if your computer's processor happens to encounter a whole series of operations that are carried out within the processor's caches, it will literally fly through that series. The avarage computer may not have had that advantage, so it slogs through the operations using operations against the main processor RAM, spending more cycles in the process. As a result, your computer gets done faster, and gets the points sooner, resulting in more points per hour. Asking forgivenes in advance for the analogy, consider that our computers are like trucks pulling a weighted sled around a track. Some people have more horsepower, and can consistently get a sled around faster than others. Sometimes, for some sleds, options like XM radio may help a truck to drag them even faster, while sometimes XM won't help at all. What counts in the end is getting the sled across the finish line.

I apologize in advance if I have mangled any concepts beyond recognition; I'd rather seek forgiveness rather than ask permission... :-)

Happy crunching!

The new system is Lotto. My last 2 results:
CPU-time: 10,061.41 GC: 68.19
CPU-time: 9,951.78 GC: 105.76

So much more points for less work? ...

:-) At last, someone concerned about getting too many points... ;-)

In a more serious vein, there seem to be two items of concern:
1. Variation in the amount of points between problems that appear to be similar.
2. A seeming lack of correlation between CPU time and points.

For (1.), this is my impression of the process: The calculations required to develop a trajectory--a decoy-- are enormously complex. These are not closed-form direct calculations as in finding the answer with a direct formula. Rather, there are numerous random choices ("Monte Carlo" methods). In addition, the "landscape" over which the search is being made for a "deep valley" of low energy is apparently extremely irregular, with huge thin walls, spikes, wide valleys at high elevation, and perhaps small deep holes on otherwise high terrain. Then calculations are trying to find the deepest point on a very large landscape by hunting around, much like one in total darkness, testing the nearby terrain to see of it gets lower. This is done
by randomly poking around. But just because the terrain gets higher doen't mean that there isn't a beautiful deep valley just over the rise. The calculations are also guided by heuristics, or scientific guesses, to allow the search to continue uphill for a while. Other methods allow the search to hop over a relaively long distance in a random direction just to see if there are lower spots not too far away. It's conceivable that in this terrain, the very lowest point--the global minimum--may be an extremely deep golf hole on a green at the top of a mountain. (Forget about getting your ball back!) With the terrain being so ragged and onpredictable, with different starting points for the search, and with the moves or jumps being random, it seems reasonable that the CPU time to get to some localized deep point--a local minimum--could vary of an extremely wide range.

For (2.), one has to consider the probability that the mix of instructions actually executed during these extremely complex random guided searches does not mirror the mix of instructions used in some benchmark, including the "benchmark" consisting of the average across a number of other computers with different instructio sets. For example, if your computer's processor happens to encounter a whole series of operations that are carried out within the processor's caches, it will literally fly through that series. The avarage computer may not have had that advantage, so it slogs through the operations using operations against the main processor RAM, spending more cycles in the process. As a result, your computer gets done faster, and gets the points sooner, resulting in more points per hour. Asking forgivenes in advance for the analogy, consider that our computers are like trucks pulling a weighted sled around a track. Some people have more horsepower, and can consistently get a sled around faster than others. Sometimes, for some sleds, options like XM radio may help a truck to drag them even faster, while sometimes XM won't help at all. What counts in the end is getting the sled across the finish line.

I apologize in advance if I have mangled any concepts beyond recognition; I'd rather seek forgiveness rather than ask permission... :-)

Happy crunching!

All that rhetoric aside, let's look at this example.

2 hr 45 minutes to do 11 decoys, and 2 hr 47 minutes to do 11 decoys.

1 WU gets over 50% more credit than the other.

Now, I could understand this variation if we were only talking about one decoy, but this is 11 per WU! So for this PC, it took roughly 15 minutes to do each decoy, regardless of the type!

Why the big difference in score then?

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

The new system is Lotto. My last 2 results:
CPU-time: 10,061.41 GC: 68.19
CPU-time: 9,951.78 GC: 105.76

So much more points for less work? ...

:-) At last, someone concerned about getting too many points... ;-)

In a more serious vein, there seem to be two items of concern:
1. Variation in the amount of points between problems that appear to be similar.
2. A seeming lack of correlation between CPU time and points.

For (1.), this is my impression of the process: The calculations required to develop a trajectory--a decoy-- are enormously complex. These are not closed-form direct calculations as in finding the answer with a direct formula. Rather, there are numerous random choices ("Monte Carlo" methods). In addition, the "landscape" over which the search is being made for a "deep valley" of low energy is apparently extremely irregular, with huge thin walls, spikes, wide valleys at high elevation, and perhaps small deep holes on otherwise high terrain. Then calculations are trying to find the deepest point on a very large landscape by hunting around, much like one in total darkness, testing the nearby terrain to see of it gets lower. This is done
by randomly poking around. But just because the terrain gets higher doen't mean that there isn't a beautiful deep valley just over the rise. The calculations are also guided by heuristics, or scientific guesses, to allow the search to continue uphill for a while. Other methods allow the search to hop over a relaively long distance in a random direction just to see if there are lower spots not too far away. It's conceivable that in this terrain, the very lowest point--the global minimum--may be an extremely deep golf hole on a green at the top of a mountain. (Forget about getting your ball back!) With the terrain being so ragged and onpredictable, with different starting points for the search, and with the moves or jumps being random, it seems reasonable that the CPU time to get to some localized deep point--a local minimum--could vary of an extremely wide range.

For (2.), one has to consider the probability that the mix of instructions actually executed during these extremely complex random guided searches does not mirror the mix of instructions used in some benchmark, including the "benchmark" consisting of the average across a number of other computers with different instructio sets. For example, if your computer's processor happens to encounter a whole series of operations that are carried out within the processor's caches, it will literally fly through that series. The avarage computer may not have had that advantage, so it slogs through the operations using operations against the main processor RAM, spending more cycles in the process. As a result, your computer gets done faster, and gets the points sooner, resulting in more points per hour. Asking forgivenes in advance for the analogy, consider that our computers are like trucks pulling a weighted sled around a track. Some people have more horsepower, and can consistently get a sled around faster than others. Sometimes, for some sleds, options like XM radio may help a truck to drag them even faster, while sometimes XM won't help at all. What counts in the end is getting the sled across the finish line.

I apologize in advance if I have mangled any concepts beyond recognition; I'd rather seek forgiveness rather than ask permission... :-)

Happy crunching!

All that rhetoric aside, let's look at this example.

2 hr 45 minutes to do 11 decoys, and 2 hr 47 minutes to do 11 decoys.

1 WU gets over 50% more credit than the other.

Now, I could understand this variation if we were only talking about one decoy, but this is 11 per WU! So for this PC, it took roughly 15 minutes to do each decoy, regardless of the type!

Why the big difference in score then?

Basically a flawed system that was put into place before the bugs were worked out.
Movieman

---

I moved some posts to the thread "Report WU with unusual credits granted" since they were dealing with specific WU and might help the project staff to spot a problem.

---

I am a forum moderator! Am I?

An opinion( Not wanted I expect);-)

The credit system, although interesting, is not for the benefit of the science or the project as a whole. A useful measure I`ll grant to Intel or AMD but we don`t I believe work for them. The credit system is for the benefit of the crunchers as a measure of their machines capabilities.

Those capabilities do NOT change hourly unless the machines are working on other things, therefore the measure should relatively be static. A machine doing 40 credits an hour should alway`s do so. Whilst scientifically other measures can be used which show things differently this is of no benefit to the cruncher. A cruncher wants to know how he is doing, he is the boy racer, the cruiser it`s no use telling him it`ll do 30mph there but 120mph there. It has to be a measure of performance, any great differences in that measure and the cruncher WILL automatically think there is a problem with his machine. Most will fine tune their machines to the limit of their capabilities if they then see them get 120 then later 30 it destroys their soul.

If credits are not steady, the reason for an upgrade lessens because the benefits may be hard to see and measure for the USER. The points per hour on a specific machine cannot alter significantly to keep the cruncher happy, anything outside is useless to him as a measure of his tuned machines capabilities.

The new system seems designed, like the RAC possibly, scientifically correct maybe but of no use whatsoever to the streetracer/cruiser. MPH is the all important factor and if I`ve spent $1000-$5000 finely tuning my machine to see it go 30 at one point 150 in another I feel disatisfied, it makes me feel the course is not upto my hardware rather than vice versa. Either way after so much effort and work I`m unhappy.

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.