Lionel 的帖子

141) 留言板 : Number crunching : Show and tell your machine. Here's mine. (消息 1471008)
发表于：31 Jan 2014 作者： Lionel
Post:
... as I've never seen cabled off-board PCIe ...


this from ebay http://www.ebay.com/itm/PCI-express-1x-to-16x-16x-1x-mining-Extender-Riser-Card-Power-USB3-0-cable-/271378879332

cheers
142) 留言板 : Number crunching : CPU vs. GPU (消息 1466817)
发表于：20 Jan 2014 作者： Lionel
Post:
Qax

I feel some of the commentary above may have missed the point regarding your first post at the top of this thread.

If you wish to increase your credits for seti (as you implied above), process seti on GPU only. Look at processing MB and AP WUs. MB WUs give around 60%-70% of the recognition that AP WUs give, so best to process AP WUs above MB WUs. Availability of AP WUs is periodic in that there are periods where they are available and periods when they are not available. Also, due to the fact that AP recognition is higher, they are in greater demand when available.

Processing seti MB on CPU is not worth the effort due to the low level of recognition received. You are better off assigning a project to the CPU that does not have a GPU application enabled (as you thought above).

cheers
143) 留言板 : Number crunching : Maxwell Cometh ... (消息 1465575)
发表于：17 Jan 2014 作者： Lionel
Post:
This article may be of interest to anyone thinking of purchasing a new Nvidia GPU in the near future.

http://www.techpowerup.com/196956/nvidia-readies-geforce-gtx-750-ti-based-on-maxwell.html

cheers
144) 留言板 : Number crunching : Observation of CreditNew Impact (4) (消息 1443981)
发表于：19 Nov 2013 作者： Lionel
Post:

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

cheers
145) 留言板 : Number crunching : Observation of CreditNew Impact (4) (消息 1443973)
发表于：19 Nov 2013 作者： Lionel
Post:
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.
146) 留言板 : Number crunching : Motherboard help (消息 1443590)
发表于：18 Nov 2013 作者： Lionel
Post:
Suggest:

Case - look at NZXT Switch 810, plenty of internal volume and easy to work in (can also fit water cooling inside if desired).

M/B - try looking at Asus Rampage IV Extreme (will take 4 GPUs).

You can put 4 GPUs on the M/B but air cooling will not work. There is insufficient gap between the GPUs and they get too hot and stop working fairly quickly (I have tried it just to see how long it would take).

cheers
147) 留言板 : Number crunching : Haswell Temps??? (消息 1442570)
发表于：15 Nov 2013 作者： Lionel
Post:
http://www.bit-tech.net/news/hardware/2013/06/06/haswell-heat/

http://www.extremetech.com/computing/157337-the-haswell-paradox-the-best-cpu-in-the-world-unless-youre-a-pc-enthusiast

Suggest you have a look at these. There are more articles around if you search.

cheers

148) 留言板 : Number crunching : Observation of CreditNew Impact (3) (消息 1416201)
发表于：16 Sep 2013 作者： Lionel
Post:
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.


Wiggo, I don't believe that I am noticing a drop in average credit awarded for an AP work unit. The credits bounce around quite a bit and in looking at my list of valids, they appear to be similar to before. If we could get a good run of APs for about 10 days straight we should be able to see if there is an indicator towards a change but with the oscillation occurring quite frequently it's a bit difficult to get a sense of it.

Lionel
149) 留言板 : Number crunching : Observation of CreditNew Impact (3) (消息 1416174)
发表于：15 Sep 2013 作者： Lionel
Post:
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.



What evidence do you need Richard? All you have to do is look at the numbers. They tell the story quite clearly.

By the way, just after posting the comment above, I also posted a comment in Eric's staff blogg under "What's new about SETI@home v7" to let him know that my comment was there.

Overall, what amazes me is the lack of scientific rigor that is being applied to determining what the root cause(s) is/are with the rating system and this behaviour is from the "lead" scientists of the project. Tweaking a knob isn't the solution.













150) 留言板 : SETI@home Staff Blog : What's new about SETI@home v7 (消息 1415924)
发表于：15 Sep 2013 作者： Lionel
Post:
Eric, you may want to look at "Observation of CreditNew Impact (3)" in the Number Crunching forum. There is still a problem with the credit system.

