One more thing, on P4 2.8 Ghz computer it used to take some 5 hours to complete a long s4 wu (without an optimized application) and it takes now some 13+ hours to complete a long s5 wu. It seems that the s5 long wu are much looooooooooooonger than the s4 ones.
Constantinos
Yes, it's been stated that the long ones are approximately 5x longer than the old long ones, and the short ones are approximately 2 times longer, from the STANDARD applications.
But 5 is optimized, at least in part. So the 5x is length of crunch, but more than that in data. If it was not optimized, I am unsure how much longer it would take.
Due to EDF for other projects have one machine still not on to S5's yet. Assume others might be in same boat, and I notice on some of my pending S4 units the servers were re-sending yesterday.
Due to EDF for other projects have one machine still not on to S5's yet. Assume others might be in same boat, and I notice on some of my pending S4 units the servers were re-sending yesterday.
Andy
I just checkked some of my older pending credit, some of it's being sent with a ~28h turn around. Looks like they're trying to speedup the wrapup phase.
Due to EDF for other projects have one machine still not on to S5's yet. Assume others might be in same boat, and I notice on some of my pending S4 units the servers were re-sending yesterday.
Andy
I just checkked some of my older pending credit, some of it's being sent with a ~28h turn around. Looks like they're trying to speedup the wrapup phase.
Why are we stuck at ~362 days of S5 work remaining?
I suspect the computation has the implicit assumption that all resources are devoted to S5. But S4 still has 87000 WU's without a canonical result, and apparently some S4 results have not yet been sent out for the first time (inference from 8 day + plus oldest unsent result entry).
I'd think the estimate would need some settling time after the great majority of hosts have switched to S5 before it means much. Of course if the optimizers succeed in influencing the productivity of the overall fleet appreciably, it may take yet longer for the estimate to stabilize. That would be a good thing.
Why are we stuck at ~362 days of S5 work remaining?
Every day the "total needed" on the server status page seems to
increase by 1 day, so that "Work still remaining" remains
constant.
OTOH, the floating point speed (55.3 TFLOPS) is increasing daily.
This does not make sense.
I think the "Search Progress" stats are based on the rate at which WUs are distributed, not completed. The initial flood of S5 units, going out to machines finishing S4 units, is slowing as the clients start crunching much longer WUs.
RE: One more thing, on P4
)
Yes, it's been stated that the long ones are approximately 5x longer than the old long ones, and the short ones are approximately 2 times longer, from the STANDARD applications.
But 5 is optimized, at least in part. So the 5x is length of crunch, but more than that in data. If it was not optimized, I am unsure how much longer it would take.
official estimate for
)
official estimate for completion of s5 is now 368.1 days and 363.5 to go, come on friends let´s take it down not up.
Based on working with just
)
Based on working with just one S5 run, it looks like the time for me goes from 9 hours for S4 to 35 hours for S5. (celeron 1.8 Mhz, 496 Mb RAM)
Due to EDF for other projects
)
Due to EDF for other projects have one machine still not on to S5's yet. Assume others might be in same boat, and I notice on some of my pending S4 units the servers were re-sending yesterday.
Andy
RE: Due to EDF for other
)
I just checkked some of my older pending credit, some of it's being sent with a ~28h turn around. Looks like they're trying to speedup the wrapup phase.
http://einsteinathome.org/workunit/8710946
RE: RE: Due to EDF for
)
Going to need that speedup if we have too many hosts like hostid=654189 that has over 80 still to process and it already has many units timed out.
Andy
Why are we stuck at ~362 days
)
Why are we stuck at ~362 days of S5 work remaining?
Every day the "total needed" on the server status page seems to
increase by 1 day, so that "Work still remaining" remains
constant.
OTOH, the floating point speed (55.3 TFLOPS) is increasing daily.
This does not make sense.
RE: Why are we stuck at
)
I suspect the computation has the implicit assumption that all resources are devoted to S5. But S4 still has 87000 WU's without a canonical result, and apparently some S4 results have not yet been sent out for the first time (inference from 8 day + plus oldest unsent result entry).
I'd think the estimate would need some settling time after the great majority of hosts have switched to S5 before it means much. Of course if the optimizers succeed in influencing the productivity of the overall fleet appreciably, it may take yet longer for the estimate to stabilize. That would be a good thing.
RE: Why are we stuck at
)
I think the "Search Progress" stats are based on the rate at which WUs are distributed, not completed. The initial flood of S5 units, going out to machines finishing S4 units, is slowing as the clients start crunching much longer WUs.
Dead men don't get the baby washed. HTH
RE: RE: RE: I hope we
)
Will that leave us time for lunch breaks?
Try the Pizza@Home project, good crunching.