Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 38. (Read 499791 times)
November 27, 2012, 07:47:22 PM
us2 was probably down today, and after it got back up, my miners were able to connect to it, but it was not acknowledging shares of my miners. I realized it after mobile miners screen was showing 0MH/s for my us2 miners and showed them as down (red) even though my miners were still mining on us2.
November 26, 2012, 06:19:43 PM
Interesting, thanks for the heads up ckolivas!
November 26, 2012, 06: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, 05: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, 11:05:19 AM
Thanks mdude77 I will check it out later today!
November 18, 2012, 08: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, 12: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, 12:25:11 AM
My Workers -> Manage ... there's a drop down called Worker Type
November 15, 2012, 12: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 14, 2012, 11:44:58 PM
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, 06: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, 04: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, 04: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, 04: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, 04: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, 04: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, 04: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, 04: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, 03: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, 03:26:52 PM
I don't see any sense in limiting variable difficulty to integers. I'm interested in hearing your idea.
Jump to: