Am I the only single core Intel P4 on the project?

My scores have not been wobely, but have dropped consistenly for two weeks and continuing.

I've had to actually lower my target CPU time and Connect To Server settings to hold my own. Maybe my RAC will get back to 200. It used to run 225+ easily.

For posterity, because results don't stay around long on the servers ...here's Keith's results from his two hosts at present:


Host 253124
70677147 63275152 Over Success Done 28,683.33 60.33 59.92
70612598 63215711 Over Success Done 27,890.09 58.66 69.70
70555110 63161895 Over Success Done 28,081.42 59.06 66.34
70496639 63108413 Over Success Done 27,506.05 57.85 51.42
70433368 63049940 Over Success Done 28,532.02 60.01 66.88
70373136 62994522 Over Success Done 27,073.64 56.94 53.80
70297508 62924348 Over Success Done 28,791.86 60.84 63.87
70239194 62870053 Over Success Done 28,892.86 61.05 53.72
70185975 62822254 Over Success Done 29,147.11 61.59 73.25
70184878 62821337 Over Success Done 29,265.52 61.84 88.28
70156156 62798670 Over Client error Downloading 0.00 0.00 ---
70103874 62751687 Over Success Done 27,653.56 58.43 80.30
70043584 62695550 Over Success Done 28,693.95 60.63 64.41

Host 459186

71393048 63939096 Over Success Done 6,955.09 14.49 18.97
71362940 63911096 Over Success Done 13,938.75 29.04 44.69
71304353 63856592 Over Success Done 13,956.67 29.07 37.28
71244518 63800887 Over Success Done 13,931.30 29.02 33.13
71183197 63743966 Over Success Done 12,960.92 27.00 30.74
71127645 63692296 Over Success Done 13,700.47 28.54 46.61
71054124 63624152 Over Success Done 28,383.45 59.13 71.89
70989507 63564080 Over Success Done 27,691.33 57.69 68.42
70989421 63563994 Over Success Done 28,423.25 59.21 64.73
70989332 63563905 Over Success Done 29,848.17 62.18 66.98
70989331 63563904 Over Success Done 29,323.77 61.09 52.94


Keith, reducing your runtime preference and connecting to the server more frequently to report complete work is a lot like pushing income to January 2nd and pulling expenses to December 29. It doesn't actually change the amounts of your income nor expenses, it just looks that way on paper, but will eventually catch up to you if you aren't able to do the same thing next year.

I wanted to post your results list here to help give a specific reference going forward to define what you feel the problem with granted credit is. A large percentage of your work is granted more credit then you are claiming for it.

---

Rosetta Moderator: Mod.Sense

When I tested the granted credit ratio on AMD 64 cpus, P4s, and the Intel Core cpus - I remember the P4s as overclaiming, while the AMD 64s and Intel Core and Core2 cpus underclaiming. Changing the cpu mix will change the average ratio of the granted credit to the claimed credit on your machine.

As mentioned before, recent changes started giving the "waiting for memory" message. If you're running 24/7, you should be getting close to 86400 seconds * 7 per week per core. (604,800 seconds per week per core). If you're getting less seconds of work done per week than normal, then it's time to track down why you're losing more time than usual.

---

Thinks Keith has a good point!!
And to think that all I wanted to know was - why my claimed/granted credit was so variable!!
As long as it is not due to my PC misbehaving, am not all that worried, just curious. Apologies for [re] opening such a can of worms.

---

That's alright Michael. Don't feel bad bringing up honest concerns. I'm going to let it ride for a while. David Kim is trying to optimize the sidechain problem and make the WU's more efficient (According to his post).

The AMD users appear to be taking the biggest hit and I hope that they stay for a while.

I have a number of AMD machines running Linux and crunching 24/7 with a 10 hour crunch time. Looking at the "host average" chart in BOINC manager, all but one that I checked had a very steady RAC. I don't see any sign of the alledged drop for AMD machines. Even the Duron with its tiny cache has a steady RAC. The one machine that varied has a 1MB cache. It increased its RAC by 10% a few weeks ago, but has now given back half of that. As that's only one machine it could just be a statistical fluke, though.

So whatever is happening has nothing to do with AMD vs Intel.

