Enclosed in this post are comments that I have previously posted, along with updated data and additional comments surrounding that data.

Previous Comments on the Observation of CreditNew Impact Following the Introduction of v7

Shortly after the introduction of v7, I’ve had a look at data around v7 and v6 WUs as well as AP WUs and the following is a quick observational analysis of the data that I was seeing and the impact of v7 in relation to granted credits.
Under v6, I was roughly averaging 100 credits per Work Unit (WU).

Under v7, it seems that the average is sitting around 75-80 credits per WU.
In looking at run-times and taking the outliers out, cpu run time was around 600-660 seconds (10-11 minutes) per WU for v6, and appears to be around 800-1100 seconds (13+ to 18+ minutes) for a v7 WU. CPU time seems to have gone up by a factor of 2-3 from 50-60 seconds for v6 to 90-180 seconds for v7.

So doing a quick Back of the Envelope (10.5/15.83=0.66) shows that from a WU processing/throughput capability, I can expect to do roughly 66% of the volume of WUs that I did before (for example, if I was doing 400 WUs per day under v6, I can now expect to do around 264 WUs per day under v7).

Looking at the impact on credit gives 0.66*0.775 = 0.514 or 51.4%. In essence I can expect that daily credit for v7 will drop to circa 51% of what I was getting under v6.

I am aware of the comments around “that the system needs time to settle down” and that “it thinks all the WUs coming back at the moment are easy, hence the low credit” however, if the system continues to perform as is, then I can expect to see no change from current trajectory.

To test the assumption, I have looked at credit per day pre v7 and post v7 implementation (the data is contained below).

The average daily credit prior to migration was 221,878. Following migration on 1st June, the average daily credit is showing as 102,376 which is circa 46.1% of the previous daily average under v6. Up to and including 22 June, I saw no real change in daily total even though was comment that the credit system had been tweaked.

As part of my thinking, I decided to “benchmark” v7 credits against Astropulse credits. I started this on 23 June with the migration of a single box. Over the next day or two, I noticed what appeared to be an increase in daily totals, so decided to migrate the other two boxes to AP only to see what the full impact would be.

The assumption that I was running with was that pre v7, v6 and AP should have been fairly well benchmarked against each other and that the granting of credits would be in approximate equilibrium based on a daily basis.
If this was the case, then I would expect to see a rise in daily totals from circa 102k to circa 220k and for the daily total to remain around 220k. From 23 June onwards, totals increased on a daily basis towards the peak of 222k on 29 June. Unfortunately there was a lack of AP WUs starting around 30 June and so daily totals declined over the last few days until 5th July when AP was once again available.

