ZECMiner
ZECMiner copied to clipboard
Genoil
0.0S/s
Looks like everything is running fine, except no Sols...
Genoil's ZEC miner 0.4 - ft. Silent Army
using Silent Army kernels by mrb
Made possible by tromp, ocminer (suprnova), feeleep (coinmine.pl) and 110GH
Thanks for your donation! (BTC) Silent Army: 1DbGfE695VUs3kcsy6cX6sLjTmsPawmwvj Genoil : 1Nu2fMCEBjmnLzqb8qUJpKgq5RoEWFhNcW
Using OpenCL platform: AMD Accelerated Parallel Processing gpu#0: Pitcairn gpu#1: Pitcairn zec-sa#0 compiling kernels/zec-sa.cl... zec-sa#0zec-sa#1 compiling kernels/zec-sa.cl...: zconn Connecting to us1-zcash.flypool.org:3333 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zconn Connected! zconn subscribed zconn received new job #a430afc512e8b3a161fb zec-sa#0 writing binary kernels/cache/zec-sa-Pitcairn-64.bin zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#1 writing binary kernels/cache/zec-sa-Pitcairn-64.bin zconn received new job #caf65a909f4c5f0e5166 zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zconn received new job #7cdefbaeb6c9ed0b3999 zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s
I left it running for about 10 minutes with no change.
I have the same issue. I checked the GPU it showing 100% usage, but it doesn't look like anything is getting sent back to the pool.
Same here also reporting same error
zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zconn received new job #91 zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s zec-sa#0: 0.0S/s zec-sa#1: 0.0S/s total: 0.0S/s
I can confirm that GPU usage goes to 99-100%, but still 0.0S/s - even with the 4.1 release.
Pitcairn & Tahiti (GCN1.1) won't work. Kernel author @mbevand is looking into this. I might as well :)
After I connected to a pool I see 0 sol/s then after new job from pool (when new block found in network) it starts hashing. Very strange.
Looks like after mining.authorize first mining.notify is ignored for some reason.
2016/10/30 12:42:59 Stratum miner subscribe
2016/10/30 12:42:59 Stratum miner authorization request z:z
2016/10/30 12:42:59 Stratum miner subscribe <- WTF?!
@Genoil Why miner trying to subscribe 2 times in a row?
Protocol Flow
Client sends mining.subscribe to set up the session. Server replies with the session information. Client sends mining.authorize for their worker(s). Server replies with the result of authorization. Server sends mining.set_target. Server sends mining.notify with a new job. Client mines on that job. Client sends mining.submit for each solution found. Server replies with whether the solution was accepted. Server sends mining.notify again when there is a new job.
https://github.com/str4d/zips/blob/77-zip-stratum/drafts/str4d-stratum/draft1.rst
Yeah that double subscribe is a bit of a hack to get a job pushed quicker. I asked ocminer and feeleep to push me a new job immediately after auth, but for some reason they wouldn't.
So they both violate spec then, flow is simple, must set_target followed by notify right after authorize.
@Genoil your miner sends 2nd subscribe regardless received it job after first auth or no, my software works correctly and pushing target followed by new job immediately after authorization request, but your miner still ignores it and only hashing after new job appears on pool and new notification sent.
{"id": 1, "method": "mining.subscribe", "params": ["xxx.xxx",5555, "genoil+tromp/0.1", "NULL"]}.
##
{"id":1,"result":[null,"00000000000000000000000003e63fe4"],"error":null}.
##
{"id": 3, "method": "mining.authorize", "params": ["z","z"]}.
#
{"id":3,"result":true,"error":null}.
#
{"id":null,"method":"mining.set_target","params":["7ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0"]}.
#
{"id":null,"method":"mining.notify","params":["523333875480617","04000000","219e2bfc7b803f691815d242f3e026ddf93f853a8ff648f62f17af8304000000","c3d7e26bcf8159f42ccfba9cc34144459bda45095c747e31a9989fffaf27398a","00000000000
00000000000000000000000000000000000000000000000000000","e6b51558","cba30b1d",true]}.
#
......
#
{"id": 1, "method": "mining.subscribe", "params": ["xxx.xxx",5555, "genoil+tromp/0.1", "NULL"]}.
#
{"id":1,"result":[null,"00000000000000000000000003e63fe5"],"error":null}.
So simply your miner work with both broken stratums and does not work with correct.
@Genoil - indeed my code is wrong, but now when i fixed it you miner will behave like sammy007 wrote. Will try to hack my end to send it twice until your code is done.
Solution is simple, wait for nonce on subscribe reply and wait for target and job after authorize. We don't need 10 fragmented stratums like in shitereum.
@Genoil - if you want a hack-around for broken servers/proxies then why not setting some timer ? If you did not obtained job in, say, 2 secs after authorization, then issue the redundant subscribe or something.
Are there keep-alive null packets in stratum protocol, or it wholly rely on TCP-level keep-alives ?
No one says "correct server is bad". But "working even with bad servers is good".
Look, there are HTML and XHTML. The main difference is exactly this very "OMG".
HTML claims: in real world there are incorrect badly authored pages, the browser still should extract and present to user as much info as salvagable. XHTML claims: in real world there are NO incorrect badly authored pages, if you somehow met one - drop it at once.
The WEB is created of many less than 100% correct HTML pages and few XHTML niches.
Fuck you idiot and your broken connections with HTML. There is correct spec even @slush0 like it.
There are correct specs for HTML, XML, XHTML. And everyone likes it.
But 99% of people are idiots reading WWW via adaptable browsers to have the job done, and only sammy007 is reading it via W3C validators to keep himself pristine.
I understand your desire to ban all the stratum servers that you don't like. I just cannot understand why should it be Genoil and his users paying for YOUR agenda.
This very page violates HTML specs 48 times. We all should immediately cease any work on ZCash miners on GitHub until GitHub admins fix their part and come back to the holy specs compliance and let us be consistent and prohibit any software that dares recovering from server-side specs violations allows its idiotic users to read this very page.
Oh, LOL....
@the-Arioch it is just called doing things the proper way, this is called standardization, where we all agree on a set of rules and develop based on that, so we can expect the same result and behavior so we don't waste time arguing about these things.
@mmitech you are trying to crash into the door open long ago. No one says Genoil should not work with correct servers, you are arguing with your own ghost here. What I say is that Genoil should NOT be prohibited from working with less than correct servers.
Otherwise - what are you even doing in this non-standard specs-violating www-page ? Be consistent and wait until GitHub fixes it before touching it.
@the-Arioch true, Genoil is NOT prohibited from working with less than correct server, assuming this doesn't break functionality with correct servers, which is the whole point about this issue.
Last 27 minutes you and Sammy exactly argue that he SHOULD be prohibited. Otherwise there would be n-o-t-h-i-n-g to argue about. But since you both keep arguing then it necessarily means you want to prevent him from making software capable of errors recovering for the benefits of his users. There is just no third option.
At this point I have no Idea where did you get this assumption from, we are reporting an issue and discussing ways this could be resolved based on the right stratum documentation, we appreciate the work genoil and everyone is doing, we just don't wish to end up with 100 stratum implementation like Ethereum, until now stratum was/is straight forward and always worked under one documentation, until Ethereum came out...
discussing ways this could be resolved
Sammy is "discussing" that Genoil should follow the specs in the strictest possible way, making only 100% correct servers work: when I suggest an approach that would hopefully both work with correct servers and still provide a hack-around for less than correct ones, Sammy makes a fuss and says only idiots deviate from his One True Way to accommodate to dirty server's faults.
And that is THE ONLY point of the discussion between me and him going for last 40 minutes. There are just NO any other points.
You joined into that discussion on Sammy's side, which means you share his point, that only 100%-compliant servers should be cared for and only idiots can search for ways to enable compatibility with less than 100% compliant server.
Well, you are taking this personally, I agree with Sammy for obvious reasons, the shit we had to go through with a 100 stratum implementation with Ethereum is just unbelievable, while all other coins (for example Bitcoin) have clear and straight forward stratum implementation. we didn't have to mess with 10 different miners and 20 different pool implementation.
It should by obvious by now that we want to have it the correct way since we are really at the very begging, anyone making software that doesn't follow the documentation should reconsider now, probably no one is going to reconsider if they don't get left behind with a broken implementation.
BTW, the OP issue is a different issue, after adding the Genoil quirks, we still get 0 sols on R9 280x and R9 480x, same as OP.
@sammy007 can you open a separate issue for this?
Regarding the OP question, GCN 1.0 doesn't work currently.
@mmitech Well, "idiot" is personal, is it not? And while you say about discussing technical issues - but there was none.
BTW, the OP issue is a different issue
Fair point. Gladly this offtopic issue was addressed finally. Well, I am not convinced with some network-related points you made above, but would not pursue them here.
Maybe there would be a point to make test build with enabling OpenCL/CPU devices, to see if the problem lies within GPU hardware expectations or with AMD/Intel OpenCL stacks themselves
Issue resolved for my Pitcairn gpu's in the v0.5 release. Issue may be closed once secondary issues in the thread are satisfied.