Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 42. (Read 499597 times)
November 03, 2012, 09:01:01 AM
say for example I want to get a diff 5 share only how do I configure that in Eclipse as you offer Vardiff
November 03, 2012, 07:12:09 AM
Hmm... I remember I ran into this same problem in the quick stats a long time ago but I can't remember what caused it specifically...
I made a change to how that is handled, did it fix the problem? I can't duplicate it on my test accounts on command.
I made a change to how that is handled, did it fix the problem? I can't duplicate it on my test accounts on command.
Hard to tell since it seemed to be sporadic. I'll let you know if I see it again.
M
November 03, 2012, 01:42:34 AM
Hmm... I remember I ran into this same problem in the quick stats a long time ago but I can't remember what caused it specifically...
I made a change to how that is handled, did it fix the problem? I can't duplicate it on my test accounts on command.
I made a change to how that is handled, did it fix the problem? I can't duplicate it on my test accounts on command.
November 02, 2012, 04:46:56 PM
Where are you seeing that?
On the API output. The website shows a value (less than 1, only 2.5 gh pointed here), the API shows 0. Always.
Edit: It's there now. It wasn't when I wrote the original note..
M
It's doing it again. The website says:
Code:
0.06064159
The API says:
Code:
"estimated_rewards":0
As of now we're ~16 mins into a block.
Edit: 4mins later, the API is properly showing it..
M
November 02, 2012, 02:24:33 PM
http://us1.eclipsemc.com:8337 GW: 774 A: 5726 740 % Diff1 A: 15477 2000 % R: 14 0.2 %
http://us2.eclipsemc.com:8337 GW: 441 A: 6530 1481 % Diff1 A: 15659 3551 % R: 20 0.3 %
http://us3.eclipsemc.com:8337 GW: 714 A: 8745 1225 % Diff1 A: 18080 2532 % R: 42 0.5 %
US2 seems to be the sweet spot for me.
http://us2.eclipsemc.com:8337 GW: 441 A: 6530 1481 % Diff1 A: 15659 3551 % R: 20 0.3 %
http://us3.eclipsemc.com:8337 GW: 714 A: 8745 1225 % Diff1 A: 18080 2532 % R: 42 0.5 %
US2 seems to be the sweet spot for me.
November 02, 2012, 02:06:11 PM
Where are you seeing that?
On the API output. The website shows a value (less than 1, only 2.5 gh pointed here), the API shows 0. Always.
Edit: It's there now. It wasn't when I wrote the original note..
M
November 02, 2012, 02:01:39 PM
Where are you seeing that?
November 02, 2012, 12:13:33 PM
Looks like estimated_rewards is always 0:
"estimated_rewards":0
Am I the only one using this?
M
"estimated_rewards":0
Am I the only one using this?
M
November 01, 2012, 07:35:15 PM
Hour sixteen says YES... all you other hours: Piss off!
The pool isn't really unlucky. Just look at the bottom of the block stats page, we are within 4% of the median for the last 50 blocks, and it swings back and forth within 5% or so most of the time. It's pretty much exactly where you'd expect it to be over time.
The pool isn't really unlucky. Just look at the bottom of the block stats page, we are within 4% of the median for the last 50 blocks, and it swings back and forth within 5% or so most of the time. It's pretty much exactly where you'd expect it to be over time.
November 01, 2012, 06:02:07 PM
why is eclipse pool becoming so unlucky?
November 01, 2012, 05:55:41 PM
could this 14 hour round end please?
thanks 
thanks 
November 01, 2012, 06:54:46 AM
EMC tracks difficulty per job, not per user. So it works on both the getwork and GBT side, so it doesn't matter which protocol you use or when you submit the work, as long as it's not stale, it will accept it if it's under the difficulty for a particular job. If you're discarding work when you receive new work without submitting it then yes you'd lose shares, but if you submit it even after you get new work, it's likely still valid within the stale window.
Woo - nice.That's my argument against Stratum at the moment, the fact that difficulty is separated from work.
Now if we could just get GBT to reduce the amount of data that it needs to send to the miner (more than GetWork with roll-n-time), use a better protocol ..., and solve the mystery of ignored transactions; then if Stratum's diff was also fixed we'd have 2 closely competitive options ...
October 31, 2012, 09:08:03 PM
US 1 working here
October 31, 2012, 08:41:27 PM
EMC tracks difficulty per job, not per user. So it works on both the getwork and GBT side, so it doesn't matter which protocol you use or when you submit the work, as long as it's not stale, it will accept it if it's under the difficulty for a particular job. If you're discarding work when you receive new work without submitting it then yes you'd lose shares, but if you submit it even after you get new work, it's likely still valid within the stale window.
October 31, 2012, 07:44:56 PM
Ah, got it... no, it just uses a sliding window. Is there some drawback to bouncing around? The work is accepted for old difficulty work, so it doesn't matter if there is a difficulty change, since the difficulty is tied to the work sent out. You might be currently working on Difficulty 3 and sending back difficulty 2 shares from an older set of work that hasn't been sent back yet.
Not with getwork, but with GBT (and stratum) the work is tied with the block template they get, so if they ask for an updated block template, and are currently working on different difficulty shares, they lose work across diff changes (mainly on diff drop) since internally the pool only has the notion of the current difficulty target expected from the miner unless you go out of your way to add leeway expecting old target diff work for some grace period. October 31, 2012, 07:36:32 PM
Ah, got it... no, it just uses a sliding window. Is there some drawback to bouncing around? The work is accepted for old difficulty work, so it doesn't matter if there is a difficulty change, since the difficulty is tied to the work sent out. You might be currently working on Difficulty 3 and sending back difficulty 2 shares from an older set of work that hasn't been sent back yet.
October 31, 2012, 07:22:17 PM
Well, the sliding window is currently set at 180 seconds, so, if I understand what you're asking, then yes to a limited degree.
No, by hysteresis I mean a different threshold for lowering diff versus raising diff. i.e. if the shares are > 20 per minute to increase diff, but then to only lower diff if they drop to < 10. There will be less bouncing around of diff values that way. October 31, 2012, 01:22:51 PM
Sorry to hear that.. hope they give it back one day. Doesn't seem right at all.
Nope, they are still holding on to my funds. @#%#@$ Paypal.
Con - are you seeing what you should be seeing or are you still experiencing a problem?
Con - are you seeing what you should be seeing or are you still experiencing a problem?
October 31, 2012, 01:08:36 AM
Well, the sliding window is currently set at 180 seconds, so, if I understand what you're asking, then yes to a limited degree.
October 30, 2012, 11:51:00 PM
US1 is currently set to 20 spm over a 180 second test window. You are connected to US1 and not seeing an adjustment even at almost twice that?
Although... now that I think about it, that makes sense, if you aren't doubling the target then you won't get to 2 very often, since it would bring you in under 20 SPM otherwise, so I think that makes sense.
Ok, wondering whether you used any hysteresis for diff up versus diff down and whether the diff target is a "keep below 20 shares". There's nothing actually wrong here then, just my misinterpretation. Although... now that I think about it, that makes sense, if you aren't doubling the target then you won't get to 2 very often, since it would bring you in under 20 SPM otherwise, so I think that makes sense.
Jump to: