Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 39. (Read 499597 times)
November 26, 2012, 07:19:43 PM
Interesting, thanks for the heads up ckolivas!
November 26, 2012, 07:17:37 PM
I believe I've found what the issue is with stratum+emc+cgminer causing lots of rejects.
Okay I see the problem here on EMC stratum.
Based on a commit luke-jr did to bfgminer, it seems he thinks that new work notification by stratum mandates that all work be thrown out in favour of the new work, because he FORCES the clean flag. However no other pool actually expects this, only forcing a clean when they actually send the work clean message. So I'm going to go out on a limb here and say the problem lies with the implementation of stratum on EMC, as coded up by luke-jr.
Based on a commit luke-jr did to bfgminer, it seems he thinks that new work notification by stratum mandates that all work be thrown out in favour of the new work, because he FORCES the clean flag. However no other pool actually expects this, only forcing a clean when they actually send the work clean message. So I'm going to go out on a limb here and say the problem lies with the implementation of stratum on EMC, as coded up by luke-jr.
November 26, 2012, 06:02:13 PM
Everything seems to be up and running at the moment. Are you still having issues?
Inaba, what's up with nmc unconfirmed thing? I've got like 1.5 hanging for a week now, is it working at all?
Seems that I have caught this bug too, I have over 11 unconfirmed NMC's.
November 18, 2012, 12:05:19 PM
Thanks mdude77 I will check it out later today!
November 18, 2012, 09:02:50 AM
In case you didn't see my post, I wrote a .Net "widget" for Windows that allows you to monitor your miners on p2pool, eclipse, ozcoin, and 50btc. More pools are coming as time permits (bitminter is next).
https://bitcointalksearch.org/topic/mpoolmonitor-42-monitors-most-pools-idle-worker-notification-blockchaininfo-86502
M
https://bitcointalksearch.org/topic/mpoolmonitor-42-monitors-most-pools-idle-worker-notification-blockchaininfo-86502
M
November 15, 2012, 01:58:35 PM
Thanks guys. I had forgotten about the Manage button - even though it's bright red! 
It's so obvious when you know where to look.
It's so obvious when you know where to look. November 15, 2012, 01:25:11 AM
My Workers -> Manage ... there's a drop down called Worker Type
November 15, 2012, 01:24:35 AM
Maybe I'm blind, but I've looked for this on the EMC site multiple times:
How do I switch from DGM to PPS? or PPS to DGM?
In "My Workers", click on "Manage" towards the upper right. Now under "Worker Type", there is a drop-down menu to switch between DGM and PPS. (This is the same page that allows you to make workers, and chose their passwords)How do I switch from DGM to PPS? or PPS to DGM?
November 15, 2012, 12:44:58 AM
Maybe I'm blind, but I've looked for this on the EMC site multiple times:
How do I switch from DGM to PPS? or PPS to DGM?
How do I switch from DGM to PPS? or PPS to DGM?
November 14, 2012, 07:42:49 PM
I suppose the second addendum to the numbers was glossed over slightly. It says this:
[2] Fractional parts may be problematic, since many decimal fractions cannot be represented exactly as binary fractions.
That would seem to indicate that it is better to use Integers then decimals or other real numbers. At least since they may not get the same value that the server sends.
I agree that using real numbers here is not the best idea. Unfortunately, stratum's protocol defines this as a Number represending a multiple of bdiff 1 (difficulty 1 subject to bitcoin rounding rules), which cannot reasonably represent traditional pdiff targets (which are easier to check). Additionally, EclipseMC has been using fully variable targets anyway.[2] Fractional parts may be problematic, since many decimal fractions cannot be represented exactly as binary fractions.
That would seem to indicate that it is better to use Integers then decimals or other real numbers. At least since they may not get the same value that the server sends.
I expect during stratum's BIP discussions, consensus will probably determine using a target as getwork and GBT do (without these problems) is the proper solution.
Actually I have an idea on how to suggest handling it I may see what Con thinks.
BFGMiner handles it by truncating the difficulty (with a special case of pdiff 1 for difficulties under bdiff 1) and letting the server reject shares that it doesn't think meet its target. This results in some degree of rejected "high-hash" shares, but it guarantees no valid ones are lost.That one share lost in a few billion-trillion can never be a block, so it doesn't matter.
...
Anyone who tries to force the old pool difficulty used onto Stratum, simply needs to complete school level maths first, and then think again.
The lost shares related to checking the difficulty will be if the pool implementation of the same is faulty and allowing in shares that are below what the pool specifies, or rejecting shares that are above what the pool specifies.
November 14, 2012, 05:49:32 PM
Actually I have an idea on how to suggest handling it I may see what Con thinks.
BFGMiner handles it by truncating the difficulty (with a special case of pdiff 1 for difficulties under bdiff 1) and letting the server reject shares that it doesn't think meet its target. This results in some degree of rejected "high-hash" shares, but it guarantees no valid ones are lost.so its a HACK where mined shares will get lost... (in some cases)
[/quote]
Hack, yes, but no shares will be lost. The miner will just send shares which are under the pools target difficulty, so will be rejected.
That is, they'll be rejected by the pool, rather then internally in the miner software.
November 14, 2012, 05:46:07 PM
Actually I have an idea on how to suggest handling it I may see what Con thinks.
BFGMiner handles it by truncating the difficulty (with a special case of pdiff 1 for difficulties under bdiff 1) and letting the server reject shares that it doesn't think meet its target. This results in some degree of rejected "high-hash" shares, but it guarantees no valid ones are lost.[/quote]
so its a HACK where mined shares will get lost... (in some cases)
November 14, 2012, 05:44:29 PM
I'm open to a change in EMCs way of doing it, but it seems like it's working fine in all the miners right now and it's just a JSON issue at the moment that can be fixed fairly easily one way or another.
November 14, 2012, 05:39:58 PM
I suppose the second addendum to the numbers was glossed over slightly. It says this:
[2] Fractional parts may be problematic, since many decimal fractions cannot be represented exactly as binary fractions.
That would seem to indicate that it is better to use Integers then decimals or other real numbers. At least since they may not get the same value that the server sends.
I agree that using real numbers here is not the best idea. Unfortunately, stratum's protocol defines this as a Number represending a multiple of bdiff 1 (difficulty 1 subject to bitcoin rounding rules), which cannot reasonably represent traditional pdiff targets (which are easier to check). Additionally, EclipseMC has been using fully variable targets anyway.[2] Fractional parts may be problematic, since many decimal fractions cannot be represented exactly as binary fractions.
That would seem to indicate that it is better to use Integers then decimals or other real numbers. At least since they may not get the same value that the server sends.
I expect during stratum's BIP discussions, consensus will probably determine using a target as getwork and GBT do (without these problems) is the proper solution.
Actually I have an idea on how to suggest handling it I may see what Con thinks.
BFGMiner handles it by truncating the difficulty (with a special case of pdiff 1 for difficulties under bdiff 1) and letting the server reject shares that it doesn't think meet its target. This results in some degree of rejected "high-hash" shares, but it guarantees no valid ones are lost. November 14, 2012, 05:31:32 PM
Sometimes 'good enough' is acceptable 
I'll try your patch when I get time, maybe tonight.
I'll try your patch when I get time, maybe tonight.
November 14, 2012, 05:27:56 PM
I don't know actually, it just seems offensive to me to limit a field to int when it doesn't need to be. In either case, CGMiner currently works with EMC Vardiff under Getwork, that should be no different for Stratum. I put in a pull request for cgminer with some very minor changes that make it work fine with floating point as opposed to integer (but still, of course, works with integer) so there's really no technical reason it can't be done. You can check out my fork and compile it and test it out if you want on Github.
November 14, 2012, 05:13:56 PM
I don't see any sense in limiting variable difficulty to integers. I'm interested in hearing your idea.
My argument to that would be: Why would such fine-grained difficulty be required?
November 14, 2012, 04:58:49 PM
Well my idea was that it would be easy to accept whatever eclipse sends for difficulty, truncate it to an int add 1 (you can't be below difficulty) then use it as an int in CGMiner.
I realise that this isn't a great idea as if eclipse sent .5 difficulty I would only send difficulty 1 work. In theory losing a ton of valid shares. The closer the decimal got to 1 or 2 or any other int but stayed under it the less shares would be lost.
My other thought was a workaround on the first but it would require eclipse to change so that either CGMiner could ask for difficulty as an int, or CGMiner could tell eclipse what difficulty it actually worked on so as to avoid getting paid .5 for 1 difficulty work.
For the future I really can't imagine that the integer difficulties are that bad. 1-2 is a 100% increase but 2-3 is only 50%. At 10-11 is a 10% increase. 20-21 is a 5%. This does ignore the difficulty adjustment for block timing though. I do see the point in decimal difficulties at the really low end to some extent but the higher the sent difficulty the less difference it makes.
I realise that this isn't a great idea as if eclipse sent .5 difficulty I would only send difficulty 1 work. In theory losing a ton of valid shares. The closer the decimal got to 1 or 2 or any other int but stayed under it the less shares would be lost.
My other thought was a workaround on the first but it would require eclipse to change so that either CGMiner could ask for difficulty as an int, or CGMiner could tell eclipse what difficulty it actually worked on so as to avoid getting paid .5 for 1 difficulty work.
For the future I really can't imagine that the integer difficulties are that bad. 1-2 is a 100% increase but 2-3 is only 50%. At 10-11 is a 10% increase. 20-21 is a 5%. This does ignore the difficulty adjustment for block timing though. I do see the point in decimal difficulties at the really low end to some extent but the higher the sent difficulty the less difference it makes.
November 14, 2012, 04:26:52 PM
I don't see any sense in limiting variable difficulty to integers. I'm interested in hearing your idea.
November 14, 2012, 04:13:58 PM
Cgminer doesn't seem to like that. coming up as dead.
cgminer's stratum implementation is broken. I've got some fixes in BFGMiner git, but I hear Con's making excuses.Stratum works fine on Ozcoin. I'd say Stratum implementation on Eclipse is broken..
I found Con's implementation of stratum had 3 problems with regard to working on Eclipse:
- It assumes all difficulties set are integers. JSON treats all Numbers as the same type, and stratum doesn't restrict the range to integer values. Every stratum client implementation except Con's correctly handles real number difficulties. EclipseMC has an unrestricted vardiff range, and more often than not uses a real number.
- It assumes the server will send a notify (or at least some message) every 90 seconds. Stratum makes no such guarantees.
- It gives up on authorizations if a response is not received basically instantly.
Cgminer doesn't seem to like that. coming up as dead.
cgminer's stratum implementation is broken. I've got some fixes in BFGMiner git, but I hear Con's making excuses.id: An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification. The value SHOULD normally not be Null [1] and Numbers SHOULD NOT contain fractional parts [2]
It seems like luke-jr misunderstands what a client is. The client is CGminer. Also in no example I have found in the documentation was id anything but an integer. This doesn't mean it has to be but if every example has it being so then it seems like a precedent. It seems like id is used instead of method. Shouldn't it be like this?
{"jsonrpc": "2.0", "method": "auth", "id": (whatever the client sent)}
According to the Stratum Documentation.
Response
Every response contains following parts
◦message ID - same ID as in request, for pairing request-response together
◦result - any json-encoded result object (number, string, list, array, …)
◦error - null or list (error code, error message)
While true it says that any string, number or NULL value is required, it also stated it is selected by the client. I am not 100% positive on the rest I didn't write the specs or anything. I just read them. I really don't see why a person wouldn't want authorized before they get a difficulty.
As I see it and maybe I am totally wrong but I want to try stratum on EMC. Since authorize can come at any time why can't it come before subscribing?
So, how to I use stratum on EMC?
help?
I'll plan to release a BFGMiner with the fixes sometime soon... but it should be noted that GBT is still better. help?
Obviously the stratum proxy and/or poclbm should work fine too.
I suppose the second addendum to the numbers was glossed over slightly. It says this:
[2] Fractional parts may be problematic, since many decimal fractions cannot be represented exactly as binary fractions.
That would seem to indicate that it is better to use Integers then decimals or other real numbers. At least since they may not get the same value that the server sends.
Actually I have an idea on how to suggest handling it I may see what Con thinks.
Jump to: