akashamar (OP)
Newbie
Offline
Activity: 38
Merit: 0
|
|
June 14, 2015, 09:44:06 PM |
|
Today we've seen another diff adjustment. I've gathered and summarized payments so far and compared them to theoretical ideal earnings considering diff in previous periods: first period up to May 17 2015: (0.0105558 diff*1.33 Th/s*12 days=0.168470568 BTC) second period from May 17 2015 up to May 31 2015: (0.01030404diff*1.33 Th/s*14 days=0.191861225 BTC) third period: (0.01056774diff*1.33 Th/s*14 days=0.196771319 BTC) http://www.poolpayouts.com/after_june_14th_difficulty_change.pngWoha, kano and AntPool are above 100% luck (must have been some very good luck at those two pools recently) and NiceHash is almost at 100% of theoretical ideal payouts. BTCGuild is paying extremely low. Is anyone else observing such low payouts from BTCGuild lately?
|
|
|
|
kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
June 15, 2015, 01:25:08 AM |
|
For kano.is it's just luck Be it high or low. At this point the luck has been even higher than that since you'll get decreasing payouts (currently) for a couple of weeks after you stop mining. The pool pays 99.1% of 25 + txns fees (so about 99.5%) less orphans (which has been ~0.8% so far) So the long term expected average would currently be 98.7% Any short term mining will of course be mostly affected by luck.
|
|
|
|
p3yot33at3r
|
|
June 16, 2015, 11:54:31 AM |
|
Thought I'd add some p2pool stats, seeing as you've forgotten to mention it in your "observations" P2pool 30 day luck: 127.35%Source: http://minefast.coincadence.com/p2pool-stats.phpThis is not including payments from the 10 extra merge-mined coins of course Tak.
|
|
|
|
jonnybravo0311
Legendary
Offline
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
|
|
June 16, 2015, 05:54:53 PM |
|
Thought I'd add some p2pool stats, seeing as you've forgotten to mention it in your "observations" P2pool 30 day luck: 127.35%Source: http://minefast.coincadence.com/p2pool-stats.phpThis is not including payments from the 10 extra merge-mined coins of course Tak. Not so much forgotten as not included in the tests. OP chose the pools he wanted to test and p2pool wasn't one of them. I invited OP to use the data I have been recording as part of my tests on OgNasty's Nasty Pool. You can see the long-running results of that test here: https://bitcointalk.org/index.php?topic=891298.0The summary is that my S3 running on the standard p2pool payouts has earned 99.36% of expectations (test started 12/26/2014).
|
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
akashamar (OP)
Newbie
Offline
Activity: 38
Merit: 0
|
|
June 16, 2015, 08:52:01 PM |
|
Results after 6 weeks of uninterrupted mining are online, here is also the graph: http://www.poolpayouts.com/after_week_006_normalized_graph.pngAntpool, NiceHash and kano have cumulative top payouts and are more or less on pair, with almost 100% payouts compared to theoretical payouts. BTC Guild is still very low, also, they announced that BTC Guild is shutting down (maybe the recent bad luck is also one of the reasons). I'll keep hashing on this pool until June 30th, then I'll collect the final results of this pool and remove BTC Guild from experiment. I feel a bit sorry that I haven't included p2pool instead BTC Guild, but now I can't change this anymore. Maybe I'll start another parallel experiment with p2pool and some other pools with additional miners in the future.
|
|
|
|
akashamar (OP)
Newbie
Offline
Activity: 38
Merit: 0
|
|
June 24, 2015, 02:20:50 PM |
|
Results after 7 weeks of uninterrupted mining are online, here is also the graph: http://www.poolpayouts.com/after_week_007_normalized_graph.pngAntpool and NiceHash are more or less on pair, kano is still having good luck and all top three are paying around 100% compared to theoretical payouts. WARNING!!! This is the last time that BTC Guild is included, since it is shutting down on July 30th 2015 I'll no longer include BTC Guild in my future experiment.
|
|
|
|
|
macbook-air
|
|
June 30, 2015, 07:22:34 PM |
|
Here are results at the diff change on June 28th with combined total payouts after 2 moths (minus 2 days): And resutls of 8 weeks (two months of uninterrupted mining) are online, here is also the graph: What we learned so far is that antpool and kano are doing well with PPLNS. f2pool suffers with high 4% fees and distance to china (rejects), while nicehash is doing well regardless of 3% fee since it provides above 100% payments in particular periods. You count merged mining payout?
|
|
|
|
akashamar (OP)
Newbie
Offline
Activity: 38
Merit: 0
|
|
June 30, 2015, 07:46:12 PM |
|
You count merged mining payout?
No, only Bitcoin payout ... it would be additional work to exchange merge-mined altcoins to Bitcoins and the value would be most probably negligible.
|
|
|
|
opentoe
Legendary
Offline
Activity: 1274
Merit: 1000
Personal text my ass....
|
|
July 04, 2015, 02:27:44 PM |
|
kano, thanks for your feedback. Yes, my goal is to run this experiment on a long-run basis (several months). My intention is not to compare PPS/PPLNS, but primary to give insight into how payments are delivered to users when mining on various pools. And also the obvious difference between various pools performance (related to pool's location, software used, etc.). Me, as well as many other users, too, are looking to get as much as possible profit out as mining. And since mining is not as profitable as it was a year ago, a 5% can make a difference. In an ideal world it should be essentially the same on which pool one is mining. I'd like to see if my experiment can prove or deny this ... we'll see in few months.
Keep doing it and get as much information as you can. Pool operators hate transparency and easy to read stats. Keep trucking.
|
|
|
|
jonnybravo0311
Legendary
Offline
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
|
|
July 04, 2015, 02:32:40 PM |
|
You count merged mining payout?
No, only Bitcoin payout ... it would be additional work to exchange merge-mined altcoins to Bitcoins and the value would be most probably negligible. The reason that question was asked was because they claim those merge mined coins given to you will make up for the fees they charge you. I'm in full agreement with you, though. The hassle of dealing with all of those alt coins and trading them on the exchanges, then paying any potential fees on the exchanges for the trades and moving BTC is just not worth the meager returns you might get from them. EDIT: full disclosure, I run my own p2pool node and I used to merge mine every coin I could. Now the only alt coin daemon still running on my node is NMC. I've only ever found a couple blocks, and when I did, I donated the BTC I made back to p2pool miners. That NMC daemon is probably not going to be running on my node very much longer. At 25 NMC per block and current exchange rates, finding a block will net me about 0.07 BTC.
|
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
kano
Legendary
Offline
Activity: 4620
Merit: 1851
Linux since 1997 RedHat 4
|
|
July 04, 2015, 02:57:00 PM |
|
Also with pools that do merge mine you could get a higher payout if they didn't ...
No merge mining pool actually goes to the trouble of determining the actual BTC value of merged mining and the expected loss due to it ... I wonder why ...
There is also the issue of the affect on the pool software itself due to the secondary crappy altcoind's that must run on the pool and the affect on stale work that NO pool has ever reported any stats about ... Also some pools/proxies really screw up the miners by sending altcoin block change notifications that increase stale shares quite a lot ...
I've run stale block stats on my pure bitcoin pool and it wins hands down against Eligius (>90% block changes are faster on my pool vs Eligius giving almost 1% higher stale block work rate on Eligius) They merge mine NMC ... and have pretty bad long term luck stats ... Some have argued that was due to block withholding ... but since the Eligius pool operators are not affected by block withholding but their payout scheme is pretty good for someone who block withholds ... that could also be part of the cause of the bad luck history ...
|
|
|
|
p3yot33at3r
|
|
July 04, 2015, 05:20:32 PM |
|
There is also the issue of the affect on the pool software itself due to the secondary crappy altcoind's that must run on the pool and the affect on stale work that
For me, merge mining with p2pool has proven to be not just a great way to learn about mining in general, but also helped me get into Linux (I read one of your guides kano, setting up on Xubuntu 10.04 I think it was - very helpful btw). I haven't found that having more altcoind's running on my rig has affected it's results in any way, they seem very similar to when I was only mining using the bitcoind (which uses the most resources). For example, my rig is using an old unlocked Phenom, 16GB RAM with two seperate SSD's - one for the system & one for the coind data. It's currently running 12 coin daemons, 11 of which are being merge mined with p2pool - I tried to get a snapshot of all the coin daemons, but ran out of patience...... : All those altdaemons are using hardly anything, my efficiency very rarely goes below 105% (currently 115%), my DOA rate sits at around 2% & my latency is constantly around the 0.3s mark (currently 0.354s) - which, considering that I'm on a crappy 3mb ADSL line using old, second hand parts (apart from the SSD's - I got quality ones as I thought it was important to have them) is quite amazing IMHO. The way I see it, if the rig is going to be on 24/7 anyway, why not mine as many coins as I can? Performance is virtually unaffected. No, they are not worth much, but I now earn an extra 10 x more of a little compared to 10 x nothing without having to do anything at all, set it & forget it. Plus of course, merge mining gives those altcoins added network security/stability. I know there are BTC diehards out there who don't agree with all these altcoins & I would completely agree with them, most of the bazzilions of altcoins are shite - but with the costs of mining constantly rising & the rewards for the home miner constantly falling, one has to make the most of the resources he/she has available to offset costs, & merge mining enables me to do that. I'm of the opinion that if I can break even I've done well, anything extra is a bonus & I've helped Bitcoin (other altcoins) gain a foothold. I spent many, many days reading up on what my best options were until my eyes bled, & for me there was no doubt in my mind that merge mining using p2pool was my best option by far. It doesn't suit everyone of course, but I'm glad I chose it. Let's face it, the days of home mining & making a profit ended long ago (I missed that boat), this is more of a hobby for me - a very interesting & fun one that I glad I decided to take up. I do use your pool as a backup though kano........ I'm a bit of a noob to mining & Linux, so if I've made any incorrect statements - feel free to harass & scold me
|
|
|
|
eleuthria
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
July 04, 2015, 05:40:00 PM |
|
I'm a bit of a noob to mining & Linux, so if I've made any incorrect statements - feel free to harass & scold me Coin daemons use very little CPU for the majority of the time. The issue is when a new block hits it causes a significant spike in CPU, disk, and network activity. If multiple daemons hit blocks at the same time (which is common with merged minable coins), it means you will have other processes competing with bitcoind for CPU/disk/network resources during the block verification/relay period. If you want to merge mine coins without impacting BTC performance, put the altcoins on a separate system, so that they are never utilizing the same CPU/disk as your bitcoin daemon. Additionally, at least in the case of pools, you should never spend any time waiting for an altcoin daemon when a new block hits. Assemble a new BTC block with the MM information in the coinbase and push it out. Most of the time this will push out work with the new altcoin block as well, since most altcoins are virtually unused so there is very little time involved in verifying a new block. If the new block for bitcoind and the altcoin chain arrived at the same time, you will almost always have the altcoin verified before bitcoind is done. If it doesn't, you're not losing anything significant, just catch up to the newest altcoin block the next time you do a work push.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
p3yot33at3r
|
|
July 04, 2015, 05:56:01 PM |
|
Coin daemons use very little CPU for the majority of the time. The issue is when a new block hits it causes a significant spike in CPU, disk, and network activity. If multiple daemons hit blocks at the same time (which is common with merged minable coins), it means you will have other processes competing with bitcoind for CPU/disk/network resources during the block verification/relay period.
If you want to merge mine coins without impacting BTC performance, put the altcoins on a separate system, so that they are never utilizing the same CPU/disk as your bitcoin daemon. Additionally, at least in the case of pools, you should never spend any time waiting for an altcoin daemon when a new block hits. Assemble a new BTC block with the MM information in the coinbase and push it out. Most of the time this will push out work with the new altcoin block as well, since most altcoins are virtually unused so there is very little time involved in verifying a new block. If the new block for bitcoind and the altcoin chain arrived at the same time, you will almost always have the altcoin verified before bitcoind is done. If it doesn't, you're not losing anything significant, just catch up to the newest altcoin block the next time you do a work push.
Hi eleuthria, Thanks for that input - very interesting. I did notice the spikes you refer to a while ago, so decided to use the niceness option on bitcoind to give it maximum priority, which seems to have helped a little. The biggest performance increase I got was from putting the data directories on a separate, larger SSD - but I don't think it would be worth my while splashing out on more hardware for the daemons to run on - it's a private node after all, to play with..... Even though my setup is a simple home thing, it's interesting to fiddle around trying to find the best settings. When you refer to "Assemble a new BTC block with the MM information in the coinbase and push it out." - how does one do that with p2pool? Or is it even possible? Really appreciate your input eleuthria - thanks
|
|
|
|
eleuthria
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
July 04, 2015, 07:25:14 PM |
|
When you refer to "Assemble a new BTC block with the MM information in the coinbase and push it out." - how does one do that with p2pool? Or is it even possible?
Can't help on this one unfortunately, I've never used p2pool so I don't have any idea how it assembles work, same with merged mining via p2pool. Different drives for the coins is definitely one good way to split the load when new blocks hit though.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
p3yot33at3r
|
|
July 04, 2015, 10:15:07 PM |
|
When you refer to "Assemble a new BTC block with the MM information in the coinbase and push it out." - how does one do that with p2pool? Or is it even possible?
Can't help on this one unfortunately, I've never used p2pool so I don't have any idea how it assembles work, same with merged mining via p2pool. Different drives for the coins is definitely one good way to split the load when new blocks hit though. Thanks man - I'll ask in the p2pool thread
|
|
|
|
sloopy
|
|
July 11, 2015, 07:15:51 PM |
|
Also with pools that do merge mine you could get a higher payout if they didn't ...
No merge mining pool actually goes to the trouble of determining the actual BTC value of merged mining and the expected loss due to it ... I wonder why ...
There is also the issue of the affect on the pool software itself due to the secondary crappy altcoind's that must run on the pool and the affect on stale work that NO pool has ever reported any stats about ... Also some pools/proxies really screw up the miners by sending altcoin block change notifications that increase stale shares quite a lot ...
I've run stale block stats on my pure bitcoin pool and it wins hands down against Eligius (>90% block changes are faster on my pool vs Eligius giving almost 1% higher stale block work rate on Eligius) They merge mine NMC ... and have pretty bad long term luck stats ... Some have argued that was due to block withholding ... but since the Eligius pool operators are not affected by block withholding but their payout scheme is pretty good for someone who block withholds ... that could also be part of the cause of the bad luck history ...
I am extremely interested in merge mining, but I am torn for various reasons. One being the simple fact you and CK seem to be so adamantly against it. If you have time I would appreciate more information from you about this and how it relates to what the OP is attempting to show through his experiences. Regarding the previous comments on running the mm coins on a different system, does that satisfy your concern with it having an impact on bitcoin rewards? To be more specific, say on your pool, kano.is, you have hardware in terms of computing hardware at your disposal to put whatever mm coin software and anything else needed on other "servers" are there other reasons this would impact bitcoin payouts on kano.is? I am sincerely uninterested in Elgius (mainly due to the involvmenet of Lukejr) and understand your examples are to educate the community not just for my benefit, but in my example I am using kano.is as you have control over everything and I am curious as to what other aspects can impact my payouts from a pool which uses mm. I do not think anyone can predict the future profitability of the coins available to be merge mined, and it is obviously interesting to many miners because it is presented as 'free coins'. I do not have enough hashrate and time to mine at various multipools to determine for myself if my end of the month / year, etc payouts would be advantageous. I do not believe anything is free, but I do believe it is possible a pool operator would take on additional hardware expense to entice more miners to use their pool. I think another thing which may impact the actions of some pool operators is the philosophical view of 'alt' coins. I think both Kano and CK are against the support of anything but bitcoin? Please correct my statement if it is out of order, but my understanding is you both feel any support of an alternative coin community detracts from the bitcoin community. In no way am I suggesting this would impact your technical opinion of the ability to merge mine. I have no doubt you would fairly assess the scenario and provide an impartial analysis but I feel like there must be a disclaimer of sorts to make sure we are on the same page regarding such. Obviously I think there is plenty of room for other currencies and in fact a need for some small number, but that debate is not what I am after. I probably could have simply asked, in your opinion if you wanted to merge mine what would it take to do so without impacting your bitcoin mining payments on kano.is?
|
Transaction fees go to the pools and the pools decide to pay them to the miners. Anything else, including off-chain solutions are stealing and not the way Bitcoin was intended to function. Make the block size set by the pool. Pool = miners and they get the choice.
|
|
|
akashamar (OP)
Newbie
Offline
Activity: 38
Merit: 0
|
|
July 22, 2015, 10:22:20 AM |
|
Resutls of 12 weeks are online, here is also the graph: http://www.poolpayouts.com/after_week_012_normalized_graph.pngf2pool is slowly lagging behind in terms of payouts (china location with rejects and high fees), antpool and nicehash are more or less on pair with around 100% payouts, while kano is still riding good luck with >100% of theoretical payouts.
|
|
|
|
Mikestang
Legendary
Offline
Activity: 1274
Merit: 1000
|
|
November 02, 2015, 10:17:40 PM |
|
Are you still conducting this experiment and recording data? I expect you to be on/around week 20, but nothing has been reported since week 12. Thanks, very interesting study.
|
|
|
|
|