Is the donation % now taking from BTC and NMC?  It would be nice to have a separate donation for each, or a NMC donation address for the pool.

Donation currently is set the same for both NMC and BTC.  I will spit it up so that you can set it individually.

As soon as I can find a reliable API for gathering the exchange rate between NMC and BTC, I will make the ability to convert available.

Are block stats messed up for anyone else?

This has probably been explained somewhere in the previous 50 pages of this topic, but what exactly is the prop differential?

It tells you how much you made (or lost) in comparison to mining at a 100% fair proportional pool (which doesn't exist because of hoppers).  Basically, it gives you a rough guide of how much more you are making compared to mining on a proportional pool that has hoppers on it.  When you see a + percentage, it usually means someone has been hopping the pool or had miner problems and stopped mining before the block was finished.  You gain x% more than you would have if you were mining at a prop pool and that person was hopping or quit prior to the block being solved.


It may be "normal" in so far as it's the going rate in Australia, but it is still utterly ridiculous.  The state of your Data Centers in Australia are like our wireless carriers here - they are crying about artificial bandwidth shortage, which simply does not exist, and then charging you for it.  Bandwidth is cheap the world over.  Australian bandwidth isn't any more expensive than US bandwidth - they all run on the same hardware.  The intercontinental links may be more congested, but this has very, very little to do with your ISPs and the Data Centers.  Traffic in and around Australia is counted towards the artificially low caps, even though the IC links are not utilized... so you're being charged a premium for this artificial bandwidth scarcity.  Our wireless carriers, and to an extent our wireline carriers are trying to pull the same thing over here, most egregiously AT&T and Comcast.

For 99% of the population, they have no idea what bandwidth capacity is (or even what bandwidth really is), but for the few people who actually work in the industry and work with the equipment, we know what a joke the whole thing is.  There is a glut of bandwidth.  The backbone in the US is at a fraction of it's current capacity and adding capacity is dirt cheap. There is no bandwidth shortage in the US or worldwide.  Anyone who tells you differently is lying or severely misinformed. The only people crying about bandwidth shortages are those that stand to make money from charging you for your usage.

Hi Inaba,

if you are interested, i currently use this api for exchange rates:
http://exchange.bitparking.com:8080/api/ticker

Thanks catfish.  There's a lot that can be done with the guide for mining in particular.  I just put together the guide for the easiest/quickest/simpliest of methods to get it up and running, but as for optimization, it's definitely not a good guide for that.

As far as python-jsonrpc - I don't think you need it anymore and if I recall, it's not in the guide.  Only pyopencl is required now.

Anyway, the pool is pretty stable unless I am poking at it with a stick, then it gets uppity... but I haven't had to poke any sticks into the pool in a while.  I do need to make some adjustments to the internals of the getwork server now that we are no longer doing proportional... it's still got the proportional code running but doing nothing. 

I'm also considering switching to Poolserverj when that is a bit more stable.  Although if it ain't broke, I shouldn't fix it.  But I always do.

Does anyone have a feel for how double geometric scoring affects round size based variance?

Out of interest, have you compared your average payout/share to a theoretical prop payout/share for the same round?

If anyone's not sure what I mean then just pick a previous long round and divide payout by your submitted shares. Then divide the Difficulty for that round by the total shares for that round (theoretical proportional pool payout). Compare and contrast. If you can be bothered I'd like to see the results.

You might need to compare a few sequential rounds rather than just one round. To do this, divide your actual total payout by the total shares you submitted. Then (assuming Difficulty didn't change between the rounds you are looking at) compare with (Difficulty*number of rounds)/(total shares in rounds).

It depends on the value of parameter o which every double geometric method pool chooses for his payout model:

https://bt.irlbtc.com/view/39497.msg481864#msg481864

Maybe Inaba will make the parameter o - cross-round leakage public.

If you are interested how round size based variance goes with o = 0.5 send me a pm!