why can't I ping 'eth.etheres.com' to see what the latency is from my location? (I'm using Windows/CMD command (ping eth.etheres.com)) Thanks.
ICMP (ping) has not been allowed, for me all I did was point my software miner at the service and the latency is reported when I submit a share...I get quite high from the uk 120-140 although its not made much diff a block is a block...maybe it would if 2 ppl found it same time and I'm 10ms behind the other person.
@ImAMiner? Currently no stale/invalid shares are not rewarded, we are working on a "weighting" system where they are counted but no where near as much as a valid share kind of thing.
Just my two cents, but wouldn't the easiest solution be to count all shares, including stale/invalid, as valid from every miner? If every share has a chance to solve a block or uncle, then they should all be valid. Granted the stale/invalid shares are less likely to solve a block but if every share from every miner is counted that way, then it's fair. Maybe I don't understand how it works though.
You could just copy how miningpoolhub and ethermine count stales...
@ImAMiner? most pools weight stale shares a bit differently then non-stale shares now. IMO, the best strategy for a pool is to reward n-1 stales at some ratio to non-stale shares. Say, 50% or 87.5% (the value of an n-1 uncle).
@work what is the thought process behind the reduced reward for stale shares? Is it a sort of punishment towards the miner for producing a half baked share? I really don't know, not trying to bait you into an argument or something.
It just seems to me that the simplest way to implement a solution is to count all shares the same, but maybe that's because I don't understand the rationale for reduced share reward.
@Etheres "no where near as much as a valid share" is not very comforting to me. Let's say I have 3% n-1 stales and etheres pool only counts n-1 as a 50% reward, then I'm losing 1.5% of my hashrate. That's not insignificant.
@ImAMiner? an n-1 share has a roughly 50% chance of becoming a block (if it's ethash value is higher then the already existent block at that height). And it also has a chance of becoming an uncle (worth 7/8 of a block [very rarely], worth 3/4 of a block [fairly often], [...], down to 1/8 of a block).
It's dangerous to count all shares the same, because then miners won't care about submitting work in a timely manner, and there is no reason not to crank up your kernel run-time into the multiple seconds.
Keep in mind if your stales are about the same as the pool average stale rate, you're effectively not losing any hashrate.
Comments
Block 1,948,545 - Found! Payments have been calculated and will be sent within the hour!
That's 6 blocks all under 30% in a row now, looks like today is the day to mine at Etheres!
You could just copy how miningpoolhub and ethermine count stales...
It just seems to me that the simplest way to implement a solution is to count all shares the same, but maybe that's because I don't understand the rationale for reduced share reward.
@Etheres "no where near as much as a valid share" is not very comforting to me. Let's say I have 3% n-1 stales and etheres pool only counts n-1 as a 50% reward, then I'm losing 1.5% of my hashrate. That's not insignificant.
It's dangerous to count all shares the same, because then miners won't care about submitting work in a timely manner, and there is no reason not to crank up your kernel run-time into the multiple seconds.
Keep in mind if your stales are about the same as the pool average stale rate, you're effectively not losing any hashrate.