From 5th July to 23rd July I once again only processed AP WUs. Ignoring credits from the 5th and 6th July (due high mix of v7 valids) gives average credit per day of 221,276 (over the period 7July to 23 July inclusive.
From 24 July onwards, AP work units have not been available and so I have been processing only v7 work units. As can be seen by the data, daily credit is falling towards its previous average of 102k. It may settle at a number different to this but it will none the less be circa 50% of daily totals under AP.

My observation in here (albeit based on a small amount of data) is that v6 and AP seemed to be fairly well benchmarked against each other. The issue is with v7. V7 WUs are not well benchmarked against v6 WUs, nor are they well benchmarked against AP WUs. In fact, one can almost double their existing daily run rate through only processing AP WUs.

I appreciate that this is just data for one individual, but from what I see, it is symptomatic of what others are seeing as well. I also appreciate that there is a view that has been expressed within the forums by others that Dr Anderson is of the belief that the system is working as designed however, the data below contradicts this belief.

In the interests of the scientists involved in this project and the volunteers that dedicate resources to this project (many of them at high personal expense), I am asking for a review of the design of the credit system, coupled with some forensic analysis to determine if said design is flawed.

Overall, whilst some may feel that the system “is working” there are many volunteers that think it is not working as it should be and that there is an issue within the design of the system that is causing v7 WUs to be granted a seemingly lower rate of credits than maybe should be the case and I am asking for the above in the interests of all.

New Comments on the Observation of CreditNew Impact Following the Introduction of v7

The attached data covers the period 16 May to 15 September. I have oscillated the machines from v7 to AP and back based on the availability of AP. One of the effects that is evident is that it takes about 1 day for the impact of the switch to start to show itself in the daily totals.

What the data quite clearly shows is that despite the tweaking carried out by Berkeley, the credit system is not balanced and that v7 work units still attract significantly less credit than v6 did or AP does.

As I have said before, I do not believe that tweaking is the answer. Berkeley needs to look at the design (conceptual and logical) and determine the root cause of the issue. Once they understand the issue, then they can re-frame the solution and test, with volunteers if necessary. However at the moment they are not doing this which will only lead to continued angst and frustration at both ends.

Daily run rates:

Seti@home enhanced work units (wus) only.

2013.05.16 – 244,130
2013.05.17 – 220,168
2013.05.18 – 231,098
2013.05.19 – 226,353
2013.05.20 – 224,723
2013.05.21 – 210,477
2013.05.22 - 0
2013.05.23 – 431,485
2013.05.24 – 229,312
2013.05.25 – 228,767
2013.05.26 – 239,021
2013.05.27 – 231,271
2013.05.28 – 231,050
2013.05.29 – 0
2013.05.30 – 392,635
2013.05.31 – 209,556

Migration of all computers to seti@home v7 on “day 1”

2013.06.01 – 123,072
2013.06.02 – 94,061
2013.06.03 – 102,333
2013.06.04 – 99,896
2013.06.05 - 65,653
2013.06.06 - 112,209
2013.06.07 - 102,538
2013.06.08 - 110,760
2013.06.09 - 89,757
2013.06.10 - 96,018
2013.06.11 - 111,653
2013.06.12 - 90,091
2013.06.13 - 119,848
2013.06.14 - 99,884
2013.06.15 - 104,561
2013.06.16 - 110,566
2013.06.17 - 110,603
2013.06.18 - 102,856
2013.06.19 - 85,268
2013.06.20 - 140,694
2013.06.21 - 70,247
2013.06.22 - 109,698

Migration of all boxes away from v7 only to AP only (over period of ~4 days)

2013.06.23 – 126,873
2013.06.24 – 141,847
2013.06.25 – 169,625
2013.06.26 – 169,517
2013.06.27 – 183,693
2013.06.28 – 206,019
2013.06.29 – 222,126
2013.06.30 – 211,468
(Lack of AP work unit availability from here, enabled processing of v7 work units)
2013.07.01 – 182,394

Note: 1st August 2013: Noticed 1 day discrepancy between results in BOINCstats/BAM and Free-DC. Free-DC lists results as being 1 day earlier than BAM. Results for 2nd July (119,271) missed as a result but now included. Dates adjusted to reflect and align with dates in BAM.

2013.07.02 – 119,271
2013.07.03 – 66,497
2013.07.04 – 114,962
2013.07.05 – 136,995
2013.07.06 – 124,333
(AP work units available part way through day. All v7 work units aborted and v7 deselected in preferences – processing of AP work units only from this point)
2013.07.07 – 177,095
2013.07.08 – 206,386
2013.07.09 – 215,145
2013.07.10 – 226,249
2013.07.11 – 225,827
2013.07.12 – 204,476
2013.07.13 – 268,704
2013.07.14 – 225,795
2013.07.15 – 215,721
2013.07.16 – 245,191
2013.07.17 – 179,378
2013.07.18 – 252,912
2013.07.19 – 248,430
2013.07.20 – 195,626
2013.07.21 – 176,686
2013.07.22 – 231,015
2013.07.23 – 229,457
2013.07.24 – 214,695
(AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home preferences)
2013.07.25 – 197,347
2013.07.26 – 185,041
2013.07.27 – 147,529
2013.07.28 – 148,774
Comment: No CPU or GPU APs on i7, 53 CPU APs left on Q9450, 64 CPU APs left on Q6600 – 14:42 local)
2013.07.29 – 135,518
2013.07.30 – 132,605
2013.07.31 – 105,612
2013.08.01 – 170,818
2013.08.02 – 145,184
2013.08.03 – 129,548
2013.08.04 – 143,947
2013.08.05 – 136,038
2013.08.06 – 129,675
Local Time 13:55, 6 August. AP WUs available, ceased download of v7 WUs and aborted all v7 WUs (CPU and GPU) across all machines, v7 de-selected in seti@home preferences)
2013.08.07 – 96,293
2013.08.08 – 209,741
2013.08.09 – 223,880
2013.08.10 – 213,615
2013.08.11 – 233,952
Local Time 10:30 11 August. (AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home preferences)
2013.08.12 – 212,721
2013.08.13 – 168,775
Local Time 13:10- 13 August. (AP WUs available, ceased download of v7 WUs and aborted all v7 WUs (CPU and GPU) across all machines, v7 de-selected in seti@home preferences)
2013.08.14 – 114,831
Local Time 15:30 14 August. (AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home preferences)
2013.08.15 – 239,833
Local Time 08:51- 15 August. (AP WUs available, ceased download of v7 WUs and aborted all v7 WUs (CPU and GPU) across all machines, v7 de-selected in seti@home preferences)
2013.08.16 – 201,245
Local Time 18:15 16 August. (AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home preferences)
2013.08.17 – 255,106
2013.08.18 – 191,307
Local Time 14:25- 18 August. (AP WUs available, ceased download of v7 WUs de-selected in seti@home preferences)
2013.08.19 – 187,036
Local Time 20:35 – 19 August (AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home preferences)
2013.08.20 – 223,720
2013.08.21 – 165,272
Local Time 11:30- 21 August. (AP WUs available (not many available), ceased download of v7 WUs de-selected in seti@home preferences)
2013.08.22 – 184,691
Local Time 09:30 – 22 August (AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home preferences)
2013.08.23 – 159,981
2013.08.24 – 152,501
2013.08.25 – 162,481
2013.08.26 – 145,759
Local Time 08:45 - 26 August. (AP WUs available, ceased download of v7 WUs de-selected in seti@home preferences, and aborted all v7 wus across all machines)
2013.08.27 – 146,581
Local Time 07:15 – 27 August (AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home)
2013.08.28 – 166,216
Local Time 11:30 - 28 August. (AP WUs available, ceased download of v7 WUs de-selected in seti@home preferences, and aborted all v7 wus across all machines)
2013.08.29 – 158,164
2013.08.30 – 200,924
2013.09.01 – 205,214
2013.09.02 – 225,448
2013.09.03 – 203,822
2013.09.04 – 211,468
Local Time 07:48 – 4 September (AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home)
2013.09.05 – 235,696
2013.09.06 – 166,536
2013.09.07 – 158,091
Local Time 09:00 – 7 September (AP WUs available, ceased download of v7 WUs de-selected in seti@home preferences)
Local Time 14:23 – 7 September (AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home)
2013.09.08 – 167,621
2013.09.09 – 159,543
2013.09.10 – 169,547
2013.09.11 – 129,568
Local Time 07:52 – 11 September (AP WUs available, ceased download of v7 WUs de-selected in seti@home preferences)
2013.09.12 – 152,963
2013.09.13 – 201,197
Local Time 11:10 – 13 September (AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home)
2013.09.14 – 216,246
2013.09.15 – 166,155

