I think something might be wrong with the merged mining.
Our "luck" has been incredibly bad soo bad I think there may be some sort of a bug. I don't blame Dr.Haribo as merged mining is fraked. The protocol is poorly documented and it is very easy to create subtle bugs.
Still the difficulty for NMC is only 200,000 (roughly 8x easier) than BTC. By my math (which may be wrong) we are at the 99.995% pertcentile (CDF) in the current block for NMC.
More simplistically since starting merged mining we have completed roughly 1.8M shares and found 2 NMC blocks. The average/expected gain would be 9 blocks. Now there is always variance but either we are incredibly unlucky not just in this block but since starting merged mining or there is some sort of bug.
Topic: [1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff] - page 350. (Read 837101 times)
November 05, 2011, 07:11:45 PM
November 05, 2011, 06:57:35 PM
Right now there is a command line option which will force cgminer to submit all completed shares regardless of it if thinks they are stale. Of course that puts more work load on the server. Hopefully the next version of cgminer will strike a better balance.
Yes, it puts a little more load on the server. But for creating the most blocks this is the best option.
The miner has no idea how many chains you are merged mining on the server. It doesn't know whether its proof of work is stale or valid for those chains. And it doesn't know if it passes the difficulty of those chains either. Best it can do is just send in every proof of work.
This will make the number of rejected proofs of work go up on both client and server. So it won't look so pretty. But it's the best option for creating the most blocks.
If anyone is interested the option in cgminer is "--submit-stale".
Some/most of the SS actually are stale so they will become R. Hopefully some of the SS are usable by the pool and thus become A. So one would expect to see both R & A numbers rise and DW numbers to go to zero. Personally I haven't used it because the number of SS tend to be very low anyways (really would only occur on a NMC block change that isn't a BTC block change and before the next getwork() which is a really small window).
November 05, 2011, 06:52:54 PM
Right now there is a command line option which will force cgminer to submit all completed shares regardless of it if thinks they are stale. Of course that puts more work load on the server. Hopefully the next version of cgminer will strike a better balance.
Yes, it puts a little more load on the server. But for creating the most blocks this is the best option.
The miner has no idea how many chains you are merged mining on the server. It doesn't know whether its proof of work is stale or valid for those chains. And it doesn't know if it passes the difficulty of those chains either. Best it can do is just send in every proof of work.
This will make the number of rejected proofs of work go up on both client and server. So it won't look so pretty. But it's the best option for creating the most blocks.
November 05, 2011, 06:25:48 PM
SS is Stale Shares discarded (work completed but not submitted because already stale - just as bad as rejected)
When merged mining this is a bad idea. The proof of work may not be valid on the bitcoin chain, but it could still be valid on the namecoin chain. One might potentially throw away a proof of work that would have been able to create a namecoin block.
By the way, it is now possible to enter an NMC cash out address on the website and collect your namecoins. More website updates coming soon.
Some of us have pointed this out and the author is working on an updated version of cgminer which doesn't assume blocks are stale unless it receives an LP.
Right now there is a command line option which will force cgminer to submit all completed shares regardless of it if thinks they are stale. Of course that puts more work load on the server. Hopefully the next version of cgminer will strike a better balance.
November 05, 2011, 06:12:01 PM
SS is Stale Shares discarded (work completed but not submitted because already stale - just as bad as rejected)
When merged mining this is a bad idea. The proof of work may not be valid on the bitcoin chain, but it could still be valid on the namecoin chain. One might potentially throw away a proof of work that would have been able to create a namecoin block.
By the way, it is now possible to enter an NMC cash out address on the website and collect your namecoins. More website updates coming soon.
November 05, 2011, 03:18:45 PM
30 shares per minute is 2.14GH/s effective. Actually I double checked and for last 48 hour it was closer to 32 shares per minute. Remember no card is 100% efficiency (stales, delayed work, downtime, card throttling, etc). U is your actual useful work so that is pretty decent.
I have found that the speed that produce ~2.3GH/s tend to work the best for me. Clocking higher nets me more shares but then when a rig locks up (even if only once a week) the downtime erases any gains. Likely if I wanted to keep a closer eye on the rigs I could another 10% more out of them.
I have found that the speed that produce ~2.3GH/s tend to work the best for me. Clocking higher nets me more shares but then when a rig locks up (even if only once a week) the downtime erases any gains. Likely if I wanted to keep a closer eye on the rigs I could another 10% more out of them.
November 05, 2011, 03:10:45 PM
Looking back in my long rambling answer I noticed I never answered the direct question "where did the other shares go".
They were discarded BEFORE working. cgminer records that as DW
They were discarded BEFORE working. cgminer records that as DW
I figured that much, but thanks for the long answer
Quote
I find the most useful metric is U (Utility. How many ACCEPTED shares per minute do I generate). A high U(tility) means high revenue. U is subject to variance so I really only look at it after cgminer has been running for 4 hours+.
With my 3x5970 rigs I try to maintain ~30 shares/min. Man I thought this one was going to be short ... failed again.
With my 3x5970 rigs I try to maintain ~30 shares/min. Man I thought this one was going to be short ... failed again.
You're such a fountain of wisdom! That was the one question lingering in my mind, what that "u" meant exactly. Intuition told me it was a good proxy for performance.
BTW, 30 shares per minute, so 5 per gpu ? Seems lowish to me. Have you underclocked and undervolted those 5970s? Thing is, Im getting exactly 5 share per minute per core on average with my considerably cheaper (*) GPU cores (and not even seriously overclocked due to linux limitations).
(*) okay, they would have been cheaper if I wasnt so anal about keeping temps low. If I factor in the cost of that spitfire and the other coolers, its not that cheap anymore, but the ease of mind that 46C peak temperature on the 5870 @ 900 MHz gives me is priceless
. November 05, 2011, 02:47:15 PM
Looking back in my long rambling answer I noticed I never answered the direct question "where did the other shares go".
They were discarded BEFORE working. cgminer records that as DW
cgminer is a little more advanced that other miners once you request a getwork() it can end one of four places:
A is Accepted Share (what we want. Work submitted and credit given by pool)
R is Rejected Share (Work submitted but rejected by pool)
SS is Stale Shares discarded (work completed but not submitted because already stale - just as bad as rejected)
DW is Discarded Work items (discard work because it went stale before work began - puts more loan on server but no GPU time is wasted)
Often people look only at R but cgminer doesn't submit work it knows is stale so really you should look at R + SS both are work you did and won't get credit for.
I find the most useful metric is U (Utility. How many ACCEPTED shares per minute do I generate). A high U(tility) means high revenue. U is subject to variance so I really only look at it after cgminer has been running for 4 hours+.
With my 3x5970 rigs I try to maintain ~30 shares/min. Man I thought this one was going to be short ... failed again.
They were discarded BEFORE working. cgminer records that as DW
cgminer is a little more advanced that other miners once you request a getwork() it can end one of four places:
A is Accepted Share (what we want. Work submitted and credit given by pool)
R is Rejected Share (Work submitted but rejected by pool)
SS is Stale Shares discarded (work completed but not submitted because already stale - just as bad as rejected)
DW is Discarded Work items (discard work because it went stale before work began - puts more loan on server but no GPU time is wasted)
Often people look only at R but cgminer doesn't submit work it knows is stale so really you should look at R + SS both are work you did and won't get credit for.
I find the most useful metric is U (Utility. How many ACCEPTED shares per minute do I generate). A high U(tility) means high revenue. U is subject to variance so I really only look at it after cgminer has been running for 4 hours+.
With my 3x5970 rigs I try to maintain ~30 shares/min. Man I thought this one was going to be short ... failed again.
November 05, 2011, 02:21:57 PM
Allright, thanks for clearing that up!
November 05, 2011, 02:03:54 PM
Question about efficiency/stales.
Have a look at this screenshot:
http://s9.postimage.org/8lnn9wer3/Untitled.png
The top window is my dedicated mining rig, its using linux and with a 5870+5850. It achieves 94% efficiency, where efficiency is calculated by cgminer apparently by dividing queued shares (Q) by accepted shares (A).
Then check the bottom window, its my everyday PC, running windows atm, with a 5850. Its only getting 79% efficiency. Since the number of rejected shares (R) is low on both, there are no hardware errors (HW), Im confused. Whats happening with the other shares? Why is this machine so much less "efficient"?
Have a look at this screenshot:
http://s9.postimage.org/8lnn9wer3/Untitled.png
The top window is my dedicated mining rig, its using linux and with a 5870+5850. It achieves 94% efficiency, where efficiency is calculated by cgminer apparently by dividing queued shares (Q) by accepted shares (A).
Then check the bottom window, its my everyday PC, running windows atm, with a 5850. Its only getting 79% efficiency. Since the number of rejected shares (R) is low on both, there are no hardware errors (HW), Im confused. Whats happening with the other shares? Why is this machine so much less "efficient"?
Efficiency doesn't mean you are losing anything it simply means the bottom miner is requesting more work than it can accomplish. Smaller rigs tend to be less efficient (especially w/ cgminer which pre-requests work to keep the queue full). 79% is pretty low but I haven't ever run a single card rig so it might not be that abnormal.
As a miner you lose nothing by having low efficiency. A pool operator would be more concerned with efficiency because it determines how many getworks are required to generate a give number of shares. Not sure if BitMinter implement s NTimeRolling. If it doesn't and that is added it would improve the efficiency.
TL/DR version: efficiency is only a measure of server-miner communication efficiency. 100% = 1 getwork = 1 share.
November 05, 2011, 01:55:31 PM
Question about efficiency/stales.
Have a look at this screenshot:
http://s9.postimage.org/8lnn9wer3/Untitled.png
The top window is my dedicated mining rig, its using linux and with a 5870+5850. It achieves 94% efficiency, where efficiency is calculated by cgminer apparently by dividing queued shares (Q) by accepted shares (A).
Then check the bottom window, its my everyday PC, running windows atm, with a 5850. Its only getting 79% efficiency. Since the number of rejected shares (R) is low on both, there are no hardware errors (HW), Im confused. Whats happening with the other shares? Why is this machine so much less "efficient"?
Have a look at this screenshot:
http://s9.postimage.org/8lnn9wer3/Untitled.png
The top window is my dedicated mining rig, its using linux and with a 5870+5850. It achieves 94% efficiency, where efficiency is calculated by cgminer apparently by dividing queued shares (Q) by accepted shares (A).
Then check the bottom window, its my everyday PC, running windows atm, with a 5850. Its only getting 79% efficiency. Since the number of rejected shares (R) is low on both, there are no hardware errors (HW), Im confused. Whats happening with the other shares? Why is this machine so much less "efficient"?
November 05, 2011, 11:23:35 AM
Okay here is one without promotion and mentioning merge mining; just quick and dirty:
http://s4.postimage.org/cg1cvksu5/bitminter_generic_speedo.png
http://s4.postimage.org/cg1cvksu5/bitminter_generic_speedo.png
November 05, 2011, 11:14:01 AM
One block to go.
I'm going to pay 5% extra per BTC block until we have 60 BTC blocks. So 3 blocks to go as I write this.
I think it would be sneaky for me to switch the promotion from BTC to NMC. NMC is very low value compared to BTC. I just need to update the website to say 60 BTC blocks instead of simply "60 blocks".
I wasnt sure when Haribo would be done with the dynamic banners, but let me post an interim static one without the promotion and Ill add merged mining. Must also update my own hash rate :p. Consider it done when I get home in a few hours.
Sounds great! I just need to update some things on the website to reflect the changes from merged mining. After that it is banners, and then some updates for the client (miner).
November 05, 2011, 10:55:04 AM
One block to go. Does anyone have updated banners which don't mention 150 free BTC (possibly adding "merged mining").
Ah good point. I wasnt sure when Haribo would be done with the dynamic banners, but let me post an interim static one without the promotion and Ill add merged mining. Must also update my own hash rate :p. Consider it done when I get home in a few hours.
Edit: forgot I had uploaded the templates to ubuntu one cloud, so here you are:
edit: hang on, typo in there
November 05, 2011, 10:49:04 AM
One block to go. Does anyone have updated banners which don't mention 150 free BTC (possibly adding "merged mining").
I would offer to make one but my art skills are so bad it likely would drive traffic away.
I would offer to make one but my art skills are so bad it likely would drive traffic away.
November 05, 2011, 03:38:28 AM
60th block is almost upon us though. Not that I have intentions of switching after the promotion runs out, the pool works great, fees are low and I like mining for a smaller pool; its good for bitcoin and it makes things just a tad more exciting
I could not have said it better I like the pool and the admin does whatever he can to make it good and smooth for all to use.
[ greedy mode on ]
So this far its the one i like the most and the bonus well, more more more xD
[ greedy mode off ]
November 04, 2011, 06:09:22 PM
True words. DrHaribo does a good job. Hope to add my FPGA to the pool soon *dream*
November 04, 2011, 05:43:05 PM
60th block is almost upon us though. Not that I have intentions of switching after the promotion runs out, the pool works great, fees are low and I like mining for a smaller pool; its good for bitcoin and it makes things just a tad more exciting
November 04, 2011, 05:23:10 PM
wohoo! me = jay9228
guess its time to get a namecoin client installed then eh?
guess its time to get a namecoin client installed then eh?
Well the pool has nowhere to setup withdraw of NMC so you got a little time. Still under optimal conditions NMC may be worth up to 8% of your BTC earnings. 8% NMC "bonus" plus 5% "pool bonus. Pretty sweet to get up to 13% extra (plus fees) compared to other pools.
November 04, 2011, 05:16:39 PM
Not necessarily, if you're just going to go off and trade them, just set it to where you're trading
Wouldnt hurry though. NMCs are trading for .. not very much. Barely covers the transaction fees to send them anywhere
Suggestion for DrHaribo; provide an option to donate the NMCs. Or just post your NMC address.
Jump to: