Show me an FPGA under the same conditions.

The thread completes faster so it has stale work due to LP.

Intensity determines the # of hashes in a workload (batch).
hashes in workload  = 2^(15+Insensity)

With 1 thread a 500 MH/s GPU simply runs at 500 MH/s.
With 2 threads the GPU is split into two threads each running at 250 MH/s.

For a given intensity a GPU will finish faster with less threads.

Yes you can specify per GPU values like this

With one value it applies that value to all cards.  

Either way works.

Rig powering off sounds like a power issue.

The weal thing is the email comes off as just trollish.

Sending something which looked like it came from a govt agency regarding freezing accounts owned by OKPAY and money laundering charges would have done more damage.

Lucky for OKPAY the idiot who wrote it comes off as less legit than a nigerian scammer.

I think you fail to understand how old some nodes are.  Even if programmed to start some years in the future a good chunk of the network would be incompatible.

No a 7990 @ 1 Ghz will do 2x what a 7970 @ 1 Ghz will do however I don't think a 7990 will do 1 Ghz (based on track record of 5970 and 6990).

Given stock clock on a 7970 is 925 Mhz and it achieves 1 GHz using 4 phase power it is unlikely that with the limits of 3 phase power and double GPU cooling the 7970 will be able to achieve a 1 Ghz clock (mining stable 24/7 for weeks).

I have no interest in betting.  We will find out soon enough.  To avoid this thread going off topic I will leave it at that.  The likely performance of 7990 can be debated in another thread (new or existing).

A potential solution for "limbo" tx in general is a kill or fill value.  If not included by block x, the tx is void.  Client default behavior could be to set kill value for 30 blocks into future for a tx (can be overriden by users).  Still the risk is minimal.  Tx only go into "limbo" if the user violates spam rules.  To do that requires using a custom client and willfully breaking protocol rules.


The restored node should see the tx from the other LAN node. 

So neither issues are killers but it does make the protocol more "fragile".  Things need to be done right or there is a risk of invalidating funds.

The larger issue is implementation.  A change like this would require not just miners upgrading but 100% of nodes to avoid a permenent fork.  Likely an impossible goal.  There are less drastic solutions to non 51% attack double spends (like tx contracts).  This change wouldn't affect 51% attacks or Finney attacks which are the more likely double spends.

Honestly I don't know.  Most of the "data" we have is anecdotal.

Rapid changes in fan speed are likely damaging but GPU temps tend to rise slowly.  So with a temp-hysteresis of 2+ the fan shouldn't change speed that often or that rapidly.  Fans running "too slow" will likely cause unnecessary wear but who knows what too slow is.  One thing I do know is that on 5970 the ATI/AMD fan slope is too "weak".  AMD seems to be optimizing for noise not temps so I wouldn't recommend that.

Given all the variables of fan speed, ambient temp, fan quality, normal variance, air quality (dirt) I honestly don't know.

I set all my fans at 80% fixed (65% in winter) because they are in the garage and I can't hear the noise.  I use auto-gpu (throttle clocks not fan to keep temps below target) because until recently 5970s didn't play nice with "auto-fan".  Of 24 GPUs I have had 3 fan failures but they were all on used GPUs (and one was less 1 month after purchase) so who knows how they were abused before I got them.  I see no reason to change my setup since it works.

Interesting but likely impossible to implement.  Old node (not just miners) would be incompatible.   So it would require a 100% upgrade of every single node on the network to avoid disruptions.

Likely you are going to need to find an individual.  Remember MP has a flat $5 fill fee.  So $50 is 10% fee.  $25 is a 20% fee.  $10 is a 50% fee.  That is before any exchange/trader markup/markdown.

It doesn't really make sense for small amounts.

Not sure why people think a 7990 will get 1.3 GH/s?

A 5970 doesn't get 2x the hashrate of a 5870   
A 6990 doesn't get 2x the hashrate of a 6970

An overclocked 5870 can push 450 MH/s.  I wish my 4x5970 rigs pushed 3.6 GH/s.  They push about 3GH/s or ~85% of what a 8x5870 would push.

The 7990 should get >1GH/s.  Maybe 1.1GH/s. I doubt it goes much higher on air.