Lionel
151) 留言板 : Number crunching : Observation of CreditNew Impact (3) (消息 1415921)
发表于：15 Sep 2013 作者： Lionel
Post:
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
152) 留言板 : Number crunching : Less credit with Seti@home 7 ? (消息 1405283)
发表于：19 Aug 2013 作者： Lionel
Post:
Seneca

With the introduction of v7, credit dropped to circa 50% of that for v6. Since then they have played with a knob or two and tried to tweak the system, albeit without any success. The issue is that there is a fundamental design flaw with the system (most probably due to the introduction of auto correlation). As I have said to others before, I do not think tweaking is the answer. They need to look at the design (conceptual and logical) and determine the root cause of the issue (which should include fundamental analysis across identical work units run against v6 and v7). Once they understand the issue and behavioural differences, 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 more angst and frustration at both ends.

I almost get the impression that they don't know what they are doing, or whether they understand how they should go about solving the problem.

cheers
153) 留言板 : Number crunching : A new tape! (消息 1403363)
发表于：15 Aug 2013 作者： Lionel
Post:

It's not cheating as such, it's gaming the system. The system can be gamed at a superficial level due to the imbalance in credit rates caused by v7 and CreditNew and I'm not the only one playing the oscillation game. The issue can be easily fixed though, Dr Anderson just has to fix the credit system.

cheers mate

154) 留言板 : Number crunching : A new tape! (消息 1403313)
发表于：15 Aug 2013 作者： Lionel
Post:

AP is up again ... caches filling nicely (after dumping all v7 wus) ... they should be around for a day or two ... grab them while you can

:)
155) 留言板 : Number crunching : A new tape! (消息 1402871)
发表于：14 Aug 2013 作者： Lionel
Post:


APs.... almost as mythical and elusive as Bigfoot or Nessie herself.

LOL


Maybe more so ... :))
156) 留言板 : Number crunching : A new tape! (消息 1402797)
发表于：13 Aug 2013 作者： Lionel
Post:

AP now dry, so in about a day (which is how long it takes to do 100 AP GPU wus) it is back to MB until AP surfaces again...
157) 留言板 : Number crunching : A new tape! (消息 1402448)
发表于：13 Aug 2013 作者： Lionel
Post:

No corrections needed. You are basically correct. v7 wus give you about half the rate per hour that AP wus give. Where as v6 and AP wus were fairly well benched marked against each other (so it didn't matter what you ran), v7 gives you about 50% of the rate that AP does, so it it always better to run AP over v7. You only go back to v7 when there are no AP wus left...

cheers
158) 留言板 : Number crunching : A new tape! (消息 1402442)
发表于：13 Aug 2013 作者： Lionel
Post:
Yes, I noticed that AP was up as well. I have dumped all my v7 wus and am filling up on AP again ...

159) 留言板 : Number crunching : Observation of CreditNew Impact (2) (消息 1401608)
发表于：10 Aug 2013 作者： Lionel
Post:

My letter to the chancellor is in draft at the moment. I said that I would wait an appropriate period of time to see if Dr. A. was going to rectify the system (I have emailed him on this issue). If I do not see any real change in system behaviour after the next v7 swing, my letter will go.

cheers

I would be happy to hear an official acknowledgement that a problem exists. A statement indicating the time frame for corrective action would be a plus.

I think what's happening is that the powers that be are hoping that we wear ourselves out and the problem just goes away by ignoring it. This may be more political than technical. I've worked too long in Fortune 500 companies to not recognize this.


Seti@Home is just a part time gimmick for UCB. Dr.A runs the show and he runs BOINC. Their real jobs are for the space science lab. Do you really think the Chancelor could give a rats patootie about your RAC on creditnew?

Dr A. is the BMOC. I really doubt that angry letters from credit hounds will sway the chancelor to force DR.A. to change it.




James

You are entitled to your view as anyone else is to theirs.

cheers
160) 留言板 : Number crunching : SETI@home Enhanced v6 is now done, finito, kaputt. (消息 1401599)
发表于：10 Aug 2013 作者： Lionel
Post:

5,881








前 20 · 后面 20


 
©2020 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.