I think they also like good graphics cards... aren't CPDN and SAP done with graphical models? I thought so, which is the reason I never participated...
@Scott Brown,
A standard machine would be nice but as you can see with Tony's results and my reply different machine perform differently on different projects. The celery and AMD mentioned were both primarily Einstein crunchers as that was were they performed the most science. Seti likes Intels with as large an L2 cache as it can get. Not too sure there is much difference on most of the other projects although I get the impression CPND, and maybe the other climate projects, like lots of memory and frequent back-ups.
Andy
I would agree with pretty much everything that you have said. However, as I noted, one can set any machine as the standard (it is completely arbitrary and could even be an "averaged" machine that combines various features--e.g., cpu, memory, OS, etc.). Because different machines perform differently on different projects does not preclude this possibility. I would also add that Tony's nicely done cross-project figures, in addition to hardware performance differences, also incorporate fundamental differences in how credit is claimed and granted (i.e., credit by benchmark, client FLOPS, server FLOPS, etc. as well as structural differences such as redundancy). Thus, it is not possible to determine what factors cause such variability (though it is probably reasonable to assume that all of the above matter in varying degrees by project).
My latest update of different projects as they pertain to cross project parity can be found here. Note: the einstein data represented was collected between Jul 25 and Aug 10(the old S5 sytem). I've been shuffling projects to collect data and have put einstein back into the mix this morning so I can see where the new system is at.
Note: all data is from standard/official project software.
And Yes, Eric K from seti has a copy of this. Others are also collecting data on this issue.
Nice work there Tony.
FWIW, this dovetails with my results nicely, the exception being I'm not seeing the difference you have between SAH and EAH due to running the optimized SAH apps. With those I have virtual credit rate parity between the two projects.
However, I think this shows the EAH team has worked really hard to make the best performing EAH apps automatically available to everyone (more so than SAH does at this point, as evidenced by the performance gain of Simon's and Crunch3r's apps).
I sure Bernd and Dr. Allen will take this into account before they make any decision to adjust credit again.
Interesting. I have just ONE result in on my AMD64 3700, it's "benchmark calculated" credit/hour (as seen below) is 14.14 credit/hour, with app 4.02 it averaged 21.86/hour, but with 4.24 it got a whopping 33.52 credits/hour.
On my AMD64 Mobile 3700, the "Benchmark calculated" credit/hour (as seen below) is 13.33 credit/hour, with 4.02 it averaged 20.83 credits/hour, but with 4.24 it averaged (3 results so far) 21.74.
did the formula get boosted, reduced, or hasn't it happened yet? I haven't been following this board for weeks?
Credit was dropped by ~17% when 4.24 (and equiv *nix apps) were released, and then again by the same amount a few days later once it was clear the first drop was too small. The net effect of the drops was to make credit/hour roughly the same for 4.02 and 4.24.
Credit was dropped by ~17% when 4.24 (and equiv *nix apps) were released, and then again by the same amount a few days later once it was clear the first drop was too small. The net effect of the drops was to make credit/hour roughly the same for 4.02 and 4.24.
thanks, I'll let her roll, and put a few under the belt.
Interesting. I have just ONE result in on my AMD64 3700, it's "benchmark calculated" credit/hour (as seen below) is 14.14 credit/hour, with app 4.02 it averaged 21.86/hour, but with 4.24 it got a whopping 33.52 credits/hour.
On my AMD64 Mobile 3700, the "Benchmark calculated" credit/hour (as seen below) is 13.33 credit/hour, with 4.02 it averaged 20.83 credits/hour, but with 4.24 it averaged (3 results so far) 21.74.
did the formula get boosted, reduced, or hasn't it happened yet? I haven't been following this board for weeks?
As Dan has said, the credit per WU has dropped (twice) recently.
However, the one WU with credit on your AMD64 3700 at the moment is one which was re-issued after one of the original quorum members failed to report. These re-issued WUs are given credit at the rate prevailing when they were first issued. You got a lucky bonus!
My 1.8 P4 Northwood server 475735 is currently showing a good snapshot of what you can expect.
There's a small variation between WUs, but the long ones are typically just over 120 - the occasional 170's are outliers from before the credit correction/release of speeded-up app. There's no equivalent of the credit ranges from different ARs that you're used to from SETI.
This will be a bit long in the pic dept, sorry to all you dial up users. Here's my up to date cross project comparison and graphs pertaining to my puters. Red text indicates "non current" credit schemes. Green indicates "Benchmark calclulated" credit/hour (the credit I should be claiming/granted).
NOTE: my Einstein data sample is small but I'm working on it. I think maybe when I've collected many samples, I should make Einstein two columns, one for long wus and one for short.
Also, the Einstein data labelled "4.24 pre Aug 30 rate reduction" only includes the data from WUs granted credit on the immediately previous system, not the original 4.24 scheme.
I think they also like good
)
I think they also like good graphics cards... aren't CPDN and SAP done with graphical models? I thought so, which is the reason I never participated...
RE: @Scott Brown, A
)
I would agree with pretty much everything that you have said. However, as I noted, one can set any machine as the standard (it is completely arbitrary and could even be an "averaged" machine that combines various features--e.g., cpu, memory, OS, etc.). Because different machines perform differently on different projects does not preclude this possibility. I would also add that Tony's nicely done cross-project figures, in addition to hardware performance differences, also incorporate fundamental differences in how credit is claimed and granted (i.e., credit by benchmark, client FLOPS, server FLOPS, etc. as well as structural differences such as redundancy). Thus, it is not possible to determine what factors cause such variability (though it is probably reasonable to assume that all of the above matter in varying degrees by project).
RE: My latest update of
)
Nice work there Tony.
FWIW, this dovetails with my results nicely, the exception being I'm not seeing the difference you have between SAH and EAH due to running the optimized SAH apps. With those I have virtual credit rate parity between the two projects.
However, I think this shows the EAH team has worked really hard to make the best performing EAH apps automatically available to everyone (more so than SAH does at this point, as evidenced by the performance gain of Simon's and Crunch3r's apps).
I sure Bernd and Dr. Allen will take this into account before they make any decision to adjust credit again.
Alinator
Interesting. I have just ONE
)
Interesting. I have just ONE result in on my AMD64 3700, it's "benchmark calculated" credit/hour (as seen below) is 14.14 credit/hour, with app 4.02 it averaged 21.86/hour, but with 4.24 it got a whopping 33.52 credits/hour.
On my AMD64 Mobile 3700, the "Benchmark calculated" credit/hour (as seen below) is 13.33 credit/hour, with 4.02 it averaged 20.83 credits/hour, but with 4.24 it averaged (3 results so far) 21.74.
did the formula get boosted, reduced, or hasn't it happened yet? I haven't been following this board for weeks?
Credit was dropped by ~17%
)
Credit was dropped by ~17% when 4.24 (and equiv *nix apps) were released, and then again by the same amount a few days later once it was clear the first drop was too small. The net effect of the drops was to make credit/hour roughly the same for 4.02 and 4.24.
RE: Credit was dropped by
)
thanks, I'll let her roll, and put a few under the belt.
RE: Interesting. I have
)
As Dan has said, the credit per WU has dropped (twice) recently.
However, the one WU with credit on your AMD64 3700 at the moment is one which was re-issued after one of the original quorum members failed to report. These re-issued WUs are given credit at the rate prevailing when they were first issued. You got a lucky bonus!
RE: You got a lucky
)
Wooohoooo!. I assume I should not use that one in my upcoming data table, as it might throw off the results (unless I collect a lot of them). LOL
thanks
My 1.8 P4 Northwood server
)
My 1.8 P4 Northwood server 475735 is currently showing a good snapshot of what you can expect.
There's a small variation between WUs, but the long ones are typically just over 120 - the occasional 170's are outliers from before the credit correction/release of speeded-up app. There's no equivalent of the credit ranges from different ARs that you're used to from SETI.
This will be a bit long in
)
This will be a bit long in the pic dept, sorry to all you dial up users. Here's my up to date cross project comparison and graphs pertaining to my puters. Red text indicates "non current" credit schemes. Green indicates "Benchmark calclulated" credit/hour (the credit I should be claiming/granted).
NOTE: my Einstein data sample is small but I'm working on it. I think maybe when I've collected many samples, I should make Einstein two columns, one for long wus and one for short.
Also, the Einstein data labelled "4.24 pre Aug 30 rate reduction" only includes the data from WUs granted credit on the immediately previous system, not the original 4.24 scheme.