[1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration!

[Inaba]

At those prices, they better be REALLY good to you!   

I'm sure they are a good company, but their prices are insane... I suppose that's what the market is in AU though.  Someone needs to come in and provide a cheap alternative and eat all the other ISPs lunch.  How can prices be so much less here in the US?  For the same as a basic $250 package for WebInABox, I can get the saem for about $50 here in the US.

[1714250539]

1714250539

[1714250539]

1714250539

[1714250539]

1714250539

[Graet]

At those prices, they better be REALLY good to you!   

I'm sure they are a good company, but their prices are insane... I suppose that's what the market is in AU though.  Someone needs to come in and provide a cheap alternative and eat all the other ISPs lunch.  How can prices be so much less here in the US?  For the same as a basic $250 package for WebInABox, I can get the saem for about $50 here in the US.

there are a limited number of big fat pipes into AU. its these international links to/from our island continent that cost,
plus the established billing structure of providers in AU - if you are on a good thing, why change? :/

there are cheaper hosts, but quality of service generally drops quicker than cost

[gnar1ta$]

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.

[freakfantom]

Please, add an option to convert NMC to BTC.

[Inaba]

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.

[WebMonkey]

busy busy!

=]

'monkey

[Druas]

Are block stats messed up for anyone else?

[Inaba]

Yep, I killed the block stats!

Meni found a bug earlier today in how shares are transferred from block to block with the DGS.  It did/does not affect payout negatively, just the calculation of how many shares you submitted for a given round.  The payment calculation is handled in a different table than the block stats display and I had mistakenly had the SQL taking the last shares submitted from the last block you mined in and putting it in the block stats table, even if you didn't mine in a block - it just kept putting the same number of shares in each subsequent block statistic.

The upshot is that everyone got paid for more shares than they submitted!  Jackpot! (Total overpayment was about 7 BTC across all blocks, so it was a fraction of a BTC per person)

Anyway, the bug is fixed now, or should be, but block stats may or may not display a slightly lower number/prop differential than expected, due to the calculation "missing" the phantom shares.  Going back to fix it would result in people getting a negative balance that I would have to fix manually, so everyone gets free BTC yay!  Your stats will show a lower prop differential boo!  In either case, though, you should be paid properly from now on... no more free rides!

While working on this bug, I also found another bug that was over calculating the amount of shares in a block (by a few tens or hundreds of shares per block) - so they were removed from all blocks as appropriate - our "luck" is actually better than has been reported... luck display should be accurate now.

If you notice something is not correct, let me know and I will look into it right away.

[Druas]

Your stats will show a lower prop differential boo!

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

[worldinacoin]

It is quite normally, nothing ridiculous. This is Australia pricing, you can be sure other parts of the world had similar pricing.  Just a few years ago, my IDC only allow 20 GB/mth traffic per rack and comes at USD$800 with 1.5kVA!

They use WebInABox, which was one of the most ridiculously priced ones I've found.  They want a minimum of $250/mo for a basic dedicated server or a whopping $100/mo for a 1U server with only 5GB of data... it's almost laughable.  The state of Australia ISPs is dismal and I feel sorry for the people forced to go to Australian ISPs for their hosting needs.  I honestly don't see how ozco.in can stay in business at 0% fee... they must be taking a loss of major proportions.

There was and is a reason to host in AU, yes its expensive and thus a US server coming soon
no need to feel sorry for me - I knew what i was getting - been dealing with AU hosts for years :/
WebInABox is run by people I know and have been very good to me

[Inaba]

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 is quite normally, nothing ridiculous. This is Australia pricing, you can be sure other parts of the world had similar pricing.  Just a few years ago, my IDC only allow 20 GB/mth traffic per rack and comes at USD$800 with 1.5kVA!

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.

[WebMonkey]

your full disclosure is threatening my bottom line inaba.....

=]

'monkey

[urstroyer]

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.

Hi Inaba,

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

[Inaba]

Oh, nice... ok, I will see what I can do about integrating that this weekend or early next week.  Thanks for the tip!

[Inaba]

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.

[racerguy]

damn damn damn these rounds from hell!

[organofcorti]

damn damn damn these rounds from hell!

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).

[racerguy]

I thought the stats already told us that?

[urstroyer]

damn damn damn these rounds from hell!

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:

o - Cross-round leakage. Increasing o reduces participants' share-based variance but increases maturity time. When o=0 this becomes the geometric method. When o->1 this becomes a variant of PPLNS, with exponential decay instead of 0-1 cutoff (note that "exponential" does not mean "rapid", the decay can be chosen to be slow). For o=1, c must be 0 and r (defined below) can be chosen freely instead of being given by a formula.

https://bitcointalk.org/index.php?topic=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!

[organofcorti]

damn damn damn these rounds from hell!

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:

o - Cross-round leakage. Increasing o reduces participants' share-based variance but increases maturity time. When o=0 this becomes the geometric method. When o->1 this becomes a variant of PPLNS, with exponential decay instead of 0-1 cutoff (note that "exponential" does not mean "rapid", the decay can be chosen to be slow). For o=1, c must be 0 and r (defined below) can be chosen freely instead of being given by a formula.

https://bitcointalk.org/index.php?topic=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!

Thanks urstroyer - but I was actually after what miner's experiences had been in the short term. In appendix D of Analysis of bitcoin pooled mining reward systems Meni shows how to calculate the variance and maturity time in the DGS payout system, but that doesn't give me the same insight as actual results do.

So I was interested in seeing what recent historical variance results had been after reading a post from someone complaining about a long round - had anyone seen a reduction in variance compared to a proportional payout?