Variables that help or hurt when mining

[hdmediaservices]

So I've noticed that some Scrypt pools that mine the same coin at about the same hash rate do not find a similar # of blocks (this is over a decent period of time - so its not the whole variance bad luck thing). 

I've even seen some pools at a low hash rate (in the 200-300Mh/s range) do much better than a pool at a higher hash rate (2x to 3x as much).  This would be for coins that have an average hash rate of 500Mh/s to 1Gh/s.

There must be other variables when it comes to alt coin mining pool optimization?  Are there any special tweaks? 

Or special nodes that one pool may have access to and the others do not? 

Could it just be latency? 

Or the # of miners at one time?

Just curious - as not all pools are doing the same - even though the hashes stated would predict otherwise.

[djm34]

So I've noticed that some Scrypt pools that mine the same coin at about the same hash rate do not find a similar # of blocks (this is over a decent period of time - so its not the whole variance bad luck thing).  

I've even seen some pools at a low hash rate (in the 200-300Mh/s range) do much better than a pool at a higher hash rate (2x to 3x as much).  This would be for coins that have an average hash rate of 500Mh/s to 1Gh/s.

There must be other variables when it comes to alt coin mining pool optimization?  Are there any special tweaks?  

Or special nodes that one pool may have access to and the others do not?  

Could it just be latency?  

Or the # of miners at one time?

Just curious - as not all pools are doing the same - even though the hashes stated would predict otherwise.

it depends on the net hashrate, if the nethashrate is large compared to the pool hashrate you can't exclude variance...
(after there are pool that cheat   if you have doubt and if the pool is way too unlucky, you might try to look at the address on the pool in a block finder, and check that the number of block found by the pool address is the same as the one reported on their website...).

I think latency should rather affect on the miner side meaning you would get more rejected... and smaller difficulty shares.
Could be also some bad difficulty tuning causing wrong hashrate to be reported by the pool (not really frequent if the algo is well known) etc...

[hdmediaservices]

Hmm - "bad difficulty tuning."  So would it be odd that a coin's total hashrate is delayed by 12 to 24 hours?

How would one go about correcting this issue?  Like in NOMP?  Is there an offset value?

And then if a pool has the wrong total hashrate - how does that effect its efficiency?

Thanks for your help!

[djm34]

Hmm - "bad difficulty tuning."  So would it be odd that a coin's total hashrate is delayed by 12 to 24 hours?

How would one go about correcting this issue?  Like in NOMP?  Is there an offset value?

And then if a pool has the wrong total hashrate - how does that effect its efficiency?

Thanks for your help!

I don't think the pool efficiency is affected, but it could just report a hashrate which is much higher than it is.

An other explanation could be fake shares (I think this issue has been solved) sent by some miners, that would clearly boost the total hashrate of the pool while not solving any block...

[hdmediaservices]

So - Mining Pools 101 -- are all pools mining for the same block?  Then if one finds it, they all start onto the next block?  Meanwhile that mining time for the "non-winning" pools was wasted?

I've noticed that if you see a pool with say 500Mh/s and then another pool comes in at 1.5Gh/s -- and the difficulty remains the same -- that in this case the 1.5Gh/s pool ends up finding more than the expected 75% of the blocks.  It many cases they end up finding 90% to 95% of the blocks.

Any reason to this?