After the first unit crunched I needed only 17,5 hours thats half the time the S5R2 units but I only got a third of the credits, you have to ajust the credit value more than 5% its around 30 % the ajustment needed to get to the same value of last units.( 124000 seconds = 640 credits, now 62000seconds = 219 credits)
To be more accurate the data are 18.6 sec/ credit in S5R2 and 12.9 sec/ credit in S5R3a on a Mac Book Pro dual core, Darwin
I'm not sure what you did wrong, but those numbers are impossible. What you've listed are 193/279credit/hour = 4600/6700 credit/day.
The rates of the person you quoted are 193 and 283 sec/credit.
Sorry you are right, but still its a huge difference
Before it was 18.5 Credits / hour now its 12.9 credits per hour
On Host 579944, an AMD Opteron 285 running Linux FC3, I have noticed a gradual decline in the average amount of cobblestones/credit/points awarded each month.
[pre]MONTH CRUNCH TIME TYPE FIXED VALUE AVERAGE[/pre]
Not sure about the S5R1 dates as I mainly recorded the crunch times and fixed credit values. Have only recently started adding the WU type.
The average has slowly dropped from low 23's to low to mid 21's.
My average has now taken a dive from 21.47 to 12.36.
From the length of time taken to process I am not enthused by the credit value placed on my work.
A 42.43% drop in average credit.
The S5R3 average was only over 2 work units so I am interested in the others that I have to see if it is still worth the effort.
But we will see.
So while the gcc compiled code for Linux and Darwin seems to have been a bit faster than that for Windows in the previous run (S5R2), now in S5R3 gcc is losing ground.
Please keep posting your results, and for convenience please mention on which operating system the result was crunched.
The wingman I've been monitoring got a rash of 'signal 11' client errors last night (Linux/AMD). Probably a machine problem rather than an app problem, but someone with experience of reading the Linux output might like to take a look.
Both of my Macs that have S5R3 runs are showing spreads on credit per hour. Click the thumbnail if you want to see the graphs. I wanted to save bandwidth here and at imageshack with the thumbnail. One of the graphs is a histogram like chart that shows how many of each credit per hour value I've seen.
On Host 579944, an AMD Opteron 285 running Linux FC3, I have noticed a gradual decline in the average amount of cobblestones/credit/points awarded each month.
[pre]MONTH CRUNCH TIME TYPE FIXED VALUE AVERAGE[/pre]
Not sure about the S5R1 dates as I mainly recorded the crunch times and fixed credit values. Have only recently started adding the WU type.
The average has slowly dropped from low 23's to low to mid 21's.
My average has now taken a dive from 21.47 to 12.36.
From the length of time taken to process I am not enthused by the credit value placed on my work.
A 42.43% drop in average credit.
The S5R3 average was only over 2 work units so I am interested in the others that I have to see if it is still worth the effort.
But we will see.
Well have now processed 4 S5R3 Work Units and the cobblestones per hour are still woeful,
[pre]Work Unit Process Time Claimed Credit Credit/Hour
0518.05 S5R3 66,500.88 221.97 12.02
0518.05 S5R3 62,969.81 221.97 12.69
0518.05 S5R3 63,276.57 221.97 12.63
0518.05 S5R3 60,591.06 221.97 13.19[/pre]
This averages out at just 12.62 credits per hour
My last Sept S5R2 average was 21.47 cr/h (which has been getting lower for months)
Making this an 41.22% DROP in awarded credit.
Only one more to process then I might have to put this project on the backburner in the hope that things will improve.
It was the first project I joined so I would like to keep it going (I would like to get at least to 500,000 cobblestones).
As I noted before, my AMD 6000+ machine with Kubuntu 7.04 Linux has taken a significant performance hit with the switch to the 'R3 run. But, the story is quite different with the one Windows machine that's completed an 'R3 unit.
My AMD 3500+ machine, running WindowsXP, only takes a couple of hours longer to do an 'R3 than what it takes for the 6000+ machine. For the monster 656-cobblestone 'R2's, it would take about 43 hours for the 3500+ machine, vs. about 27 hours for the 6000+.
So, it seems that there's something strange about the 'R3 app that's having quite the impact with Linux machines.
As I noted before, my AMD 6000+ machine with Kubuntu 7.04 Linux has taken a significant performance hit with the switch to the 'R3 run. But, the story is quite different with the one Windows machine that's completed an 'R3 unit.
My AMD 3500+ machine, running WindowsXP, only takes a couple of hours longer to do an 'R3 than what it takes for the 6000+ machine. For the monster 656-cobblestone 'R2's, it would take about 43 hours for the 3500+ machine, vs. about 27 hours for the 6000+.
So, it seems that there's something strange about the 'R3 app that's having quite the impact with Linux machines.
Yes, that is definitely the case and has been reported by others as well. As always, it's not so much an issue with the OS itself, but this time the Microsoft Compiler really seems to have generated code that better suited for the S5R3 tasks than the code generated by gcc. It's similar on Mac OS.
For S5R2, it was kind of the oposite, although not as extreme. I'm quite sure the developers can squeeze a bit more out of the gcc code with some additional tweaking. Stay tuned.
More feedback: This is from an athlon64 2800 running linux
Over Success Done 78,611.82 219.42 219.42
Over Success Done 97,309.28 219.42 219.42
Over Success Done 157,405.97 632.84 632.85
The first 2 are R3 results, notice the difference in time is significant for the same credit. Due to my work hours lately, this machine at home is definitely just sitting there crunching einstein.
The last result is an R2 typical result. From R3 to R2, roughly half the crunching time and 1/3rd the credit. D'oh!
We'll see what the project does. Hopefully the linux app gets some tweaking soon. The memories of running WINE during S4 to take advantage of Akos' optimized apps comes to mind here . . .
RE: RE: RE: RE: Afte
)
Before it was 18.5 Credits / hour now its 12.9 credits per hour
On Host 579944, an AMD
)
On Host 579944, an AMD Opteron 285 running Linux FC3, I have noticed a gradual decline in the average amount of cobblestones/credit/points awarded each month.
[pre]MONTH CRUNCH TIME TYPE FIXED VALUE AVERAGE[/pre]
[pre]Jan 17,600 S5R1 112.06 22.88[/pre]
[pre]Jan 1,900 S5R1 12.72 23.24[/pre]
[pre]Jan 1,760 S5R1 12.25 25.10[/pre]
[pre]Feb 8,280 S5R1 53.12 23.21[/pre]
[pre]Mar 7,970-8,330 S5R1 54.37-53.82 23.75[/pre]
[pre]Apr/May 68,200 S5R2 442.55 23.38[/pre]
[pre]Jun 56,580 0447.85.S5R2 361.91 23.05[/pre]
[pre]Jul 58,100 0447.85.S5R2 361.89 22.47[/pre]
[pre]Sep 78,400 0526.30.S5R2 465.47 21.38[/pre]
[pre]Sep 106,742 0538.85.S5R2 646.20 21.79[/pre]
[pre]Sep 76,111 0518.05.S5R2 454.00 21.47[/pre]
[pre]Sep 64,734 0518.05.S5R3 221.97 12.36[/pre]
Not sure about the S5R1 dates as I mainly recorded the crunch times and fixed credit values. Have only recently started adding the WU type.
The average has slowly dropped from low 23's to low to mid 21's.
My average has now taken a dive from 21.47 to 12.36.
From the length of time taken to process I am not enthused by the credit value placed on my work.
A 42.43% drop in average credit.
The S5R3 average was only over 2 work units so I am interested in the others that I have to see if it is still worth the effort.
But we will see.
Two R3 results on one more or
)
Two R3 results on one more or less dedicated E@H PC here, 191 and 206 sec per credit.
141 sec pr credit was the slowest R2 for that comp.
Not worth it IMO, i shut it down.
Team Philippines
So while the gcc compiled
)
So while the gcc compiled code for Linux and Darwin seems to have been a bit faster than that for Windows in the previous run (S5R2), now in S5R3 gcc is losing ground.
Please keep posting your results, and for convenience please mention on which operating system the result was crunched.
CU
H-BE
The wingman I've been
)
The wingman I've been monitoring got a rash of 'signal 11' client errors last night (Linux/AMD). Probably a machine problem rather than an app problem, but someone with experience of reading the Linux output might like to take a look.
Both of my Macs that have
)
Both of my Macs that have S5R3 runs are showing spreads on credit per hour. Click the thumbnail if you want to see the graphs. I wanted to save bandwidth here and at imageshack with the thumbnail. One of the graphs is a histogram like chart that shows how many of each credit per hour value I've seen.
RE: On Host 579944, an AMD
)
Well have now processed 4 S5R3 Work Units and the cobblestones per hour are still woeful,
[pre]Work Unit Process Time Claimed Credit Credit/Hour
0518.05 S5R3 66,500.88 221.97 12.02
0518.05 S5R3 62,969.81 221.97 12.69
0518.05 S5R3 63,276.57 221.97 12.63
0518.05 S5R3 60,591.06 221.97 13.19[/pre]
This averages out at just 12.62 credits per hour
My last Sept S5R2 average was 21.47 cr/h (which has been getting lower for months)
Making this an 41.22% DROP in awarded credit.
Only one more to process then I might have to put this project on the backburner in the hope that things will improve.
It was the first project I joined so I would like to keep it going (I would like to get at least to 500,000 cobblestones).
Here's something else that's
)
Here's something else that's strange. . .
As I noted before, my AMD 6000+ machine with Kubuntu 7.04 Linux has taken a significant performance hit with the switch to the 'R3 run. But, the story is quite different with the one Windows machine that's completed an 'R3 unit.
My AMD 3500+ machine, running WindowsXP, only takes a couple of hours longer to do an 'R3 than what it takes for the 6000+ machine. For the monster 656-cobblestone 'R2's, it would take about 43 hours for the 3500+ machine, vs. about 27 hours for the 6000+.
So, it seems that there's something strange about the 'R3 app that's having quite the impact with Linux machines.
RE: Here's something else
)
Yes, that is definitely the case and has been reported by others as well. As always, it's not so much an issue with the OS itself, but this time the Microsoft Compiler really seems to have generated code that better suited for the S5R3 tasks than the code generated by gcc. It's similar on Mac OS.
For S5R2, it was kind of the oposite, although not as extreme. I'm quite sure the developers can squeeze a bit more out of the gcc code with some additional tweaking. Stay tuned.
CU
H-BE
More feedback: This is from
)
More feedback: This is from an athlon64 2800 running linux
Over Success Done 78,611.82 219.42 219.42
Over Success Done 97,309.28 219.42 219.42
Over Success Done 157,405.97 632.84 632.85
The first 2 are R3 results, notice the difference in time is significant for the same credit. Due to my work hours lately, this machine at home is definitely just sitting there crunching einstein.
The last result is an R2 typical result. From R3 to R2, roughly half the crunching time and 1/3rd the credit. D'oh!
We'll see what the project does. Hopefully the linux app gets some tweaking soon. The memories of running WINE during S4 to take advantage of Akos' optimized apps comes to mind here . . .