Observation of CreditNew Impact (4)

As many are aware, the change form Enhanced (I’ll call these v6 work units) to v7 work units around 1 June caused daily totals to fall and many volunteers to complain (this should be of no surprise to anyone). It is fair to say that there has been some attempt to fix the issue, however I feel that it is also fair to say that this has been less than satisfactory to date, possible even halfhearted at best.

Since just before the migration to v7, I have been keeping a track of my daily totals. I have numbers for every day except the period when I was overseas.

The daily totals are contained below.

In continuing to look at the issue of daily totals, I have adopted a certain profile of behaviour. When AP becomes available, I set preferences to AP only and over the period of the day I aborted all v7 WUs across all machines to minimise the time it takes to fill their caches with AP WUs. I have made no secret of doing this and you can find my comments to this end in other threads in this forum. When AP is no longer available, I reset preferences to include v7 WUs and let all machines run dry of AP at their own pace (The AP GPU WUs run out first on the i7 (within 24 hours), followed by the Quads the following day. The AP CPU WUs usually run out over circa 2 days on the i7, followed by 1-2 weeks for the Quads).

I do this to ramp up the daily total fairly quickly to see where the AP daily total is compared to that of v7 as the ability to “obtain” over time AP WUs is limited compared to v7 WUs. They are not there for as long, coupled with periods of unavailability (nothing new here).

Wiggo, I am aware of your thread “Now when is a fair go going to far?” and do note that 3 of the machines you point out are mine. There is also a particular comment in there from Jason Gee “In a nutshell, from the credit aspect they're really wasting their time & effort”, that I will make comment on later. In no way is the following a go at either you or Jason.

I have made comment on credits in the past and those comments are also contained after the daily totals.

In relation to the data, you will note that after switching to AP or v7, it takes about a day or two for the numbers to head towards their steady state position. This is due to the lag effect in credits being granted. The other complicating factor is the rapid transition to AP, no AP, AP, no AP, etc. When you have AP for a day or two and then no AP for a day or two it tends to mask the overall effects.

Of note is the more recent data. If you look at the numbers around 6, 7, 8 November, and 10, 11, 12 November, you will see daily totals trending to around 210,000 per day for AP.

In looking at 13 November onwards, you can see daily totals falling away. The totals on 13 and 14 November are an amalgam of AP and v7 credits. The totals from 15 November onwards are primarily due to v7. You can see that these daily totals seem to sit around 145,000 per day.

In short, v7 WUs generate circa 69% of the credit that AP WUs generate per day. Jason, this is why your comment in the other thread is not right.

What the data quite clearly shows is that despite any 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.

It also shows that the initial claim that the disparity would disappear after a few months (due settling) was wrong.

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.

I have sent this data before to Dr Anderson (and will do so again), and for the lead scientist to ignore facts and stick to an emotional viewpoint I would have thought was akin to demonstrating scientific heresy/complete lack of judgement. Given that v7 was launched 5 ½ months ago, the issue should have been fixed by now and I am surprised at the high level of inertia being exhibited by Dr Anderson in trying to ignore this issue and hope that it just goes away.

Lastly I would like to offer the following comment on credit.

Whilst there has been discussion between the volunteers on credit vs science, and some volunteers are focusing just on credit, the issue is not about credit as such. It’s about recognition.

There are many distributed computing projects to which people contribute resources. The manner and means in which those projects recognise individual contribution is through a system that is based on and allocates credits. Some projects choose to recognise a person’s contribution more than other projects, thus they grant a higher credit rate per contribution for that project. In short, credits are effectively an indication of a person’s contribution to a project.

In the case of "the New Credit System" implementation of version 7 work units by Berkeley, recognition of personal contribution has been significantly reduced compared to v6 or compared to AP. At present, the indication is that recognition for effort is notionally just over half that of what it was prior to the new version of seti work units being employed.

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
2013.09.16 – 171,660
2013.09.17 – 175,775
2013.09.18 – 136,418