---

Over this same period have you noticed a drop in the average cobblestones awarded for AP task now?

Pre-MB7 AP's averaged around 785, but now that has dropped to around 710.

So it seems that some sort of leveling is happening.

Cheers.

In the interests of the scientists involved in this project and the volunteers that dedicate resources to this project (many of them at high personal expense), I am asking for a review of the design of the credit system, coupled with some forensic analysis to determine if said design is flawed.

What the data quite clearly shows is that despite the tweaking carried out by Berkeley, the credit system is not balanced and that v7 work units still attract significantly less credit than v6 did or AP does.

As I have said before, I do not believe that tweaking is the answer. Berkeley needs to look at the design (conceptual and logical) and determine the root cause of the issue. Once they understand the issue, then they can re-frame the solution and test, with volunteers if necessary. However at the moment they are not doing this which will only lead to continued angst and frustration at both ends.

---

Hi,
I run a dual core E4700 with one doing SETI and one doing MW@H. I have a problem in that my system seems to favour MW@H work over SETI. When left unattended recently it ran more MW@H work than SETI and I had a daily total c 1600 cobblestones. Now that I am trying, by suspending MW@H, to even the work out more, my daily total is c 1200.
I know that this thread is about a change in the credit system for SETI with the introduction of v7 but surely BOINC should award roughly equal credit for all its projects and all their versions.
If I were merely concerned about cobblestones then I would migrate both cores to MW@H but I am interested in both and not in the least competitive.

BOINC should make an effort to even out the credit across all its projects and then we would not have this problem when migrating from one version to another within SETI.

John

Hi,
I run a dual core E4700 with one doing SETI and one doing MW@H. I have a problem in that my system seems to favour MW@H work over SETI. When left unattended recently it ran more MW@H work than SETI and I had a daily total c 1600 cobblestones. Now that I am trying, by suspending MW@H, to even the work out more, my daily total is c 1200.
I know that this thread is about a change in the credit system for SETI with the introduction of v7 but surely BOINC should award roughly equal credit for all its projects and all their versions.
If I were merely concerned about cobblestones then I would migrate both cores to MW@H but I am interested in both and not in the least competitive.