Yeah even if space/bandwidth wasn't an issue I don't like complicating the sharechain w/ merge mining data.  Most of the alt chains are nearly worthless and I wonder the load if it became popular to merge p2pool mine a dozen or more alt-chains.

Local generation may be rough on low end nodes so anything which makes p2pool less viable isn't worth the cost IMHO.

Would it be possible to have a separate merge mining chain and a different p2pool instance.  Still I am not clear on what level of communication or interaction is necessary between instances or even if it is possible.

Given the nearly worthless nature of alt-coins I don't see it as a useful venture.  There is so much that can be done to improve p2pool (in terms of GUI frontends, monitoring/reporting, updated docs, custom distros, simplification, etc) that I would hate to see any skill, resources, and time devoted to worthless alt-chains.

Orphans aren't wasted hashing power for the p2pool "pool" which was what was being discussed.  The node will broadcast any blocks it finds to all p2pool peers and all Bitcoin peers.  Thus even a miner with 80% oprhan rate isn't wasting his hashing power from the point of view being disccused which is avg # of shares per block (or pool luck).

I think it is made pretty clear one's PERSONAL compensation depends on relative orphan rate.

Miner has 5% orphan rate, p2pool has 10% orphan rate.  Miner is compensated 5% over "fair value".
Miner has a 10% oprhan rate, p2pool has a 10% orphan rate.  Miner is compensated "fair value".
Miner has a 15% oprhan rate, p2pool has a 10% orphan rate.  Miner is compensated 5% under "fair value".

Even there the hashing power isn't WASTED.  Blocks will still be found at same rate regardless of orphan rate but the miner's compensate will be lower (due to miner having higher orphan rate relative to the pool).


Still theoretically  I do think it is possible to make a "merged" sharechain.  Bitcoin must have a single block at each height.  This is an absolute requirement due to the fact that blocks are just compensation they include tx and there must be a single consensus on which tx is included in a block (or set of blocks).

With p2pool it may be possible to include "late shares" in the chain to reduce the orphan rate.  Honestly not sure if it is worth it because as discussed if one's oprhan rate is ~= pools orphan rate the absolute values don't really matter.

Miner 0% orphan, pool 0% orphan is the same as Miner 10% orphan, pool 10% orphan.

Where are you getting 100% ROI?  Even if difficulty remains flat block reward will be halved in 8 months.  My first thought was great concept but it will never fly due to low ROI%.  I have to hand it to giga though executed awesomely on his end and a very impressive offering.  Kinda bizzare it is trading up to 0.3 BTC per MH/s post IPO.  All the risk vs reward concerns are magnified is someone is paying 50% higher price.   I guess that also points out giga could have gotten away with even higher price (which just blows my mind).

I agree I just hate monthly fees.  The first time I go three months without using it I will be like DAMN I got ripped.

Wish they had a $1 per usage option.  I would take that.

Yeah if you did feel the need to have an honorific image on each coin/note/bill I would use things like enigma machine, babbages analytical engine, shot of the naked 5970 PCB (the classic although slowly being displaced by FPGA hashing engine), etc.

As a universal rule the memory pads tend to be in pretty good condition so they likely don't need to be replaced.  Mining doesn't stress memory anyways.    

The stock pads used in reference cooler design are 1mm if I remember correctly (remember they will be compressed after heatsink has been on them for months/years).  

http://frozencpu.com is a good mod store with lots of options and fast shipping.  I usually buy my pads from them (converting 28 5970s to waterblocks ).

I use 0.5mm but that is on DangerDen waterblock so I can't help you more.  

As far as the quality of the stock TIM job.  Yours looks about right.  Ever single one I opened looked like a angry chimp slapped it on with a 5 gallon bucket and paint brush.  The TIM they used is also inferior, very thick, almost "chunky", hard to spread, hard to get a thin layer.  Honestly I am surprised some of the GPU cores didn't cook.  Some have indicated the 7000 series is better but ATI QA was awful in the 5000 series.   Still it shows these old 5000 series models are built tough.

