Based on the client's estimate, yes, the WU should never have been sent. That's granted. But the question still is whether this estimate is realistic or not. To me it looks too pessimistic.
CU
BRM
The part your overlooking here is the estimates from the scheduler log are not client side generated other than they are based on the BM's and other metrics the host has last reported. They are server side calculated, although I'm not 100% sure at the moment (brain fade) about who actually calculates the RDCF.
Anyway, we can compute RDCF ourselves :-)
ETAcpu = Nflop /BMflops * RDCF
where NFlops is a hypothetical floating point operations equivalent of the computational effort for this WU, estimated by the WU-generator
So, for the 400 MHZ box in question, we have a Benchmark of 300 MFlops
ETAcpu ~ 24 d ~ 2 * 10^6 sec
BMFlops ~ 300 *10^6 ops / sec
Nflop ~ 5.5 * 10^14 (taken from one of my own monster results, see the last argument for the client in client_state.xml for the result in question)
==>RDCF would be close to 1 :-(.
Oh-oh, this estimation seems to be realitic after all for that box ...
Although the bright side is that S5R2 has brought the issue to a point where I think it deserves another close look at by the project team, once they get a firm handle on functional problems with the new app and validator.
To step up on the soap box for a bit, this is why abandoning the project during this BETA TEST PHASE is really shooting yourself in the foot in the end, regardless of what projects you run.
Taking hosts off the project solely to chase cobblestones makes it so that the project doesn't get tested against every combination it will see in practice. Therefore subtle problems can go undetected and unfixed.
I don't like running a host for 2 weeks for no credit anymore than the next guy does. But if it means it can help refine EAH in particular, and the BOINC framework in general, then that time was not 'wasted' ultimately.
My AMD 3500+ machine, running WindowsXP, has just finished the first "monster" that I've received. It was worth 656.09 Cobblestones, and took 42.35 hours. It looks like the next one that I've received is about the same size.
Maybe, if he was running full time. However, he's got a DQ of 70 which indicates the last result was a failure, and there's no scoring activity shown on BOINCStats within the last sixty days.
Pretty grim looking prospects at this point, but hope springs eternal. ;-)
Oh-Oh...wingman is a PowerMac with ca 300 MFlops only...I wouldn't hold my breath :-(
He might make it. I have a G3 PowerMac that's slower than this guy's, and it's made deadline on a couple of 525-Cobblestone units.
I have a couple of G4/400 Macs, benchmarking at about 300 MFlop/s & 600 MIPS, each attached to this project and at least one other; both are returning three- to four-hundred-CS results on time—but admittedly without a lot to spare, and the systems run BOINC day & night. These tasks take around 100 to 140 hours of CPU-time; extrapolating (given that we get about 330 h of clock-time) suggests that dedicated hosts in this performance bracket should be capable of getting through a “monster WU� within the deadlines.
I’ll take this opportunity to register another plea for the deadlines to be increased. I understand that the science app can’t be changed at the drop of a hat, but do the same ‘conservative’ practices apply to the settings on the servers?
RE: RE: Based on the
)
Anyway, we can compute RDCF ourselves :-)
ETAcpu = Nflop /BMflops * RDCF
where NFlops is a hypothetical floating point operations equivalent of the computational effort for this WU, estimated by the WU-generator
So, for the 400 MHZ box in question, we have a Benchmark of 300 MFlops
ETAcpu ~ 24 d ~ 2 * 10^6 sec
BMFlops ~ 300 *10^6 ops / sec
Nflop ~ 5.5 * 10^14 (taken from one of my own monster results, see the last argument for the client in client_state.xml for the result in question)
==>RDCF would be close to 1 :-(.
Oh-oh, this estimation seems to be realitic after all for that box ...
CU
BRM
LOL... The prosecution
)
LOL...
The prosecution rests! ;-)
Although the bright side is that S5R2 has brought the issue to a point where I think it deserves another close look at by the project team, once they get a firm handle on functional problems with the new app and validator.
To step up on the soap box for a bit, this is why abandoning the project during this BETA TEST PHASE is really shooting yourself in the foot in the end, regardless of what projects you run.
Taking hosts off the project solely to chase cobblestones makes it so that the project doesn't get tested against every combination it will see in practice. Therefore subtle problems can go undetected and unfixed.
I don't like running a host for 2 weeks for no credit anymore than the next guy does. But if it means it can help refine EAH in particular, and the BOINC framework in general, then that time was not 'wasted' ultimately.
Alinator
My AMD 3500+ machine, running
)
My AMD 3500+ machine, running WindowsXP, has just finished the first "monster" that I've received. It was worth 656.09 Cobblestones, and took 42.35 hours. It looks like the next one that I've received is about the same size.
I hope that my wingmen are up to the task!
RE: I hope that my wingmen
)
Oh-Oh...wingman is a PowerMac with ca 300 MFlops only...I wouldn't hold my breath :-(
Yep, I was thinking the same
)
Yep, I was thinking the same thing. Most likely he'll take a pretty heavy hosing from the massive skypoint flak and go down in flames. :-)
Donald's still flying solo on the new one.
Alinator
RE: RE: I hope that my
)
He might make it. I have a G3 PowerMac that's slower than this guy's, and it's made deadline on a couple of 525-Cobblestone units.
Maybe, if he was running full
)
Maybe, if he was running full time. However, he's got a DQ of 70 which indicates the last result was a failure, and there's no scoring activity shown on BOINCStats within the last sixty days.
Pretty grim looking prospects at this point, but hope springs eternal. ;-)
Alinator
648.23 http://einstein.phy
)
648.23
http://einsteinathome.org/workunit/34205153
Hmmm... There's some
)
Hmmm...
There's some interesting observations to be had by recursively looking through your wingman, and his wingmen and so on. ;-)
Alinator
RE: RE: Oh-Oh...wingman
)
I have a couple of G4/400 Macs, benchmarking at about 300 MFlop/s & 600 MIPS, each attached to this project and at least one other; both are returning three- to four-hundred-CS results on time—but admittedly without a lot to spare, and the systems run BOINC day & night. These tasks take around 100 to 140 hours of CPU-time; extrapolating (given that we get about 330 h of clock-time) suggests that dedicated hosts in this performance bracket should be capable of getting through a “monster WU� within the deadlines.
I’ll take this opportunity to register another plea for the deadlines to be increased. I understand that the science app can’t be changed at the drop of a hat, but do the same ‘conservative’ practices apply to the settings on the servers?