BOINC should make an effort to even out the credit across all its projects and then we would not have this problem when migrating from one version to another within SETI.

John

I think your point about cross project comparisons is a very good one that is not often mentioned. SETI is one of a few, or perhaps the only, project that uses CreditNew (I call it CreditFew). Some others use a flat rate system where a given task is worth xx credits whether it is crunched on a fast gpu or a slow cpu. Simple but elegant. Some still use the old BOINC claimed credit system and they seem to be at disadvantage, even against SETI.

As to running multiple projects with BOINC v7, I've some ideas but it would be a long digression in this thread. I'll send you a pm with some suggestions - if you want to discuss or don't understand, open a thread.

Lionel, I fully support your efforts and thank you for taking the lead in keeping this issue on the table.

---

Another Fred
Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop.

SETI is one of a few, or perhaps the only, project that uses CreditNew (I call it CreditFew).

I happen to call it CreditScrewed......LOL.
But I gave up worrying, wondering, obsessing, or puzzling over it long ago.

---

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

SETI is one of a few, or perhaps the only, project that uses CreditNew (I call it CreditFew).

Subscribers to the boinc_projects mailing list will know that Eric Korpela is fully aware of this situation, and emailed the list last week in an attempt to verify this assertion. From the limited number of replies he received, it is clear that SETI is not the only project running CreditNew - I refer you (as I also referred Eric) to http://lhcathomeclassic.cern.ch/sixtrack/forum_thread.php?id=3754&postid=25782: Igor Zacharov states categorically that

All credit assignments as per boinc library settings and it is the NewCredit system.

In the past, we did experiment ...

There are other cases, as well.

Now I'll happily agree that there may not be any other (production) projects relying on CreditNew for GPU application credit - the jury's still out on that one. But I think we ought to be careful about making strong assertions without citing evidence or sources.

SETI is one of a few, or perhaps the only, project that uses CreditNew (I call it CreditFew).

Subscribers to the boinc_projects mailing list will know that Eric Korpela is fully aware of this situation, and emailed the list last week in an attempt to verify this assertion. From the limited number of replies he received, it is clear that SETI is not the only project running CreditNew - I refer you (as I also referred Eric) to http://lhcathomeclassic.cern.ch/sixtrack/forum_thread.php?id=3754&postid=25782: Igor Zacharov states categorically that

All credit assignments as per boinc library settings and it is the NewCredit system.

In the past, we did experiment ...

There are other cases, as well.

Now I'll happily agree that there may not be any other (production) projects relying on CreditNew for GPU application credit - the jury's still out on that one. But I think we ought to be careful about making strong assertions without citing evidence or sources.

I could not comment, because I have not crunched anything but Seti for a long while now.

---

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

From the limited number of replies he received, it is clear that SETI is not the only project running CreditNew.

As far as I know, the next big project running it is WCG. The CreditNew design is a joint work of Dave and Kevin Reed of WCG, so it would be weird that one of its designers isn't using it at his own project. I also have a confirmation of that somewhere, but can't find it that quickly.

And PS, nice to record CN over the course of some months, but shouldn't that be done based on non-optimized (anonymous platform) applications? And if you do want to compare it against optimized SE6, shouldn't you at least do it based on the same optimization, e.g. SSE vs SSE, not SSE vs AVX?

---

What CreditScrew is trying to do is create the "universal money", some kind of "earth credit", that not works in the real world.

We in the real world have few diferent currencies, and live perfect with them. We have currency exchanges to balance them (work beter or less due goverment politics).

In a real world example, we don´t need 1 US dollar (lets call that SETI credit) = 1 Australian dollar (1 WCG credit for example), what we need is the dollar in CA (lets call that AP) equals to the dollar in FL (MB for example), the US$ must be the same in the entire country (the entire SETI project), is that so dificult to understand?

What is happening in SETI is, you work 1 hour in CA and you receive 1000 dollars the same 1 hour in Florida you receive only 500 dollars, obviously most of the workers will go to work in CA, until no more work is avaiable there. It´s the humman nature. Some say we are volunteers, credits means nothing... If that true then why this all about?

But there are some like me who refuses to leave FL and feel bad about that, then decides to find a new job.

