So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?
I'm getting 1% stale on EMC, and 0.1 on Ozcoin.
This is the issue I've been discussing at length on this thread with Inaba. Yes it's just submitting shares below target after diff rises. Try the EMC GBT server until it's resolved. |
|
|
|
|
7000 cards need SDK 2.6 or later
|
|
|
|
With p2pool having upgrade pains, I've pointed my miners to eclipse and ozcoin respectively. It seems eclipse is shipping me non integer difficulty work, ie, somewhere between 1 and 2. I couldn't tell by the share output, because it always says x/1, but I see this on top: (5s):1.928G (avg):1.963Gh/s | Q:167 A:1075 R:6 HW:0 E:644% U:20.2/m
TQ: 0 ST: 7 SS: 1 DW: 328 NB: 7 LW: 1789 GF: 0 RF: 2 WU: 27.9
The WU is around what I expect U to be when dealing with difficulty 1 work. Am I reading this right? Any change we could get a decimal point or two in the cgminer output to show this?  Not much point when we'll all be mining difficulties in the 10s to 100s soon. |
|
|
|
Ok, if that's the case then that solves the issue. Conman, does that resolve the rapid difficulty change issue with EMC then if that particular method is implemented to handle difficulty from the Stratum protocol side of things?
For scenario A, if the old diff applies to work given out prior to the diff change it's almost the same as tying it with the work, and is how cgminer currently manages difficulty already for rising diff. Scenario C will sort itself out as well. So this works for me. What about if diff drops as in scenario B? Do you credit work to the new difficulty or does the old difficulty still apply? There is still the potential for lost opportunity in scenario D, and this would be no different if difficulty is tied with work or not, with gbt or stratum, as every window lost is the time of a one way trip from the server to the miner. While small, if done often it would start to add up. Thus it would still be prudent to minimise the diff changes to avoid this. |
|
|
|
ckolivas, maybe you can now simplify the vardiff code by storing currently known difficulty with the job which has been notified by the server? Practically it may work as if difficulty is a part of the notify message itself. This will still work with existing pools, code for managing it is much simpler and solves some uncertainity in edge cases...
I already do that. |
|
|
|
How goes preparing the first BIP draft, slush?
Not very well. I just found https://www.btcguild.com/new_protocol.php written by Eleuthria and I think this can be quite nice start for the BIP. In contrast to Eleuthria, I'm pretty bad writer and my expression capabilities are a bit limited. Whatever you do, please EXPLICITLY say what significant bit and byte order the data is in  |
|
|
|
send: {"method":"mining.notify","params":[["1-c9","0000000000e3441ba33cf51d11a8aef12e8ae6d01a5bd54e8ec7cc9a9c22837b","01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff56037c9600094269744d696e746572062f503253482f2cfabe6d6d8c53896d9815717a31ffc5 135ccd79527cec9e360aba3738261e0a338a827eb60100000000000000136465760100000000000 000c900000000000000ffffffff0100f2052a010000001976a914616c05127d60e61407f52bce21 a4f894268cd89588ac00000000","",[],"00000002","1c018167","50b292ad",false]],"id":1}
! :-) Thanks slush. |
|
|
|
You clearly do NOT want to tie difficulty to the work in Stratum, as you've stated numerous times.
Apparently he changed his mind. Look in the Stratum thread. I am implementing server-side Stratum now and I'm going to have difficulty tied to work. I'll send set_difficulty before the work, unless it is the same diff as the previous work, in which case I'll skip sending set_difficulty. Oh sorry. Send your first set of parameters for mining.notify before sending the ack for mining.authorize.
That's not helping either. I'm wondering if it has to do with my formatting being different (from other Stratum pool implementations). recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","01"],"01020304",4],"error":null,"id":0}
send: {"method":"mining.set_difficulty","params":[1],"id":1}
send: {"method":"mining.notify","params":[["1-c9","0000000000e3441ba33cf51d11a8aef12e8ae6d01a5bd54e8ec7cc9a9c22837b","01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff56037c9600094269744d696e746572062f503253482f2cfabe6d6d8c53896d9815717a31ffc5135ccd79527cec9e360aba3738261e0a338a827eb60100000000000000136465760100000000000000c900000000000000ffffffff0100f2052a010000001976a914616c05127d60e61407f52bce21a4f894268cd89588ac00000000","",[],"00000002","1c018167","50b292ad",false]],"id":1}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}
recv: {"id": 2, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":2}The strange thing is that now it tries to authorize twice, with a 10 second pause in between, then crash. I'm lost as to what's wrong then. It seems you're running windows which makes debugging a pain as well. Are you running the latest 2.9.5? 2.9.4 was crashing on extracting gbt information from your pool occasionally (obviously unrelated to stratum). There are debug builds here along with instructions for debugging on windows: http://ck.kolivas.org/apps/cgminer/debug/ . |
|
|
|
Ok, fair enough. Maybe Con can chime in then and tell me what the difference is between EMC and Slush's pool as viewed by CGMiner? All this is ultimately due to CGMiner apparently having trouble with EMC because the difficulty changes too rapidly - but if that's the case, wouldn't the same problem be evident on Slush's pool? If not, why not? I'll be glad to fix it if there's a problem somewhere. Actually, I wasn't comparing you to slush's pool because ironically... slush's pool doesn't do vardiff yet. ozcoin and btcguild are the other pools I can compare to. Make what you want of that fact. So the issue really comes down to the round trip of network time between pool sending out diff and miner receiving it, and the miner sending out a share. Most of us have round trips of ~500ms across real internets, though some of you are seeing ping times of <50ms but this does not translate to a processing, submission and return time of 50ms. Luckily c is fast so cgminer intrinsically doesn't add *that* much processing time, but it does add time. There are 4 distinctly different scenarios with changing diff separate from work. A. Diff rises before cgminer submits lower diff share and cgminer is aware of it B. Diff falls before cgminer submits now adequate diff share and cgminer is aware of it C. Diff rises in the round-trip window period as cgminer has already submitted a share below difficulty and cgminer is not aware of the new diff D. Diff falls in the round-trip window period as cgminer has discarded a share that would now be adequate as cgminer is not aware of the new diff cgminer can only do something about scenario A and B. C and D are entirely out of its control. The way I decided to manage these situations is based on maximising the possible paid share submission. Scenario A: cgminer can decide to retarget for the higher difficulty and not submit the share. It currently does NOT do this, instead keeping the difficulty target at the original lower value, in case pools have a grace period at the lower difficulty. It risks rejects but no shares are lost in this way. This is what causes more rejects on EMC when the difficulty is retargeted often. However no paid work is lost here. Scenario B: cgminer can decide to retarget for the lower difficulty and submit the share. cgminer does this since clearly this share is now work it will get paid for. No paid work is lost here, and no rejects are induced. Scenario C: cgminer can't do anything about it, but this registers as a reject. Any increase of diff by a pool can elicit this, and the more often the difficulty is raised, the more rejects will be seen. Once again, no paid work is lost here. Scenario D: cgminer can't do anything about it, and this work is lost. Any decrease of diff by a pool can elicit this, and the more often the difficulty is lowered, the more shares are lost. No rejects are induced. So there is a round-trip window period for scenario D where shares are potentially lost. If you have a 500ms round trip window, then you lose .5 seconds worth of possible lower difficulty shares with each drop. The more decreases, the more lost. The only changes I can make to cgminer's default behaviour to help here is scenario A, and retarget to the higher difficulty. Note that the emphasis is always on submitting shares that are possibly paid for over minimising rejects. B is fine. Nothing can be done about the rejects in C, but no paid shares are lost. D is the real issue that nothing can be done about, and unless difficulty is tied to the work, it ends up being dependent on how often the pool ends up changing difficulty that determines how much work is lost, and secondarily the visible rejects. I agree that retargeting with vardiff is important or floods of low diff shares will be a real issue. However retargeting for small changes in difficulty based on share submission, which is subject to large amounts of variance, will see lots of changes of difficulty and the inherent rise in rejects and lost shares. EDIT: Note that my scenario A management is in line with slush's change to the protocol stipulating changes to diff apply to next work sent by server, not existing work. |
|
|
|
You're sending a zero sized string for extranonce1
I thought that was allowed. Anyway it doesn't help changing that: recv: {"id": 0, "method": "mining.subscribe", "params": []} send: {"result":[["mining.notify","01"],"01020304",4],"error":null,"id":0} recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]} send: {"result":true,"error":null,"id":1} Still crash. Oh sorry. Send your first set of parameters for mining.notify before sending the ack for mining.authorize. Something like Server: {"params": ["bf", "4d16b6f85af6e2198f44ae2a6de67f78487ae5611b77c6c0440b921e00000000",
"01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff20020862062f503253482f04b8864e5008",
"072f736c7573682f000000000100f2052a010000001976a914d23fcdf86f7e756a64a7a9688ef9903327048ed988ac00000000",
["c5bd77249e27c2d3a3602dd35c3364a7983900b64a34644d03b930bfdb19c0e5","049b4e78e2d0b24f7c6a2856aa7b41811ed961ee52ae75527df9e80043fd2f12"],
"00000002", "1c2ac4af", "504e86b9", false], "id": null, "method": "mining.notify"}\n
Server: {"error": null, "id": 1, "result": true}\n
|
|
|
|
Trying to implement Stratum on my pool, but cgminer crashes when I connect to the server.
This is what happens, from the server perspective:
recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","1"],"",4],"error":null,"id":0}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}
Then Windows says "cgminer.exe has stopped working"
See Eleuthria's cheat sheet: https://www.btcguild.com/new_protocol.phpYou're sending a zero sized string for extranonce1 |
|
|
|
|
If you were having a problem with cgminer + GBT on this pool, I'd like to recommend upgrading to cgminer 2.9.5 which has fixes for rare large coinbases which were causing a cgminer crash.
|
|
|
|
|
To be clear, again I agree difficulty should be tied in with work on stratum instead of the current implementation. However pools can do a lot to alleviating the harm that has by tolerating a certain amount of hysteresis before retargetting diff. I'm sure emc can be tweaked some more with this in mind.
|
|
|
|
No, it's an acknowledged problem with Stratum. The original Stratum design is flawed. Difficulty is decoupled from work and that is simply an incorrect way to handle mining. Difficulty and work are inseparable from a mining perspective. The way Stratum handles is is entirely incorrect and needs to be addressed. This is not really in question, everyone involved pretty much agrees that something needs to be done about it, the only question is exactly what.
My implementation of variable difficulty is the original implementation of variable difficulty and has been working fine on both GW and GBT for months now. It works fine in CGminer on GW, it also works fine in GBT, Stratum and GW in BFGminer. The only implementation it does not work on is CGMiner with Stratum, but that's not really CGMiners fault as its' a design flaw in Stratum and Conman doesn't really have control over that.
I hope you realize that every other Stratum implementation throws away a bunch of valid work you are doing for the pool and it even throws away solved blocks if the conditions are just right. EMC's implementation will NEVER throw away valid work. So tell me which would you prefer? Shares going POOF magically on your Stratum server of choice or you getting paid for your work?
Excuse me but 99.99% of the stratum code in bfgminer is from cgminer |
|
|
|
The auto-gpu switch is no longer recognized.
I assume you mean on windows? I may have built it without adl support, lemme check EDIT: yes my fault. Repackaged the windows binaries. Try redownloading. |
|
|
|
|
New release - 2.9.5, 25th November 2012
Bugfix release.
Human readable changelog:
Fixed the crash when a GBT pool was used either as primary or backup when its gbt coinbase was very large.
Fixed the ztex submits lots of dupes bug based on an idea by luke-jr
Fixed the much larger amount of shares being leaked to backup pools
"getworks" will not be counted now from backup pools when they're just being used to see the pool is alive
Mips openwrt fixes
Full changelog:
- fixes target calc for mips openwrt
- openwrt needs roundl
- Get rid of unused last_work in opencl thread data.
- Do away with the flaky free_work api in the driver code which would often lose
the work data in opencl and simply flush it before exiting the opencl scanhash.
- Use base_work for comparison just for cleanness in __copy_work
- Remove all static work structs, using the make and free functions.
- Add pool no. to stale share detected message.
- Add info about which pool share became stale while resubmitting.
- Copy the work on opencl_free_work
- Add an extra slot in the max backlog for ztex to minimise dupes.
- Do not use or count the getworks submitted which are simply testing that pools
are still up. This was increasing share leakage and making stats not reflect
real work.
- Track all dynamically allocated memory within the work struct by copying work
structs in a common place, creating freshly allocated heap ram for all arrays
within the copied struct. Clear all work structs from the same place to ensure
memory does not leak from arrays within the struct. Convert the gbt coinbase and
stratum strings within the work struct to heap ram. This will allow arbitrary
lengths without an upper limit for the strings, preventing the overflows that
happen with GBT.
- libztex: Work around ZTEX USB firmware bug exposed by the FreeBSD libusb
- opencl: Use new dev_error function for REASON_DEV_NOSTART
|
|
|
|
So yeah, great miner guys, but there still seems to be some compatibility issues that need to be ironed out as far as the windoze side is concerned me thinks, but I don't blame you for not bothering too much about it, seeing as we all love windows so much. Well... I actually have busted my balls for months on end trying to sort out the windows issues, so that is a slight understatement saying "not bothering much"  Enjoy anyway. |
|
|
|
... and I have no control over temps, fan, memclock, engine or anything else, despite having them in my config file that it says it's read. GPU-z sees everything as stock. I've tried multiple driver versions, multiple re-installs, dummy plugs, crossfire, different gfx cards....everything. cgminer has a particular format for its conf file. Do you have the syntax all proper? Commas and { }'s all in the right places? -- Smoov Hi Smoovious, Yeah, all as it should be. Plus it was written by cgminer anyway, so it should be right, I just changed a few values. Problem is with the startup errors.....it's just not reading my cards right..... Good old random windows fuckage. Not getting adl access also happens when you log in as one user and switch to another. |
|
|
|
I was just kidding about the way I was showing public support for Graet's pool.  |
|
|
|
The semi-official Bitcoin Pool Comparison Chart only shows 2 stratum pools, BTCGuild and Slush's. Are there others?
Most pools are in the process of implementing it. Of the other ones that already have it, ozcoin is my favourite, but emc also does it (though with too unstable a variable difficulty IMO). Good to know Thanks ckolivas  * ckolivas rattles the donation jar and whistles innocently j/k |
|
|
|
|
Show Posts
