Shutting down my K8's and Rebuilding with K7's.

Not necessarily.

If you look at historical data for Einstein@Home, you can see that around this time of year, there's always a decline in active hosts, because of summer on the northern hemisphere. The decline will continue for two more month or so.

The active hosts count is higher in this statistics, probably because the threshold value in days for inactivity is higher. Classifying a host as inactive that has not been active for the past 7 days is a bit pessimistic, IMHO.

CU

BRM

Have no idea how to find one except for the obvious "google for it" approach, but couldn't actually locate one, yet. Maybe later today

CU

BRM

I can sort of understand that many crunchers, especially AMD users, are getting frustrated (especially those who bought hardware just for crunching). It is sort of long ago that we got an official update and that can be a bit demotivating even to the more dedicated among us. True, there aren't many crashes around, but after months I still have to use a "hacked" binary to cut the Win penalty on my Venice core AMD down from more than 65% (!) to a more acceptable 30, compared to the Linux app (hey guys, this is, among other stuff, my gaming box... I WANT to run Windows on it from time to time) and no one has been able to figure out why my Core Duo laptop also suffers a 40% Win penalty while it does perfectly okay in all other projects under both OSs. I haven't given up on Einstein altogether but have redirected some of my resources towards Prime Grid and Malariacontrol (hell, does that Venice do a good job with those new predictor WUs).

I was quite surprised when I saw that tiny A64 3000+ being able to handily beat my machine even while working on a result that was longer-running than what I was trying to compare... While I know that using energy consumption as an excuse for excessive demands from the project is not exactly how to handle the frustration, the project needs to understand that with the rising costs of energy, they need to respond to getting some sort of general parity between platforms within their own project before even thinking about cross-project parity. 10% difference is marginally acceptable. The 30 to 65% range you mentioned is truly unacceptable and would never be tolerated if this was a commercial application and is likely only tolerated because of the fact that work is being done at a fast enough pace for the scientists.

Brian