WOW!! I just had a WU that was claimed at 70 something credits but the granted was 117 credits!! The next one settled back down to 3 points over the claimed total. The 117 is the highest I have ever had.

---

hmm I realised the same, somehow the drop seems related to 5.59 :/

Before 5.59 my machine came to such results:

31.68 41.64
30.16 36.62

I also had results with less granted then claimed, but overall it was even.

Now, im only getting negative ratio like

37.73 25.57
93.12 76.75
19.51 14.74

I changed CPU target time, but i keep getting these shitty ratios, not matter what :S

Now I see, someone with an AMD 64 2800+ is getting steady positive ratios, and I wonder, what is wrong over here :/ Cant draw a connection to CPU power here

Yeah, Ive got a lesser cpu than you, but I can't see how I get better credit.
Are you getting similar work units to me?
I am running fold and dock and relax at the moment, followed by smooth increase cycles wu's.

For the moment after the 117 jump i am:
75.87 78.54 and 75.82 79.74.

But even before this I had some WU's that dropped me and a few others just before 5.59 that raised me in granted credits.

So it must be something to do with the WU's and how they work with our cpu's or memory or something.

hmm I realised the same, somehow the drop seems related to 5.59 :/

Before 5.59 my machine came to such results:

31.68 41.64
30.16 36.62

I also had results with less granted then claimed, but overall it was even.

Now, im only getting negative ratio like

37.73 25.57
93.12 76.75
19.51 14.74

I changed CPU target time, but i keep getting these shitty ratios, not matter what :S

Now I see, someone with an AMD 64 2800+ is getting steady positive ratios, and I wonder, what is wrong over here :/ Cant draw a connection to CPU power here

---

greg_be, According to David Kim's post, I think that the team is leaning in that direction. They're running many more UW types than usual. Coupled with the side-chain linking which can take up to three minutes on the Fold-Dock units and the units probably don't work as efficiently as before. Some machines are noticing this more than others.

Yes, probably right. Im running also a lot of SYMM FOLD AND DOCK RELAX WU´s (nearly only, I would have to check the log , but i think 9 out of 10 were those the last days) - The only thing I can imagine is, that my short memory is causing this credit drop. Im only running 2x256 MB on this machine, and cuz my PCIE card burned on me last week in my other machine, i cant compare atm, if results are affected on my AMD 64 aswell. So maybe the new FOLD & DOCK wu´s need segnificant more RAM then other workunits ?

The most memory used by rosetta on my "Task Manager", on the docking units, was about 120MB. I don't think that you would be hitting the celing on ram.

Oh, I just remembered something. When the new credit system was tested on RALPH last year, someone commented that P4's would do much better on scores. P4's got seriously short changed on the benchmark system. I don't know how claimed credit is calculated, but the claimed credits looked about the same under the new system. So it would be reasonable that P4's would be granted about 20% or higher average granted credits under the new system.

I finally see my system getting back above 200 RAC now. Maybe, for me, these inefficiencies get worse the longer a WU runs. 4 hour "Target CPU Time" seems to be working.

... So maybe the new FOLD & DOCK wu´s need segnificant more RAM then other workunits ?

Some may, but the project has two classes of tasks. For tasks that they know will require more then the typical 110MB or so, they flag only to run on machines that have more then ~480MB of memory.

Keep in mind, "memory" is accessed via the processor's L2 cache. If you have a larger L2 cache, then you frequently save yourself a trip out to memory. Just one way that one machine's performance differs from another. The BOINC benchmarks do not require memory access, and so do not reflect memory access speed, nor do they incorporate any adjustment for large vs small L2 cache. But a large L2 cache is going to run more efficiently and get more models completed per unit time, because it saves many trips out to memory.

Runtime preference really doesn't impact actual credit. In the short term it may impact your RAC, but this is because RAC is based on snapshots in time, not because you are doing more or less work.

---

Rosetta Moderator: Mod.Sense

The L2 cache thing would sound resonable, but my Barton has 512 k, like most AMD 64 system also have... I mean, you could explain a difference to Intel system there, or T-bred AMD XPs. I only see a difference in the Memory bandwith, which would explain why AMD 64 systems crunch better then me - given that they are using dual channel, else they have no real speed advantage there aswell (Dual Channel on S. 462 is just not that good)

My brother, running rosetta on an AMD 64 4000+ is not effected tho