We all know Eric is aware of the problem, but the problem is not Eric, is Dr. A. who aparently refuses to agree that something is wrong with the dessing of CreditScrew. He is the one we need to sensibilize.

---

I guess I should reiterate my views on 'CreditScrewed'.
I don't like it much, but as I see it, does not undermine my position here on Seti, as it treats all crunchers alike.

So, in Seti's world, it does not really affect the ranking of various Seti participants. Call it neutral.

Now, it might serve my pride a bit if I could show the rest of the Boinc world a 500 or 600 RAC, which might more truly represent the crunching power I have in terms of pre-v7 credits.

And I am very RAC driven.....I have been for 13+ years. That competition led me to build bigger and better computers and has led me to where I am today.
But, I am obviously not a simple 'credit whore'...else I would have left Seti long ago. Other projects are just not ME. And I have dabbled in them in the past.

I am 'that obsessive Seti guy' that sticks with the project through thick and thin. I shall stay here no matter what. And even though at this time, my RAC does not reflect what it may have in the past,
THIS IS THE NEW NORMAL.

I am quite fine with that, and everybody else should be too.
I still, at the moment, and it can be fleeting, hold the world's highest RAC for Seti in the world. With the same equipment I had before the v7 change.

I DO NOT CARE how Seti compares with other projects. There simply IS no comparison.

Seti is the gold standard. What if some other new project started to offer 100 times the going Seti rate for crunching. I suspect some might flock to it like flies on s**t so they could brag about how many credits they were accumulating.
Not me, not ever. It simply has no interest for me.

Please, will some of you start to recognize this?
There is NOT, as evidenced by Dr. Anderson's responses, going to be any major overhaul of CreditScrewed. And, at times I can see his point.

The real problem here is that other projects are not being forced to play by the same rules as Seti does. And are allowed to award what they wish. THAT I do hold Dr. Anderson somewhat accountable for, as he could force them to come in line. I don't know why he does not, other than like myself, he is not too concerned with what other projects award compared to Seti.

Long story short......
My position is that Seti awards all Seti participants on an even basis.
If you cannot handle the current 'rate of exchange' and your priorities are different than my own, please go to your favorite project and stop arguing dead points about the credits issued here.

Meow.

---

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

All I know is, once I was sure that my mouse skills were good enough (post stroke) to do all the installs for V7 with Lunatics apps, I was somewhat bemused by the credits received for the time spent (on my PC - the other PC is another story!)....by my reckoning, about half what I expected. Strictly speaking, the credits are not that important, but, if my CPU is spending XXXXX secs on a WU, then surely the 'reward' should reflect that. It should at least be roughly equal to what it was under v6, not half!

I'm already getting grief with my partners PC, which has been running Vista 64 without issue for a few months now - with S@H V7 and the Lunatics apps installed; it now crashes every 5 mins running S@H. I know my employers don't place a value on my time and effort, but this is a bit much.

All things considered, the Vista 64 V7 et al installation, is going to come off my partners PC and I'll wait and see if it is even worth installing V7 on the XP 32 drive. I've been 'out of the loop' for a while and I'm not impressed, to say the least.

---

Don't take life too seriously, as you'll never come out of it alive!

All I know is, once I was sure that my mouse skills were good enough (post stroke) to do all the installs for V7 with Lunatics apps, I was somewhat bemused by the credits received for the time spent (on my PC - the other PC is another story!)....by my reckoning, about half what I expected. Strictly speaking, the credits are not that important, but, if my CPU is spending XXXXX secs on a WU, then surely the 'reward' should reflect that. It should at least be roughly equal to what it was under v6, not half!

I'm already getting grief with my partners PC, which has been running Vista 64 without issue for a few months now - with S@H V7 and the Lunatics apps installed; it now crashes every 5 mins running S@H. I know my employers don't place a value on my time and effort, but this is a bit much.

All things considered, the Vista 64 V7 et al installation, is going to come off my partners PC and I'll wait and see if it is even worth installing V7 on the XP 32 drive. I've been 'out of the loop' for a while and I'm not impressed, to say the least.

Hiya, Iona.
Nice to see you here.

The point I am making is whether a certain WU is awarded 100 credits 'reward' or 1000, the science done is the same. Some may think that this reflects their computers are doing less work.....they are NOT.

Most are doing more work, since the stock apps are now the optimized apps previously.

---

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

Most are doing more work, since the stock apps are now the optimized apps previously.

