I think it's worth repeating what Gary Roberts said. I will add the question of whether any optimization will be introduced later that may reduce the cpu seconds consumed per credit granted.
Quote:
Because of the overheads introduced during the extensive beta testing process, the 4.38 version was about 10 - 15% slower than the versions in place earlier in the S5R2 run. By maintaining parity with 4.38 you are effectively building in a 15% pay cut over what was considered fair in the earlier stages of S5R2.
Really seems to be a Linux problem, apart from my box... or are your WUs maybe from the same frequency band as mine?
No, this is a frequencyband from the high end (of S5R2), not like yours which was at the low end.
Peanut had some S5R3 units that showed great variations in runtime for the same credits, up to 20% (note: not compared to S5R2 but within S5R3 !!), far more than the +/i 5% fluctuation of S5R2. So let's hope this isn't representative. But it certainly looks as if Linux is a bit slower now.
I think it's worth repeating what Gary Roberts said. I will add the question of whether any optimization will be introduced later that may reduce the cpu seconds consumed per credit granted.
Quote:
Because of the overheads introduced during the extensive beta testing process, the 4.38 version was about 10 - 15% slower than the versions in place earlier in the S5R2 run. By maintaining parity with 4.38 you are effectively building in a 15% pay cut over what was considered fair in the earlier stages of S5R2.
As to Gary's comment: AFAIK the debugging code introduced at the end of S5R2 is still in there (profiling tools will tell you this), so it's ok to aim for parity with 4.38. Once the debugging code is out again, the speed will increase accordingly.
Bernd has said that optimization will is planned for S5R3.
Really seems to be a Linux problem, apart from my box... or are your WUs maybe from the same frequency band as mine?
No, this is a frequencyband from the high end (of S5R2), not like yours which was at the low end.
Peanut had some S5R3 units that showed great variations in runtime for the same credits, up to 20% (note: not compared to S5R2 but within S5R3 !!), far more than the +/i 5% fluctuation of S5R2. So let's hope this isn't representative. But it certainly looks as if Linux is a bit slower now.
CU
Bikeman
a fluctuation of more than 10% is common for hyperthreaded CPUs, as they have no independent cores.
Edit: but Peanut seems to have dual/quad core CPUs with Darwin installed...
Really seems to be a Linux problem, apart from my box... or are your WUs maybe from the same frequency band as mine?
No, this is a frequencyband from the high end (of S5R2), not like yours which was at the low end.
Peanut had some S5R3 units that showed great variations in runtime for the same credits, up to 20% (note: not compared to S5R2 but within S5R3 !!), far more than the +/i 5% fluctuation of S5R2. So let's hope this isn't representative. But it certainly looks as if Linux is a bit slower now.
CU
Bikeman
a fluctuation of more than 10% is common for hyperthreaded CPUs, as they have no independent cores.
Peanut's monster cruncher is an Intel(R) Xeon(R) CPU X5365 @ 3.00GHz : 4 CPUs with two cores each. No Hyperthreading, true cores.
Really seems to be a Linux problem, apart from my box... or are your WUs maybe from the same frequency band as mine?
No, this is a frequencyband from the high end (of S5R2), not like yours which was at the low end.
Peanut had some S5R3 units that showed great variations in runtime for the same credits, up to 20% (note: not compared to S5R2 but within S5R3 !!), far more than the +/i 5% fluctuation of S5R2. So let's hope this isn't representative. But it certainly looks as if Linux is a bit slower now.
CU
Bikeman
More Linux data that seems to confirm this -- 17.8 credits/hr for 5 S5R3 results vs. 22 for the last four S5R2s. Much larger variation as well -- longest result 8.8% longer than shortest, as opposed to a <1% variation with S5R2.
My hosts 1001562 and 1001564 are identical boxes, running - as near as I can manage - under identical conditions. 1001562 has already switched to S5R3 - it picked up three 522.10Hz WUs this morning, following on from S5R2 work.
1001564 has got some S5R2 re-issues, so I won't be able to remove the Beta app until tomorrow lunchtime. When I do, I'll do a complete project reset, to see if I can pick up some low-frequency WUs like Annika's. That will give a direct, controlled comparison (if it works) - at least for the Windows/Intel environment.
Well, that was a spectacular failure!
Ran 1001564 down to empty, and deleted the app_info and all references to existing data files. I'd spotted that there was some S5R2 work around, so I copied the S5R3 app from 1001562 and rolled my own R3 app_info to force the upgrade. Cleared LTD and let it rip - nothing. Nowt, nada, zilch. "No work from project".
Took the app_info back out, and now I'm doing a test run to compare S5R2 stock v4.38 with beta v4.40! It'll be about another day and a half before that box is ready for more work.
All I can report so far is that on 1001562, working on 522.10Hz WUs, S5R3 is paying an average of 18.87 credits/hour, about 4.5% below the rate (19.75 cr/hr) that Beta v4.40 paid for the same frequency.
NB for anyone else wanting to do any testing - have a look at the server status page first. While the "Oldest Unsent Result" is at 8 days or more (creation time of 12:40 on Monday 17 September), you'll probably be getting S5R2 work.
I think it's worth repeating
)
I think it's worth repeating what Gary Roberts said. I will add the question of whether any optimization will be introduced later that may reduce the cpu seconds consumed per credit granted.
RE: Really seems to be a
)
No, this is a frequencyband from the high end (of S5R2), not like yours which was at the low end.
Peanut had some S5R3 units that showed great variations in runtime for the same credits, up to 20% (note: not compared to S5R2 but within S5R3 !!), far more than the +/i 5% fluctuation of S5R2. So let's hope this isn't representative. But it certainly looks as if Linux is a bit slower now.
CU
Bikeman
RE: I think it's worth
)
As to Gary's comment: AFAIK the debugging code introduced at the end of S5R2 is still in there (profiling tools will tell you this), so it's ok to aim for parity with 4.38. Once the debugging code is out again, the speed will increase accordingly.
Bernd has said that optimization will is planned for S5R3.
CU
H-BE
RE: RE: Really seems to
)
a fluctuation of more than 10% is common for hyperthreaded CPUs, as they have no independent cores.
Edit: but Peanut seems to have dual/quad core CPUs with Darwin installed...
Udo
RE: RE: RE: Really
)
Peanut's monster cruncher is an Intel(R) Xeon(R) CPU X5365 @ 3.00GHz : 4 CPUs with two cores each. No Hyperthreading, true cores.
CU
Bikeman
RE: Peanut's monster
)
Er, that would be 2 CPUs with 4 cores each, but the point is still well made: no Hyperthreading, true cores.
RE: RE: Really seems to
)
More Linux data that seems to confirm this -- 17.8 credits/hr for 5 S5R3 results vs. 22 for the last four S5R2s. Much larger variation as well -- longest result 8.8% longer than shortest, as opposed to a <1% variation with S5R2.
System is a QX6600, 4GB RAM, CentOS 5.
RE: I have an AMD Athelon
)
The next unit I crunched on this machine was 26% longer in duration, yet I received the same point value. Therefore, this equals a 26% deficit in point value compared with S5R2.
So perhaps I am not so happy! :( ;)
AMD Athlon(tm) 64 X2 Dual
)
AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
Horst 900886
S5R2: 16.4 credits/CPU_hour
S5R3: 9.5 credits/CPU_hour
OS: Linux 2.6.18 running in a Xen Express DomU
RE: My hosts 1001562 and
)
Well, that was a spectacular failure!
Ran 1001564 down to empty, and deleted the app_info and all references to existing data files. I'd spotted that there was some S5R2 work around, so I copied the S5R3 app from 1001562 and rolled my own R3 app_info to force the upgrade. Cleared LTD and let it rip - nothing. Nowt, nada, zilch. "No work from project".
Took the app_info back out, and now I'm doing a test run to compare S5R2 stock v4.38 with beta v4.40! It'll be about another day and a half before that box is ready for more work.
All I can report so far is that on 1001562, working on 522.10Hz WUs, S5R3 is paying an average of 18.87 credits/hour, about 4.5% below the rate (19.75 cr/hr) that Beta v4.40 paid for the same frequency.
NB for anyone else wanting to do any testing - have a look at the server status page first. While the "Oldest Unsent Result" is at 8 days or more (creation time of 12:40 on Monday 17 September), you'll probably be getting S5R2 work.