OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[-ck]

As much as I'm not a fan of merged mining, I have to say that's (17.3s) wrong. You get to submit a share not long after it's found by the device. Usually the device is out for 1-2 seconds at most depending on card speed, intensity and number of threads. The most work you will lose is one chunk of work submitted to the GPU during the block change that is done needlessly before the GPU can respond again. At most it will amount to say 1 second of work with average settings per block change. That's a change from 1 second with regular mining to 3 seconds with merged mining over an average 10 minutes.

HOWEVER this is all assuming one longpoll only per block change, and poolserverj with merged mining support can do some amazing shit. I've seen up to 10 longpolls...

[gnar1ta$]

How about I just run a day with merged mining and a day without and compare U? Does U take into account discarded work due to new block - which is LP request?

[-ck]

How about I just run a day with merged mining and a day without and compare U? Does U take into account discarded work due to new block - which is LP request?

Yes, but this assumes luck doesn't change over 24 hours... and it most definitely does so it will be nigh on impossible to prove beyond a shadow of a doubt. Luck of even the biggest pool can be down 40% over 24 hours, and that's over 3 THash of miners.

[SleeperUnit]

Dutch, buddy, can you tell me your cgminer Utility? Preferably a list of values for each miner.
Perhaps the best thing you can do is use an older (unaware of merged-mining and not dropping all work on LPs) release of cgminer or find yourself a pool not doing merged mining.

An quicker and easier test would be to simply disable LP. It'll cause a 2% or so increase in stales but it will provide a big boost to efficiency.

[jake262144]

Another way to look at it is the hypothetical miner above processes 34 shares.  If your analysis was right it would have 1 stale out of 34 even when not merged mining and thus could never have a stale rate of <3%.

I stand corrected. Not thinking straight. Guess it's beddy-bye time after all (check my local time DAT)

[-ck]

Another way to look at it is the hypothetical miner above processes 34 shares.  If your analysis was right it would have 1 stale out of 34 even when not merged mining and thus could never have a stale rate of <3%.

And this is probably the best way to see how much "extra" merged mining is costing you.

In your status line:
SS is Stale Shares discarded (detected and not submitted so don't count as rejects)

This will show you shares that might have otherwise been valid if you were not mining merged. cgminer does not submit them so your stale rate actually will not go up as DeathAndTaxes suggested unless you enable the --submit-stale option. (I don't suggest you do).

[DeathAndTaxes]

This will show you shares that might have otherwise been valid if you were not mining merged. cgminer does not submit them so your stale rate actually will not go up as DeathAndTaxes suggested unless you enable the --submit-stale option. (I don't suggest you do).

Any reason why?

Also background on why I recommend enabling "--submit-stale" for those who may not know is for the following scenario:
1) your find a BTC share
2) the pool detects a change in NMC block and issues an LP
3) if you discard the work you discard a valid BTC share
4) if you submit it you gain a valid share.

now if the LP is because BTC block is invalid then yes you are submitting a stale share but you don't lose anything.  Instead of a SS locally you get a R but it doesn't negatively affect how many valid shares.

[-ck]

4) if you submit it you gain a valid share.

This. It won't be considered valid if I'm not mistaken.

[DeathAndTaxes]

4) if you submit it you gain a valid share.

This. It won't be considered valid if I'm not mistaken.

It depends on the pool.  Some (most?) pools track validity of shares on each chain separately.  I know on Bitminter for example after an LP due to NMC block change the share is still valid for BTC purposes (but not NMC).

A pool could handle multiple chains in three ways
a) only given credit for a share if it is valid for all chains
b) given credit if it is valid for master chain (BTC)
c) track each chain separately and give credit is it is a valid share for that chain (each chain has separate share count).

Slush uses method B.  Bitminter uses method C.  You are correct if the pool uses method A then there is no value in submit-stale option.

[-ck]

Yes siree, I do hate merged mining.

[DeathAndTaxes]

Yes siree, I do hate merged mining.

Yeah it does complicate things BUT I would argue that things are going to get more complicated anyways.  Pools will eventually need to use to provide a mechanism to update miners when transactions change (when fees becoming more importantly).  p2pool needs a method to track when the share chain has changed.  Likely in the future there will be other as of yet implemented events which will require altering the work being done.

