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

[jamesg]

I haven't decided what to do with the efficiency metric. Either I'll make up something or just not use it.

Is the efficiency metric still important with variable diff shares? I'm sitting at 62% currently.

[1714021464]

1714021464

[1714021464]

1714021464

[Roy Badami]

You have the template for the pools block, not a solo block... so it has to be submitted through the pool to be a valid block, otherwise the key won't match the template.

Makes sense, so to be much more specific, what the pool has that the miner doesn't is the pool's private key for the address being generated against, correct?

I think this is how it works:

In order to submit the block solo, you'd have to change the address to which the block reward is payable to be one that you control.  And you'd have to do this before solving the block, otherwise you'd change the hash.  A pool operator obviously isn't going to accept a share where you've modified the coinbase transaction to change the address the block reward is paid to - so your shares would simply be rejected.

Yes, it's true that the one thing the pool operator knows but you don't is the private key of the address that the block reward is payable to - but that's really answering a different question, namely: "why can't you spend someone else's coins?"

roy

[The00Dustin]

I think this is how it works:

In order to submit the block solo, you'd have to change the address to which the block reward is payable to be one that you control.  And you'd have to do this before solving the block, otherwise you'd change the hash.  A pool operator obviously isn't going to accept a share where you've modified the coinbase transaction to change the address the block reward is paid to - so your shares would simply be rejected.

I had to think about it for a few seconds, but that makes sense, even if you can change the address in the template, once you do, you are solo mining, and if you don't, the block can't pay you.  Even simpler.

[kano]

I haven't decided what to do with the efficiency metric. Either I'll make up something or just not use it.

Is the efficiency metric still important with variable diff shares? I'm sitting at 62% currently.

Yes but as I said on the previous page - the variable diff version of that can be calculated in the API
However ...
You can also find the two numbers on the screen with: P I n Enter (where n is the pool number)
So from there divide "Accepted difficulty shares:" / "Getworks"

[jamesg]

Is there a particular reason the var diff server tries to keep shares submission to 12 per minute? With diff 1 shares, as your hash rate increases your variance goes down but this is not the case with 12 shares per minute rule. Can this be set to 20? A share submission target of once every 3 seconds?

[Inaba]

Sure, I've chosen the values arbitrarily at this point, because I wasn't sure what optimal values would be. 

Why do you choose 20, just out of curiosity?  I chose 8 at first, but that seemed to really crank the difficulty, then 12... we can move to 20 and see how that plays out.

[P_Shep]

Sure, I've chosen the values arbitrarily at this point, because I wasn't sure what optimal values would be. 

Why do you choose 20, just out of curiosity?  I chose 8 at first, but that seemed to really crank the difficulty, then 12... we can move to 20 and see how that plays out.

You should find the difficulty which lowers the traffic to a minimum, whilst also minimising stales and maximizing hashrate (obvioulsy).
So pick a value to start with, then vary that (up and down) to minimise GW/m + shares/m.
The whole point of this Vardiff, is afterall, to minimise traffic.

Have a play, build a table, see what results you get.

[jamesg]

Sure, I've chosen the values arbitrarily at this point, because I wasn't sure what optimal values would be. 

Why do you choose 20, just out of curiosity?  I chose 8 at first, but that seemed to really crank the difficulty, then 12... we can move to 20 and see how that plays out.

20 would allow for larger miners to have less variance in share submission which is usually the reward for have a larger hash rate at Diff 1. For 1Gh/s, share submission should be around 13.85 shares per minute. By having a number higher than 13.85, it still allows larger miners to have slightly less share variance while still limiting the overall pool resources the large miners are taking up.

[Inaba]

Ok, here's the config now:

US1: 12 getworks per minute target
US2: 16 getworks per minute target
US3: 20 getworks per minute target

See which one works best for you.

[jamesg]

Ok, here's the config now:

US1: 12 getworks per minute target
US2: 16 getworks per minute target
US3: 20 getworks per minute target

See which one works best for you.

So, mining with 1 5970 and 2 BFL mini rigs the results are:

US1 @ 12 getworks == diff between 50 and 75
US2 @ 16 getworks == diff between 40 and 50
US3 @ 20 getworks == diff between 30 and 40

I am really liking US3 with almost 1/2 the diff of US1. This has definitely helped bring share variance down and the swings in the diff changes as the server re-targets the diff.

[Inaba]

I can readjust all servers to different amounts as well if we want to try that.  It's also possible to leave servers at different difficulties for whatever people feel most comfortable with. 

Do you see any value of going to 24 or higher to test?  My only concern with higher GW/m rate is that when the system gets slammed with 20 TH/s, it starts to overload the back end, but in all honesty, the back end is pretty robust at this point and can handle around 5 TH/s per server at diff1, if not more. 

[jamesg]

I can readjust all servers to different amounts as well if we want to try that.  It's also possible to leave servers at different difficulties for whatever people feel most comfortable with. 

Do you see any value of going to 24 or higher to test?  My only concern with higher GW/m rate is that when the system gets slammed with 20 TH/s, it starts to overload the back end, but in all honesty, the back end is pretty robust at this point and can handle around 5 TH/s per server at diff1, if not more.

You might want to keep a minimum diff for each user mining so that once they start mining for the first time, the system will remember a minimum difficulty for that particular miner. That way, if someone with 10Th/s hops on and off the server, they don't start with diff 1 shares everytime.

Just my two bitcents. 

[420]

Anyone else have a problem connecting to account? I do. can login but worker not working when was working yesterday

[Inaba]

US2 is having some trouble, I am investigating it now. 

[420]

US2 is having some trouble, I am investigating it now.  

US3 gave me same result

Nevermind US3 seems to work now

EDIT again: both working again for RPCMiner

EDIT 3x: bad luck streak? I switch to Eclipse and no blocks are found? raincloud

[mdude77]

I'm pointing my measly 5g/h here now.  So far I like the interface.  Note to self, and others, if switching from a pool where the workers were user.miner to eclipse, change it to user_miner if you expect to see anything.  Otherwise it happily mines away, presumably to never never land.

Q: are you keeping transaction fees?  I assume you need something to pay for this, unless you have some happy donators.

M

[betatest512]

what is the pool software you are using?

[uuidman]

I just saw it. half mhash for 17 blocks now... why?

cgminer 2.4.1 cant upgrade

What he probably means is that cgminers mhash is approx half, in my case from 320 to 160 MH.

For me seen also with cgminer 2.4.1 but directly against stratum proxy (tested both) 0.5.0 and 0.8.3, (against btcguild ). Only clue for me yet is that its a 6950, 3 other 5850 same setup, no problem. Maybe you also got a 6950 ?

Nevermind, too tired, had launched an earlier cgminer. Sorry for the fuzz.

[betatest512]

what is the pool software you are using?

please answer

[nelisky]

I have an older cgminer (2.4.1) running on OpenWRT that was working great with EMC until last weekend (which I assume was when the var diff got turned on). Since then I get roughly 50% of my hashing power reported on the workers page.

I tried upgrading to the latest git version which rendered the exact same result (and random segfaults) so I moved back to my trusted version.

What am I missing here? var diff should work fine even with 2.4.1 if I understand it correctly, so what am I missing?