There is no such thing as "wasting hashing power".
You either find a block or you don't.  If you don't find a block the nonce is worthless.  I don't mean worth little, I mean absolutely worthless.
Nonces which don't solve a block are liked losing lottery tickets.  Failed attempted aren't progress towards a block.  A large number of failed tries doesn't increase the chance of finding a block in the future.  The only share worth anything is the one that solves a block and at current difficulty that occurs once every 2^32 * 1,626,856.73 =  6,987,296,450,627,500 nonces.

1 nonce = 50 BTC
6,987,296,450,627,499 nonces = 0 BTC

If we awarded compensation based on actual value of nonces found it is .... solo mining.  One would either get 50 BTC or 0 BTC for every nonce hashed.  Pool mining is a method to FAIRLY and EQUITABLY distribute that same 50 BTC to reduce variance.  We track FAILED WORTHLESS WORK because it can't be cheated.  Nothing more, nothing less.

Pools are more like block insurance companies.  In keeping with "no/limited trusted 3rd party" mantra of Bitcoin we use cryptography to ensure work can't be faked.  A pool could use a custom miner which records nonces (like a nonce odometer) and everytime a block is found collects nonce recordings from all miners and splits the block by how many nonces each miner attempted. The obvious problem is that a hacked miner would allow a miner to cheat.    Since hashes of lower difficulty can't be faked they provide good "proof" of the aproximate # of hashes attempted (subject to variance).

The 10% of work which was attempted (but failed) and then was orphaned needs to be included in the stats because it was valid work attempted. The fact that the technicalities of p2pool oprhaned it from the sharechain (compensated work) doesn't change that fact.  

It is just layers of abstraction.
Actual Work: # of nonces accurately and timely hashed (it takes on average ~7 quadrillion hashes to find one which meets current difficulty target)
Proxy for Work: nonces meeting share difficulty (1 for most pools, ~600 for p2pool) thus one p2pool share (diff 600) is a PROXY for 2.58 trillion nonces attempted.
Compensated Work: shares included in the chain (excludes orphaned shares which are a technical limit of p2pool short LP time)

One could say a solominer oprhans (discards) 100% of the failed work.  You wouldn't say a solo miner finds 1 block per share right?  The attempted work even if discarded needs to be recorded.  

If your orphan rate is ~= pool's orphan rate then your % of compensated work (shares in sharechain) ~= your % of proxy for work (shares) ~= your % of actual work (nonces hashed).


Orphaned blocks
p2pool doesn't show any higher (~1% of main fork) orphan rate ON BLOCKS.  If p2pool had 10% of its BLOCKS orphaned that would obviously cause a reduction in revenue and corresponding increase in # of shares per block.  The orphan rate on p2pool blocks is a better indication of "lost work".  An abnormally high number would indicate a problem/delay w/ network broadcasting its blocks.  Keep in mind even here relative values is what matters.  True should be 1% higher due to orphaned blocks (yes orphaned blocks represent work).  If there were no oprhaned blocks collectively miners wouldn't earn any more.

Dead on arrival (bad/stale/invalid shares killed by local node)
DOA are bad/stale/invalid shares before they even get broadcast to p2pool network and can never be a block even if they meet diff target as they would be rejected by the Bitcoin network.  They are "wasted hashing power".  DOAs unlike orphans do affect the # of shares per block.     If 2% of shares are bad/stale/invalid (not just orphaned) then 2% of your blocks will be bad/stale/invalid.  This affects all pools not just p2pool.  I would assume that any hashing graph is using post DOA hashrates.  Still DOA is a much smaller % than orphans so the difference isn't very large.

On edit: modified for clarification (of course that made it even longer ... grr).
On edit 2:  crap crap crap.  tried to simplify and turned it into a novel ("as the nonce hashes").  Sorry for wall of text.  I don't have the heart to rip it up now.

No faces.  Faces are a concept for fiat money (an extension of putting the King on the coin).

Bitcoin is more than any individual.  It exists without any individual.

Yes.  It has been at least a month (maybe 2?) since any two pools had >50%.  It has been top 3 ~50% for some time.   The % which makes up the top 3, 4, 5 has been on a slow decline.  It would be nice if someday the top 5 was <50%.

I wish blockchain showed longer intervals (like last 30 days) or a chart showing % by pool over time.