Using LP for everything is an ugly hack but it works.  However what all this ugliness is pointing to is the fact that the pool-miner communication protocol needs to be more robust.   Miners today are relatively "dumb" and rely too much on the server.

[gnar1ta$]

Well good since I was using --submit-stale, merged mining, and was completely backwards on scantime, I'll consider that strike 3 for the day and just push the default button on cgminer...too bad --donation isn't default 

[-ck]

Well good since I was using --submit-stale, merged mining, and was completely backwards on scantime, I'll consider that strike 3 for the day and just push the default button on cgminer...too bad --donation isn't default 

Heh, you know I tried to make --donation default but there was outrage and threats of forking cgminer and death threats. All right, perhaps not the last but the others.

[miscreanity]

Heh, you know I tried to make --donation default but there was outrage and threats of forking cgminer and death threats. All right, perhaps not the last but the others.

Set it to 1% in example.conf file with a note to comment it out if donations aren't desired. I hope you're at least getting a reasonable trickle from those who do have it enabled.

[-ck]

Heh, you know I tried to make --donation default but there was outrage and threats of forking cgminer and death threats. All right, perhaps not the last but the others.

Set it to 1% in example.conf file with a note to comment it out if donations aren't desired. I hope you're at least getting a reasonable trickle from those who do have it enabled.

Yes, thanks!  I'm currently getting ~450Mhash of donations. Since my mining rig is still in the workshop, this is actually all the mining I'm doing at the moment 

[Fiyasko]

Heh, you know I tried to make --donation default but there was outrage and threats of forking cgminer and death threats. All right, perhaps not the last but the others.

Set it to 1% in example.conf file with a note to comment it out if donations aren't desired. I hope you're at least getting a reasonable trickle from those who do have it enabled.

Yes, thanks!  I'm currently getting ~450Mhash of donations. Since my mining rig is still in the workshop, this is actually all the mining I'm doing at the moment 

you wantz moar?

[-ck]

I'm currently getting ~450Mhash of donations. Since my mining rig is still in the workshop, this is actually all the mining I'm doing at the moment 

you wantz moar?

From the land of rhetorical questions  But of course, I would never turn them down!

If you want to check out what my donation rate is, simply drop into irc.freenode.net #ozcoin

Here is the way to test it, and the current returned value (it fluctuates a lot):
<conman> !worker ckolivas.donation
<ozco> Worker ckolivas.donation hashrate is 401 is active: yes and is being monitored: no

[kano]

Yes siree, I do hate merged mining.

Yeah it does complicate things BUT I would argue that things are going to get more complicated anyways.  Pools will eventually need to use to provide a mechanism to update miners when transactions change (when fees becoming more importantly).  p2pool needs a method to track when the share chain has changed.  Likely in the future there will be other as of yet implemented events which will require altering the work being done.

Using LP for everything is an ugly hack but it works.  However what all this ugliness is pointing to is the fact that the pool-miner communication protocol needs to be more robust.   Miners today are relatively "dumb" and rely too much on the server.

Actually, to correct that statement ...
There is no proper protocol definition, however some before have mentioned deepbit's web page where they have 'a' definition.
And that definition is the problem - it's next to useless.
It needs to be designed (not hacked), then standardised and then placed/updated in the wiki.
I still do not understand why it is true that a very high % of miners use pools but the wiki is useless in defining the pool protocol.
(damn I need to hurry up and find the time to get around to writing my own and testing/implementing it ...)

[-ck]

you wantz moar?

Ohhh now I see it in my wallet instead, lol. Thanks!

[P4man]

Heh, you know I tried to make --donation default but there was outrage and threats of forking cgminer and death threats. All right, perhaps not the last but the others.

I say, let them be outraged and threaten. No one is forcing them to use cgminer, no one preventing them from disabling the option. And if someone wants to fork, again, let them. Why would anyone switch to a poorly supported fork which only advantage is that you dont have to change a default setting (assuming you wouldnt want to donate) ?

FWIW, when I first tried cgminer, I wasnt opposed to donating but confused how it worked. I didnt look in to it, and kept it disabled. I bet there are lots people like that.