Overseas – No data for intervening period

2013.10.31
2013.11.01 – 148,770
Local Time 10:06 – 1 November 2013 (AP WUs available, ceased download of v7 WUs de-selected in seti@home preferences, aborted all v7 WUs)
2013.11.02 – 170,841
Local Time 10:36 – 2 November 2013 (Issue with no work being available, no AP, nor v7, have switched on v7 to keep machines going).
Local Time 20:30 – 2 November 2013 (Changed preferences to AP only, residual v7 wus being processed).
2013.11.03 – 169,195
Local Time 15:59 – 3 November (AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home)
2013.11.04 – 157,975
2013.11.05 – 159,643
Local Time 10:43 – 5 November 2013 (AP WUs available, ceased download of v7 WUs de-selected in seti@home preferences)
2013.11.06 – 148,878
2013.11.07 – 212,663
2013.11.08 – 200,528
Local Time 14:28 – 8 November (AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home)
2013.11.09 – 177,440
Local Time 09:09 – 9 November 2013 (AP WUs available, ceased download of v7 WUs de-selected in seti@home preferences)
2013.11.10 – 189,139
2013.11.11 – 211,072
2013.11.12 – 213,016
Local Time 08:54 – 12 November (AP work units no longer available. Residual AP work units in queues within computers. V7 work units enabled in seti@home)
2013.11.13 – 188,319
2013.11.14 – 182,094
2013.11.15 – 153,326
2013.11.16 – 145,623
2013.11.17 – 143,540
2013.11.18 – 142,664
2013.11.19 – 130,840
2013.11.20
2013.11.21


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

Enclosed below are comments that I have previously posted, along with data and additional comments surrounding that data.

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.

---

I have also sent a complete copy of the above to Dr Anderson and Eric Korpela.

cheers

---

It's good to see that you havn't aborted any MB V7, yet, with this latest batch of AP's Lionel. ;-)

But I will tell you that a lot of us do look down at people who are doing that, and the other way as well.

Also AP's are not paying what they use to so the difference in credit is actually closing, most likely a reaction to the "other way" that I can see.

Cheers.

Lionel, You have done your homework. As for my own machines I do see the RAC drop when there is no AP work.
So I would say that you have made a case that credit new is out of kilter.
And that no amount of tweaking will close the gap. And it has been long enough for things to settle down.

Now the ball is in Dr. A's court. There is the brick wall. Unless another Admin can convice him, I doubt anything will change.

Now that being said, I would ask other users to remember that if they grab all the AP work units its less for all of us to crunch.

And as I stated in another thread, There was a time when most users didnt want AP work.

Good luck on those windmills Don Quixote:)

---

[/quote]

Old James

Now that being said, I would ask other users to remember that if they grab all the AP work units its less for all of us to crunch.

+1

---

In short, v7 WUs generate circa 69% of the credit that AP WUs generate per day. Jason, this is why your comment in the other thread is not right.

Apples and oranges:)

I think your misunderstanding lies in that you took Jason's comment to be v7 exclusive. The way I understand it, it applies to v6 too (though maybe with different percentages for v6 MB but that's irrelevant here). In other words it has nothing to do with your quest of why credit was halved going from v6 to v7. Rather it's a new discovery of a problem that dates back to 2009 (?) and not this summer.

I think where you got confused is that he indirectly answers your question of why MB vs. AP is showing a discrepancy in credit (answer: because they are calculated separately). But Jason's numbers have nothing to do with any numbers you are witnessing "today".

So I guess what he was trying to say was that the numbers aren't as bad as you think they are. They're worse. So bad, in fact, that any attempt to micromanage your crunching is futile (philosophically speaking).

On a side note, I think a lot of people here are underestimating precisely how intelligent CreditNew really is. Any attempts to tweak credit-granting (the ones you are calling "less than satisfactory" or maybe even "half-hearted"; I disagree) have been slapped down by CN. This can only mean they were anticipated (a priori) by design. A fact which I find fascinating, unexpected and very, very clever.

