This looks good. Thanks for including the user-agent in there as well. Note the session ID has changed between the initial subscription and the resume, BUT the extranonce1 has remained the same. This tells the miner it can (re)submit shares before the disconnection.
If the resume fails, how should the server respond? Give an error, or just a new extranonce1? If the old connection is still there, I guess the server could disconnect it. That means the session ID must be hard to guess so you can't disconnect other people. You must also be very sure that you don't give out the same session ID twice, or you'll have two workers disconnecting each other all day. It's safer to never resume a connection that still appears up to the server. But I wonder how often it will happen that a client tries to resume before the server discovers that the old connection is dead. Letting both connections stay seems like a bad idea. They'd both be doing the same hashes in the unlikely event that they both keep hashing. I think submitting a new extranonce1 is all that is required. We should view the sessionid submission as a hint only and let the pool decide what to do. You will indeed need unique session IDs for this support to work. When luke-Jr tested it, he found that the old connection was not actually detached before I was requesting a new one with the sessionID. This is not surprising given how difficult it can be to tell that a raw socket is actually broken or not. I suspect that dropping the first connection there is the answer. |
|
|
|
Hey Josh,
This had probably been asked before, but will EMC be ready for the wave of ASIC? I assume you'd get a ton more traffic with all the shares being submitted. Was just hoping once I get my new tech, I'd have a pool I could start mining with.
Pretty much every pool except for deepbit is ready for ASIC hashrates. |
|
|
|
|
My 4x7970 rig had a 1250W OCZ Gold PSU. It uses ~1150 at the wall when maxed out hot fans high overclocked and no real power saving option is in use. Bear in mind it had a couple of hard drives and the case has lots of fans too.
|
|
|
|
Ok for those not watching the discussion on #stratum on IRC, I believe we have a final protocol for mining resume which should not break any clients or pools. It was decided that the parameters could include both the user agent and the session ID as the first and second parameters. If this fails cgminer/other clients should resort to sending blank set of parameters as previously. The session Id, it was decided, would be encoded along with the notification message "mining.notify" as a member of the 3 deep array parameters returned for "result" by the pool. See the following for an example of an initial connect followed by a reconnect. [2013-02-25 10:30:58] SEND: {"id": 0, "method": "mining.subscribe", "params": ["cgminer/2.10.5"]}
[2013-02-25 10:30:58] RECVD: {"result": [[["mining.notify", "02000000b507a8fd1ea2b7d9cdec867086f6935228aba1540154f83930377ea5a2e37108"], ["mining.set_difficulty", "02000000b507a8fd1ea2b7d9cdec867086f6935228aba1540154f83930377ea5a2e371082"]], "02000000", 4], "id": 0, "error": null}
[2013-02-25 10:30:58] Pool 0 stratum session id: 02000000b507a8fd1ea2b7d9cdec867086f6935228aba1540154f83930377ea5a2e37108
[2013-02-25 10:30:58] Pool 0 confirmed mining.subscribe with extranonce1 02000000 extran2size 4
[2013-02-25 10:33:00] SEND: {"id": 2, "method": "mining.subscribe", "params": ["cgminer/2.10.5", "02000000b507a8fd1ea2b7d9cdec867086f6935228aba1540154f83930377ea5a2e37108"]}
[2013-02-25 10:33:00] RECVD: {"result": [[["mining.notify", "02000000c33cfaa37a964c2ba76c78b99dc170a1b1fe7a5fe025f72e89afba7fc6f23d0e"], ["mining.set_difficulty", "02000000c33cfaa37a964c2ba76c78b99dc170a1b1fe7a5fe025f72e89afba7fc6f23d0e2"]], "02000000", 4], "id": 2, "error": null}
[2013-02-25 10:33:00] Pool 0 stratum session id: 02000000c33cfaa37a964c2ba76c78b99dc170a1b1fe7a5fe025f72e89afba7fc6f23d0e
[2013-02-25 10:33:00] Pool 0 confirmed mining.subscribe with extranonce1 02000000 extran2size 4
Note the session ID has changed between the initial subscription and the resume, BUT the extranonce1 has remained the same. This tells the miner it can (re)submit shares before the disconnection. Hopefully we will not need to revise this any further. |
|
|
|
|
First card sold for $350AUD.
Second card up for sale now.
|
|
|
|
Hello,
I have a Hackberry (ARMHF) Allwinner A10 dev board.
Where can I find the 32bit binaries of cgminer? Do I have to compile them for ubuntu 12.10, likely 32bit, if these don't exist?
There are no 32 bit linux binaries, so yes you do have to compile them. |
|
|
|
Sounds to me like a HHTT stratum implementation issue rather than anything else. Thanks for your quick reply.  Sorry to bother you. Since I don't know anything about the protocol and about your code, let me know whether I understand correctly (so I will contact HHTT and I will be able to explain better the issue): that nonce isn't real, is it? Cgminer never found it and never sent it: it is faked by HHTT. Otherwise I don't understand why cgminer didn't log it. Thanks again. Stratum always starts at diff 1, even if you have asked for a different diff. So cgminer starts sending diff 1 shares until it is told to change diffs, and even then, if there are any shares that it has already found, it still submits them. The stratum protocol specifies that these should be valid shares and accepted if submitted with the original work item. Now cgminer does NOT log shares submitted at the time they're submitted, unless you're in verbose mode. It only shows the response from pool when it accepts or rejects the share submitted. Otherwise it would have to show them twice. Instead it keeps a database of shares submitted and waits till it gets a response before saying accepted or rejected. If the share has been submitted, and the pool never responds to it, you will never see any record of it. If a connection is dropped, cgminer discards all recollection of old shares submitted and considers them lost, because most of those shares will be lost somewhere in networking, and the pool will not accept shares from old connections until stratum develops a robust resume mechanism (which I'm trying to push forward at the moment). If any shares come back from the old connection as accepted or rejected, cgminer will call them "untracked shares" because it will have discarded any record of them. |
|
|
|
Sounds to me like a HHTT stratum implementation issue rather than anything else. |
|
|
|
Is there somewhere a Windows 64bit binary available?
Or does it not make very much difference if I am running the 32-bit executable on 64 bit ?
64 bit ming (the cross platform tools used to make windows binaries from linuxy software) is subtly broken for starters, it uses more ram than the 32 bit binaries, and it actually provides precisely zero benefit. So if anything, you're better off with the 32 bit binaries. |
|
|
|
Just switched to 2.10.5 and cgminer.exe crashes when it tries connecting to the pool I'm using. 2.10.4 works fine.
Almost certainly you upgraded something else between changing from 2.10.4 to 2.10.5 and that is what's crashing it. Usual suspect: driver+/-SDK change. Cgminer caches the binary created so if you try move the .bin files out of your 2.10.4, you can recreate your crash there too. |
|
|
|
|
I've implemented the modified protocol for reconnection and it's in the current cgminer master git. Not sure if anyone's interested in testing it as you all could be too busy fapping to ASIC hashrates right about now. Either way it should work in a way that doesn't break existing pool stratum support or slush's proxy.
|
|
|
|
Hello,
There might be potential Found block bug in cgminer 2.10.5. I had found about 5-10 blocks since i start mining. With old versions of cgminer (getwork) I was always able to see Found Blocks count > 0 from the cgminer api. Recently i Found a block and my pools says that is me who found it. But cgminer shows 0 under Found blocks menu. My question is follows: When mining with stratum and diff > 1 let say 8, is there any chance cgminer not to report to pool that block is found. In general what happens when we found a block, and our share matches to diff 1 which does not meet pool requirement for diff 4 for instance? Is there any chance found block to be wasted and never reported to the pool?
No |
|
|
|
thanks! Looks much better!
Any explanations why a High Intensity is not good for BTC?
Over 14 is an overflow. The numbers mean different things on LTC vs BTC. Over 9 causes too long a period of work on the GPU and the hashrate fluctuates wildly without benefit. |
|
|
|
|
Anything over I 14 is wrong with BTC. I 9 is about ideal for that card.
|
|
|
|
There's not enough to warrant a new release, but if anyone's keen to try the new poclbm kernel you can download the latest version of the file directly here: https://raw.github.com/ckolivas/cgminer/master/poclbm121016.clRemember to delete any .bin files. Seems to work best with SDK 2.7. Even my NVIDIA cards seem to prefer this kernel. I see no difference in speed for a rig with 5870+6990 cards (SDK 2.4). But there is a notable difference for a rig with 7970 cards (SDK 2.6), from 2524Mh/s to 2543Mh/s. Maybe you should keep one 7970 for a little while though?...I smell another scrypt bounty in the air... Not necessarily a LTC fan, but like many GPU miners I'll resort to any option available to keep the rigs working on something. Yah well I did test the code on a 7970... however if you're on 5x or 6x with SDK2.4, it won't even be using this kernel so of course you won't see a difference. My poclbm kernel is optimised for sdk 2.6+ and cgminer usually chooses phatk for other cards on SDK 2.4. You'd have to install SDK 2.7 and manually select -k poclbm to try it on those other cards, and I really don't know how it will perform. I suspect the 6x will perform well, but the 5x are legendary for much preferring phatk with older SDKs. EDIT: Oh and I've made some minor updates to the scrypt kernel too... |
|
|
|
I recently experience a problem with cgminer, when it should recreate it's .bin files, e.g. phatk121016Cypressv4w128l4.bin debug version of cgminer says: cgminer_d.exe caused an Access Violation at location 0042e08c in module cgminer_d.exe Reading from location 04b4e41b.
Registers:
eax=04b4e417 ebx=01e79de0 ecx=ffb5c74d edx=00000008 esi=01e5fd58 edi=01e79f1f
eip=0042e08c esp=0028f4e0 ebp=0028f548 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
Call stack:
0042E08C cgminer_d.exe:0042E08C
0043027F cgminer_d.exe:0043027F
0042D020 cgminer_d.exe:0042D020
00416F8A cgminer_d.exe:00416F8A
004010B9 cgminer_d.exe:004010B9 __mingw_CRTStartup crt1.c:244
00401284 cgminer_d.exe:00401284 WinMainCRTStartup crt1.c:274
750433AA kernel32.dll:750433AA BaseThreadInitThunk
77219EF2 ntdll.dll:77219EF2 RtlInitializeExceptionChain
77219EC5 ntdll.dll:77219EC5 RtlInitializeExceptionChain
Trying to compile the new poclbm121016.cl .bin file would then result with this error: cgminer_d.exe caused an Access Violation at location 0042e08c in module cgminer_d.exe Reading from location 00aba637.
Registers:
eax=00aba633 ebx=0058a700 ecx=ffb5c44d edx=00000008 esi=0056fd40 edi=0058a83f
eip=0042e08c esp=0028f4e0 ebp=0028f548 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
Call stack:
0042E08C cgminer_d.exe:0042E08C
0043027F cgminer_d.exe:0043027F
0042D020 cgminer_d.exe:0042D020
00416F8A cgminer_d.exe:00416F8A
004010B9 cgminer_d.exe:004010B9 __mingw_CRTStartup crt1.c:244
00401284 cgminer_d.exe:00401284 WinMainCRTStartup crt1.c:274
750433AA kernel32.dll:750433AA BaseThreadInitThunk
77219EF2 ntdll.dll:77219EF2 RtlInitializeExceptionChain
77219EC5 ntdll.dll:77219EC5 RtlInitializeExceptionChain
This looks completely unrelated to the code and suggests some driver +/- SDK fuckage. I suggest trying a different driver, if you can. |
|
|
|
There's not enough to warrant a new release, but if anyone's keen to try the new poclbm kernel you can download the latest version of the file directly here: https://raw.github.com/ckolivas/cgminer/master/poclbm121016.clRemember to delete any .bin files. Seems to work best with SDK 2.7. Even my NVIDIA cards seem to prefer this kernel. |
|
|
|
That's a whole lot of SC Mini Rig cases. Kind of drives home exactly how high the difficulty is going to skyrocket when BFL gets around to shipping them.
Kano counted 89 MR cases in all... with lots of fans. |
|
|
|
Is it possible to use the existing unique subscription ID as the session ID with mining.resume instead?
Sounds good to me, mine is just hardcoded to "1" at the moment. I'll make it unique when it is actually used for something.  We had a chat about this on IRC and agreed this would be the most seamless conversion without breaking existing clients. If the client gets a different id or enonce1 they assume it didn't resume. |
|
|
|
Thanks. However what if it's the first command after the socket is opened?
Why there should be any exception for first message? If the miner knows any recent session id, it should send mining.resume(id) firstly. If miner don't have any session id, it should send mining.subscribe(). When the pool doesn't understand mining.resume message, it should respond with standard error, not by closing the connection. Is there really any pool which closes the connection on unknown message? I was mistaken. I checked with Eleuthria and he said his pool simply doesn't respond to messages it doesn't recognise. This is a problem for me since I would have to wait for a response to time out and that would not be graceful or efficient. Perhaps for important auth messages I should let cgminer time out relatively quickly like 5 seconds since it really shouldn't take the pool longer than that to respond. |
|
|
|
|
Show Posts
