EclipseMC reporting inconsistent share contributions?

[optimiz3]

EclipseMC has been requesting difficulty ~10 shares, but has been crediting only 1 share per submission in their UI.  This is particularly troubling given they advertise VARDIFF, even though I haven't observed difficulty change notifications beyond the initial one via network traces.

Anyone else observing this?

[zvs]

EclipseMC has been requesting difficulty ~10 shares, but has been crediting only 1 share per submission in their UI.  This is particularly troubling given they advertise VARDIFF, even though I haven't observed difficulty change notifications beyond the initial one via network traces.

Anyone else observing this?

i suspect everyone is, in order to make payouts fair, by giving 1 share per 10 difficulty share submission

just a wild stab in the dark though

[Inaba]

Share display is not consistent throughout EMC.  Some places displays actual shares submitted and some places display 1diff shares submitted.  It's something that I probably need to get taken care of, but since it's only a visual issue, it hasn't been a high priority.  That's the problem with being the first one to implement new things like vardiff... there's no standard and I had to figure it out as I went along.  It's much easier for the pools coming behind to adhere to a standard.

Anyway, I assure you that you are getting full credit for your shares.  Take a look at your payouts, they should reflect your hashrate properly, that would be the real measure. 

Just as an FYI, minimum share difficulty is set at 10 on EMC.  Everyone gets difficulty 10 shares and it goes up from there.  It never drops below 10.

[optimiz3]

IMO - it would be best to normalize share contributions to diff=1, as this is what many other major pools do.  Otherwise it is near impossible to compare apples to apples without qualifying the pool and having specific knowledge about each pool.

It's becoming a large enough support issue that I'm inclined to just hide EclipseMC from the list of mining pools in our mining software until this is fixed, as right now we're dealing with angry users asking about share contribution discrepancies.

[Inaba]

I agree, 1diff as the base share is the way to go. It is on my priority list, I will see what I can do over the next few days.

[optimiz3]

Appreciated Inaba, also updated the thread title to be more accurate.

[Inaba]

All share listings should now report diff1 shares instead of actual shares... I think I found everything.  If there's somewhere that's not reporting properly, let me know and I'll get it fixed.

[ironfalcon]

MAXINT shares in this round?  Is this just a UI issue or have we stopped submitting shares?

http://imgur.com/B0foAGq

[ironfalcon]

(the number of shares listed for this round is exactly 2^31-1.)

also I have a 100 GH/s miner split across 3 pools and it says I'm humming at 260 GH/s on eclipse right now?

[Inaba]

Well, never thought I'd run into that limit, jeez.  Shares are still counted properly - they are processed individually and share count is wiped between batches, so the actual payment mechanism for shares only deals with small numbers of shares.  The round share counter is just a simple ++ counter.

I'll get that fixed shortly.

*EDIT* - Fixed... we shouldn't run into that particular problem again.

[ironfalcon]

awesome. thanks for investigating