Yes.  bin file is simply a cached copy of the compiled kernel.  Once a copy of the kernel has been loaded by the GPUs the bin file isn't used until the next start of cgminer.

auto-gpu also maintains constant temperature and keeps fan at a constant speed.

Also I think everyone is missing the point: auto-gpu vs auto-fan isn't the issue.

cgminer is showing REST.  Which indicates it has idled a GPU but the GPU continues to burn away at 100% load.  If you had a fan failure for example and that bug occurred it would indicate REST but the GPU would continue at 100% load until it destroyed the core.

They have 6990 performing worse than 6970.  None of the values have any relevence to real world.  The amount of error varies from card to card making even relative comparisons invalid.

The "benchmark" is beyond useless and beyond any defense.

The one on the left isn't too bad and it is used for misc I/O which doesn't get to hot.  The one in the middle powers the "left" GPU core.  You have a huge hole torn out of the pad.  It has to be replaced.

Also you got a lot of TIM residue on the two GPU cores.  Give it another splash of Cleaner #1 and some fresh qtips and you can get it spotless.

Well 6 blocks in last 24 hours is a good start.   But dug ourselves a deep hole over the last 7 days.

I don't have any singles but you didn't beat me either.   Still 2.86 is pretty impressive.

My new rig configuration:
4x5970
3.2 GH/s @ 1080W
3.02 MH/W

That is on 240V circuit, 80-Plus Gold PSU, usb drive running linux, optimized BIOS, underclocked & undervolted sempron, and >3 GH/s per rig.

I am pretty sure it isn't possible to get higher efficiency from a GPU rig without undervolting the GPUs.  A 4x7990 (or possibly 3x7990) rig will likely beat that though.

Well the people who pre-mined 12M coins and the ones who mined in the first million coins at 1/10,000th the work per coin will thank you for the transfer of wealth.

Interesting but as indicated no source = too risky.

They won't collude because someone has to lose to win.  Look at the Forex market.  Trillions of dollars change hands every day.  With millions of participants and trillions of dollars manipulating the market is nearly impossible.

Thus fiat:fiat exchange rates are relatively stable.  Now the speculators would love for daily fiat swings to be +/-5% but the market is so deep that nobody has the amount of money (literally trillions of dollars) to move it in any significant fashion.

More speculators (even driven for nothing but zero sum profits) will make the Bitcoin markets deeper.  Hopefully someday dropping 100K coins will barely cause a ripple.

Regulation has nothing to do with stable markets.  If anything the barriers to entry caused by many regulations often destabilize markets.

Merged mining is done by putting the child chain in the coinbase field.

Merged chains can't get something for nothing.  If there fees are low they why will miners mine them?  Ultimately each miner will decide which chains to mine.  No current chain with the exception of namecoin has any significant merge mining.

$3 monthly fee kinda puts a damper on casual use.

Accounts aren't addresses.   Accounts are groups of addresses.  It was designed to be an accounting system for wallets but honestly it is next to worthless (for a variety of reasons).

If you want to send 1 BTC from address A to address B the only way possible to create a tx and submit it to the network.  It doesn't matter if address A & B are in the same wallet or on other sides of the globe.  There are no exceptions.  

If you think about it obviously this has to always be the case.  If you could move funds between addresses without making a tx how would the network verify their balances?

~0.04 BTC

The question becomes why?

Why would the new node include the orphan coinbase in the next block?  Without an incentive they won't.  You actually would make larger pools more powerful.  Every miner would include their own orphans in their own next block attempt.  For a smaller miner that means a negligible % gain however for a pool like DeepBit they would be able to recover 35% of their orphans.  Now orphans are currently only 1% but say in a different protocol they were higher .... 3%.  DeepBit size would give them a 1% advantage over smaller pools.  That higher revenue would likely mean they become even larger.  At 50% of hashing power they would gain 1.5% effective revenue over other pools.

The other issue is validation.  The original orphaned block (or at the very least the merkle tree, and block header) would need to be included.  To validate the new block w/ orphaned coinbase you would need to validate the coinbase was also valid.  Otherwise nodes could simply put double coinbases in every block.  That orphaned block data would need to remain a part of the blockchain forever so that blockchain can be validated back to the genesis block by future nodes.

So the short answer is there is no technical reason you couldn't but it would have some unintended consequences (giving larger pools advantage over smaller ones) and would require storage of orphan blocks into perpetuity.  A lot of code, complexity, and testing for something that in the long run has no appreciable benefit to any user.

Now for something like p2pool where the orphan rate has PR cost (xyz thinks p2pool is a scam because he "loses" 8% of his hash power to orphans) a system which merges orphaned shares may have some value.  p2pool discards the end of the sharechain so there is no "into perpetuity" storage cost.  Even here it would have real effect on revenue but it would reduce the volatility of smaller miners and improve the "perception" of uneducated miners.

Except the ability to send spam.

Ah I see it in github now.  Must be post v0.10.3.  I tried simply copying the html files to my static-web folder but most of stats don't display. 

What I see
Blocks and payout breakdown are visible but removed for brevity.

Is there backend changes (post v0.10.3) required to to enable that functionality?

You have been producing totally worthless work making invalid blocks as part of a defunct chain.

Those blocks have been oprhaned (and thus coinbase reward orphaned also) because they either contain invalid tx or build upon blocks with invalid txs.  All miners must be BIP16 compatible post 1 April.  Someone released poison pill tx on to the Bitcoin network which are invalid but only in ways up to date bitcond can detect.

Until you upgrade your miner will perpetually include these invalid tx into blocks only to have them eventually orphaned out as the miners on main chain see them as invalid.

Per OP:

only auto-gpu should be required.  that is how I have my 5970 farm configured.

The fact that cgminer is showing REST indicates a deeper problem.  cgminer IS trying to shutdown the card.  If it was a config issue it simply would never even attempt a shutdown.

I have never seen this bug before and it is somewhat worrisome.  I just had a 5970 idle due to overheat yesterday without issue. 

Forrestv,
it may be useful in the next version to have a http://(p2pool IP address):9332/index.hmtl page with links to other web interface options and explanation.  It would make the web interface self documenting.  As URI change or new ones are added one just needs to check /index or /help.

On edit: actually looks like I might be able to make one myself.

Yes you did.  So please pay me the 28 BTC your jynxing has cost me.