Your data is very hit-and-miss, your figures will always contain a mix of AP and MB workunits as credit is not granted until your wingman finishes the job. Even if you finish a bunch of AP units in a day or so, the credit for those units will come in over the next few weeks, and MB units will always contaminate your figures.

As I mentioned before, I have kept figures for credits granted vs the run and cpu times per workunit, allowing the calculation of cpu-seconds per credit, which is a much more convincing parameter (in my opinion) to estimate the "value" of each credit.

I continue to collect the stats by hand from the epemeral completed workunit sheets (they vanish after 1 day, and I know of no other way to find out the credit granted per workunit). As I have a slow old laptop and no GPU the turnover of results is slow enough that I can keep up. I discard any results that are faulty e.g. results overflow.

As I said the last time I posted a graph, it is clear to see that the V7 app requires significantly more cpu-seconds per credit than the V6, and I have split the graph to show them separately. In addition, we are now about six months into the use of V7, so sufficient results are in to show if the situation has stabilised.

As you can see from the graph below, in my case, the V7 workunits are granting roughly one credit per 350 cpu-seconds, wheras the V6 workunits delivered one credit per 230 cpu-seconds. What's more, the figures have stabilised at this rate, and were initially further apart.

It's also interesting to see that shorties now pay better than standard units, where before they paid worse.




There is no doubt that the V7 optimised cpu app delivers less credit per cpu-second than V6. However I recall an answer to the previous thread saying that the V7 optimised app has less advantage over the standard app than the V6 one did, so it is possible that the standard V7 app is giving credits at the same rate as the V6 one, and the drop in value that we see is due to the optimised app being less advantageous now. I'm not sure that there is a lot we can do about that. I'd love to see cpu-seconds-per-credit comparisons for the standard apps, if anyone has them.

---

so it is possible that the standard V7 app is giving credits at the same rate as the V6 one, and the drop in value that we see is due to the optimised app being less advantageous now.

What is strange is not optimised app being less advantageous, which is totally trivial and beneficial to the whole project, but the fact that instead of RAC increasing for people using also just stock application and that of optimised being stable or enjoying a smaller benefit, what was actually experienced is a general decrease in RAC (also for stock if I am not wrong, which I would expect to increase their RAC).

One explanation which has been given, and it is not to be neglected, is that also optimised apps are not that optimised yet due to the new correlation task and we may all have been hit by this. We all have been used in V6 to use fully optimised applications and we are now using apps which have parts that still need work to get a better performance and there may be room for that.
Therefore, respect to times before V7, we are "wasting" a bit more of our computation resources and therefore we are granted less credit/second.

This maybe not the whole explanation (and for sure it is not), but it maybe a part of what we are experiencing.

Sleepy

so it is possible that the standard V7 app is giving credits at the same rate as the V6 one, and the drop in value that we see is due to the optimised app being less advantageous now.

What is strange is not optimised app being less advantageous, which is totally trivial and beneficial to the whole project, but the fact that instead of RAC increasing for people using also just stock application and that of optimised being stable or enjoying a smaller benefit, what was actually experienced is a general decrease in RAC (also for stock if I am not wrong, which I would expect to increase their RAC).

It would be very interesting if any of the posters complaining of reduced RAC were running stock apps: - Anybody here for whom that applies?

If they have seen a reduction from V6 stock to V7 stock then you're right.

As I understand it, one of the side-effects of Credit New is that the stock app is used as the benchmark, so when the stock app is updated, everyones credit calculations are affected. As long as the effect on those using the stock app is to keep their rewards at the same rate, then this is understandable.

---

At the changeover from S@H v6.x to V7.x I was bedding in a new cruncher by running stock apps on that cruncher. I noticed a drop in credits awarded per task of similar angle, along with an increase in task duration for those tasks.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