https://boinc.bakerlab.org/rosetta/results.php?hostid=441503

I dont know, maybe i was just "unlucky" the last days, just seemd to be odd to me,thats when i read here, im not the only one having this feeling.

Thx for the explanation about the CPU target time, i was reading through FAQs yesterday, when toying around with the settings, to find out if this somehow suits my system better^^

Some may, but the project has two classes of tasks. For tasks that they know will require more then the typical 110MB or so, they flag only to run on machines that have more then ~480MB of memory.

So we would get different WU's if we had more memory? But then I suppose our CPU's would not work as efficiently on these big WU's since our L2 cache is not as large as the newer processors. This would in theory cause us to lose credit since our machines would have to make more trips to the memory since the L2 is less. Thats at least one odd thought I have on this if my train of thought is correct.

---

I just received a clarification from David Kim on his comments below.

Basically, he is aware that some of the recent tasks sent out have a more highly variable runtime then we've grown accustomed to. And so some of the improvements he is working on will help any platform make a quicker determination on whether the current direction of the model is worth pursuing. Thus calling an earlier end to what are presently some areas that are taking more time for some models and less time for others. This improvement in the science of knowing which are worth pursing and which are not will also result in a more consistent runtime from one model to the next.

In other words, a lot of what we've been observing and discussing here may be more a result of hitting a couple of those longer detours, and less based on any specific CPU or system configuration.

Early on when results are coming in on a specific type of task, if several users hit those long detours, it will make the average credit per model higher then it would otherwise be. Then other users report in with tasks that did not go down such detours, or found their way out of them quickly, and they get a larger credit award (as based on the previously reported results), even though they just ran their normal runtime.

So the science improvements he is working on, are not intended to be specific to any given platform or processor. Instead, they will simply make the models of a given task have a more consistent amount of calculations required to complete them. There will always be variability, but these coming improvements should reduce it, specifically for the tasks with "jumping" in their name.

---

Rosetta Moderator: Mod.Sense

I would like to obtain some infos about these three WUs:

1i9x__BOINC_INCREASECYCLES10_NOCHAINBREAK_RNA_ABINITIO-1i9x_-_1661_146_0 (#71969554)
Result: DONE :: 1 starting structures built 30 (nstruct) times This process generated 21 decoys from 21 attempts
Credits: 35.51

1fkaA_BOINC_HALFWATSONCRICK_RNA_ABINITIO-1fkaA-chunk027__1660_47_0 (#71909871)
Result: DONE :: 1 starting structures built 30 (nstruct) times This process generated 93 decoys from 93 attempts
Credits: 28.74

2a43__BOINC_SMOOTH_INCREASE_CYCLES10_RNA_ABINITIO-2a43_-_1644_5236_0 (#71356910)
Result: DONE :: 1 starting structures built 30 (nstruct) times This process generated 378 decoys from 378 attempts
Credits: 34.23

Every WUs has been worked out with a Target CPU run time of 8 hours and correctly completed in about 28800 seconds. Every WUs has been crunched by an AMD Athlon(tm) XP 2400+ that usually scores 65-70 credits for the same 8 hours.

I think that about 30 credits for 8 hours of work is quite a low score. Why do this three WUs scored so low? Maybe that type of WUs was too difficult for my PC? The last result generated 378 decoys... Were they worthed ONLY 34 credits?

Every reply is well accepted... thanks in advance for your patience!
Luca B. from Italy

---

hm...

2 WUs, both done with an AMD 2800+, time quite the same and credits highly deffering:

CPU Time Claimed Granted
WU 1 3,174.30 9.74 8.94
WU 2 3,330.89 10.22 4.52

Text in Result from WU1:
This process generated 2 decoys from 2 attempts

Text in Result from WU2:
This process generated 1 decoys from 1 attempts

So, we don't get credits for the time we crunch but for the decoys?

Regards,
Maion

---

So, we don't get credits for the time we crunch but for the decoys?

right! That was introduced with the new credit system to avoid cheaters.

---

So, we don't get credits for the time we crunch but for the decoys?

right! That was introduced with the new credit system to avoid cheaters.

So its luck if you get 4,5 odr 9 credits?
Well, that reduces the fun of races a lot...
Aren't there other possibilities to avoid cheaters?

---