And there's the rub, the only problem I have with Credit systems normalising as they do (using whatever method). It sadly removes one of few 'real' motivators to improve the stock codebase. There are other less immediate motivators, like efficiency & striving for perfection, though somehow it's hard to find those satisfying when you double the performance of an application and everyone's credit drops by half.

---

"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.

Its a bit like pay in this country....wages have been held down (unless you're a politician, NHS exec (with a 'swing door'), BBC exec (as per NHS exec) or (un)Civil Servant (as per the prior mentioned). So, people wonder if its worth working. I'll take whatever package they offer me, next month!!!

I get what you're saying Mark, but, here is the rub. Why, is what I was doing, a few months ago, of greater value than it is now? Kind of reminds me of when I was in the RAF!

I have a wonderfully stable PC, running ancient old XP Pro 32 - I've never even had to do a re-install, from the days when this PC was originally powered by an E6550 and a Radeon X1900XT. Absolutely reliable. Yet, slowly, I'm being pushed towards using 64 bit OSs, IF, I want to use my GPU (HD6870) to do 'useful work'. Thats where I am being 'pushed', by S@H and AMD. One wonders what percentage of PCs are running on XP 32. I don't need a 64 bit OS...who pays for that? Silly me; I do! Of course, I'll also spend all that time getting things working as they should..........

---

Don't take life too seriously, as you'll never come out of it alive!

Its a bit like pay in this country....wages have been held down (unless you're a politician, NHS exec (with a 'swing door'), BBC exec (as per NHS exec) or (un)Civil Servant (as per the prior mentioned). So, people wonder if its worth working. I'll take whatever package they offer me, next month!!!

I get what you're saying Mark, but, here is the rub. Why, is what I was doing, a few months ago, of greater value than it is now? Kind of reminds me of when I was in the RAF!

I have a wonderfully stable PC, running ancient old XP Pro 32 - I've never even had to do a re-install, from the days when this PC was originally powered by an E6550 and a Radeon X1900XT. Absolutely reliable. Yet, slowly, I'm being pushed towards using 64 bit OSs, IF, I want to use my GPU (HD6870) to do 'useful work'. Thats where I am being 'pushed', by S@H and AMD. One wonders what percentage of PCs are running on XP 32. I don't need a 64 bit OS...who pays for that? Silly me; I do! Of course, I'll also spend all that time getting things working as they should..........

It depends on what you consider 'of value'.
My work is worth as much scientific value as it ever was, perhaps with v7 even more.
If the credits do not perhaps reflect that, I know why, I understand why, and it does not bother me.

---

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

Most are doing more work, since the stock apps are now the optimized apps previously.

And there's the rub, the only problem I have with Credit systems normalising as they do (using whatever method). It sadly removes one of few 'real' motivators to improve the stock codebase. There are other less immediate motivators, like efficiency & striving for perfection, though somehow it's hard to find those satisfying when you double the performance of an application and everyone's credit drops by half.

Well, my friend. You are more involved in this than most, as I believe you contributed much of the code that is now Seti stock (previously opti).
You should be very proud of that!!

I know as time allows, you have many more things up your sleeve. The kitties wait with baited breath. (Maybe that's tuna breath).

---

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

Amen, to that. If I was putting in the effort that guys like Jason (and others) have, I'd wonder what the point was......then get the VB out of the fridge!

Cheers, Jason and the KWSN guys.

---

Don't take life too seriously, as you'll never come out of it alive!

The real problem here is that other projects are not being forced to play by the same rules as Seti does. And are allowed to award what they wish. THAT I do hold Dr. Anderson somewhat accountable for, as he could force them to come in line. I don't know why he does not, other than like myself, he is not too concerned with what other projects award compared to Seti.

Quite simple answer really: BOINC (client and back-end) is open source. There is nothing to force. Anyone can make any chances to any part of the software as they see fit. Anyone can update any single part of the back-end, anything that they see fit, they're not forced to update all parts (which is good, as that can break whole projects as we have seen in the past).

---

Most are doing more work, since the stock apps are now the optimized apps previously.

And there's the rub, the only problem I have with Credit systems normalising as they do (using whatever method). It sadly removes one of few 'real' motivators to improve the stock codebase. There are other less immediate motivators, like efficiency & striving for perfection, though somehow it's hard to find those satisfying when you double the performance of an application and everyone's credit drops by half.

+1
CreditNew is evil. Said it many times already and repeat in this thread too. What should motivate de-motivates in reality!

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.