It would be very interesting if any of the posters complaining of reduced RAC were running stock apps: - Anybody here for whom that applies?

Yeah, I ran stock V6 for a little over a year... and then optimized V6 and now stock V7. My numbers (RAC) when crunching 24/7 were:

stock v7: 1000
stock v6: 1500
opti V6: 2000

Here's a picture of my opti V6 changeover to strictly V7 stock:



But Alan, I don't think the answer to your question is that simple. My laptop has a GPU while yours does not. For a CPU only machine, I'm guessing the transition from stock V6 to stock V7 would actually show a slight increase in RAC! This can easily be seen by your own APR numbers from your host:
http://setiathome.berkeley.edu/host_app_versions.php?hostid=6100462

To complicate things even further the stock V6 GPU app was slightly faster than the optimized V7 GPU app. In an ironic reversal of roles & goals the stock app was optimized for speed while the anonymous app was optimized for better science. I guess this makes sense considering Nvidia made the stock app while Seti gurus & project-lovers made the opti app:)

However the optimized V6 CPU app was nearly twice as fast as the stock CPU app. Which is why I still have the nagging feeling that the servers were actually using the opti V6 CPU app as a benchmark rather than the stock V6 CPU app.

Just a notification, reflecting that mentioned already in the 'fair go' thread. As of about 1-2weeks ago, There are at least two people on the planet, one of them myself, that understands creditNew, how it works and how it doesn't against the documentation supplied, better than the author does. Short term bandaid fixes are feasible, and more permanent corrections to the mechanism are in design.

Ask me any questions on symptoms/observations you like. I will do my best to respond at your required tech level.

---

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

OK, I'll start with this:

However the optimized V6 CPU app was nearly twice as fast as the stock CPU app. Which is why I still have the nagging feeling that the servers were actually using the opti V6 CPU app as a benchmark rather than the stock V6 CPU app.

Actually the 'cobblestone scale' is fixed, but under creditNew your host claims by elapsed time and 'boinc whetstone'. That bench is a fraction of, for example, sisoft Sandra single threaded SSE whetstone. Being a dominantly vectorised SSE+ application against an FPU it underclaims by a factor of around 3.3 times. That's scaled down further by recent AVX enabled host claims, noticing the two distinct steps at stock app upgrade.

Compare the ratio of a sisoft single threaded SSE whetstone bench [withcare], against boinc's whetstone. it should be about 3.3x.

---

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

Ask me any questions on symptoms/observations you like. I will do my best to respond at your required tech level.

Jackpot! Q&A with a Seti guru:) Thank you Jason.

I see you quoted my pet theory but until I re-read the CN page and put pen to paper I can't really form a proper question to ask. So here's a couple of other questions:

a) This whetstone discovery of yours applies to V6 too right? Does it go all the way back to Eric's flop-counter? Before the days of CreditNew?

b) And probably the hardest and most obvious question to ask: Why did credit drop? I've read replies from you, Claggy, Joe, Eric, and others but I still can't get my head 'round it.

a) This whetstone discovery of yours applies to V6 too right? Does it go all the way back to Eric's flop-counter? Before the days of CreditNew?

flop counter was 'fine' in practical and technical aspects. CreditNew covers two transitions yes, its introduction during V6, and stock CPU AVX with v7.

CreditNew woud be 'fine' too, if it wasn't for some unfortunate engineering issues.

b) And probably the hardest and most obvious question to ask: Why did credit drop? I've read replies from you, Claggy, Joe, Eric, and others but I still can't get my head 'round it.

'Boinc whetstone' versus app technology. The CN Author didn't understand that instruction level parallelism does more operations in the same time, by an average factor of, you guessed it, 3.3.

First and foremost, Whetstone benchmark was designed as a 'worst case' to defeat compiler and hardware optimisations. In creditNew it's treated as a raw peak claim, which is obviously a bad approach to start with, since no practical software works against the processor but with it.

Secondly, there are instabilities to do with how these claims are scaled, namely by 'undamped weighted averages'. The quality of this mechanism is nearly the same as comparing a cheap 5 dollar CD player to a high end pro radio station one. Put more technically it uses a fudged sampled average [sigma] instead of a stable continuous control loop [engineering concepts[.

---

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

It needs to be remembered that this isn't simply a SETI concern. Other projects issue credits too, and draw conclusions from them:

Crossed the 1 PFLOP barrier now

OK so while it's unfortunate that 'Boinc whetstone' is out of whack it has little to do (maybe AVX portions?) with the drop in credit, correct?
(Please understand I realize how important this discovery of yours is, I'm just asking if it has any relevancy to the credit drop)

So let's focus on 'undamped weighted averages'. I'm guessing that 'stable continuous control loops' were somehow vulnerable to some kind of cheating and therefor replaced by 'fudged sampled averages'?:)

Next question will be 'what exactly are undamped weighted averages?' but I'll need to brush up on the CN wiki to ask it well. So maybe tomorrow if u are still in a question-answering mood:)

It needs to be remembered that this isn't simply a SETI concern. Other projects issue credits too, and draw conclusions from them:

Crossed the 1 PFLOP barrier now

If they have SSE+ apps, and are measuring it with some Boinc server figure, they are likely doing 2-3x , or even more than that.

Understand we're talking umber of operations, not credits or estimated flops etc. CreditNew claims are an underclaim.

---

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

It needs to be remembered that this isn't simply a SETI concern. Other projects issue credits too, and draw conclusions from them:

Crossed the 1 PFLOP barrier now

If they have SSE+ apps, and are measuring it with some Boinc server figure, they are likely doing 2-3x , or even more than that.

Understand we're talking umber of operations, not credits or estimated flops etc. CreditNew claims are an underclaim.

That particular project is still allocating fixed, flat-rate credits, and - because of the deterministic runtime of their workunits - getting away with it. But, as the discussion arising from the thread title implication hints, possibly drawing scientifically-invalid conclusions from them.

They are anxious to move to CreditNew once they trust it, and they have a robust and well-managed Beta project which could be used as a testbed.

OK so while it's unfortunate that 'Boinc whetstone' is out of whack it has little to do (maybe AVX portions?) with the drop in credit, correct?
(Please understand I realize how important this discovery of yours is, I'm just asking if it has any relevancy to the credit drop)

So let's focus on 'undamped weighted averages'. I'm guessing that 'stable continuous control loops' were somehow vulnerable to some kind of cheating and therefor replaced by 'fudged sampled averages'?:)

Next question will be 'what exactly are undamped weighted averages?' but I'll need to brush up on the CN wiki to ask it well. So maybe tomorrow if u are still in a question-answering mood:)

I'll always answer this stuff, because engineering and science, and how they refuse to talk, fascinates me, even if from one of the best schools like Berkeley.

OK

The mathematical definition of chaos is:
1]sensitivity to initial conditions
[Check, credit starts around some value determined by a scaled estimate then goes awol]

2] topological mixing
[check, validation time domain is not the same as processing order ]


3] Density of periodic orbits
[check, credit arbitrarily approaches some expected value but never spot on]


A bit rough to quote from chaos theory for a supposedly deterministic system, but if the shoe fits I guess.

hint: look for self similar patterns of credit award at that same angle range, e.g. shorties. some go up, some go down, never quite the same, not random, because the patterns look similar, maybe even inverted.

[Edit:] Adding

So let's focus on 'undamped weighted averages'. I'm guessing that 'stable continuous control loops' were somehow vulnerable to some kind of cheating and therefor replaced by 'fudged sampled averages'?:)

There was never any stable continuous control loop in either the Boinc client for time estimates, nor in CreditNew. Such a mechanism would be relatively immune to cheating and somewhat simpler than the current implementation. 200 year old [control theory] technology that works is generally frowned upon in modern academia though, as it doesn't attract funding.

---

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