search

nginnever / zogminer

an OpenCL Zcash GPU miner
MIT License
151 stars 64 forks source link

Stratum spec compliance issues #71

Open sammy007 opened 8 years ago

sammy007 commented 8 years ago

Now idea how that happened since code is almost equal with standalone-miner branch from @str4d

[OPENCL]:Found suitable OpenCL device [Hawaii] with 4267290624 bytes of GPU memory
[OPENCL]:Using platform: AMD Accelerated Parallel Processing
[OPENCL]:Using device: Hawaii(OpenCL 1.2 AMD-APP (2117.7))
[OPENCL]:Printing program log
[OPENCL]:

And stuck for a while.

What happens on interface after zogminer launch:

T 192.168.1.4:47104 -> 192.168.1.4:9999 [AP]
  {"id": 1, "method": "mining.subscribe", "params": ["xxx","9999","/Satoshi:1.0.0-beta2/", null]}.
##
T 192.168.1.4:9999 -> 192.168.1.4:47104 [AP]
  {"id":1,"result":[null,"00000000000000000000000004d166e0"],"error":null}.
##
T 192.168.1.4:47104 -> 192.168.1.4:9999 [AP]
  {"id": 2, "method": "mining.authorize", "params": ["z","x"]}.
##
T 192.168.1.4:9999 -> 192.168.1.4:47104 [AP]
  {"id":2,"result":true,"error":null}.
#
T 192.168.1.4:9999 -> 192.168.1.4:47104 [AP]
  {"id":null,"method":"mining.set_target","params":["15555555555555555555555555555555555555555555555555555555555552"]}.
#
T 192.168.1.4:9999 -> 192.168.1.4:47104 [AP]
  {"id":null,"method":"mining.notify","params":["421199935875670","04000000","ac4cf2bf12ca466155e4ec0125e031cf902e548f554b8cc71dff6ad404000000","3ab3705f4652d99d4dfea241684d0db4355c166ea519d0aa3155cbbc5f822ffe","00000000000
  00000000000000000000000000000000000000000000000000000","bc351a58","2a51061d",true]}.

Everything is smooth here, but miner is still waiting for a job for some reason and don't mine. When new block mined in a network, server will send new job:

T 192.168.1.4:9999 -> 192.168.1.4:47104 [AP]
  {"id":null,"method":"mining.notify","params":["216113020742269","04000000","1e09a17e51090799b6395b05c38b2ceb4ce27f8c705ac09c086d3f6904000000","32b4efadc15fefdf85e38ef3e3187c8de9657cd366f048b822f6bf62c7e88962","00000000000
  00000000000000000000000000000000000000000000000000000","92361a58","bb3c061d",true]}.

And finally zogminer will start mining.

Kernel run took 54 ms. (36.0683 H/s)
Kernel run took 55 ms. (45.6096 H/s)

It MUST not ignore job after set_target but it ignores it.

n1koo commented 8 years ago

Seeing same issue throughout three rigs. Miners crash randomly ( https://github.com/nginnever/zogminer/issues/51 ) within 5min -> few hours, and I got a cronjob to bring them back but this makes the crashes a lot worse.

sanjay-shah commented 8 years ago

@sammy007 I'm seeing the same issue of Miner being stuck for a while during the start. @n1koo Miners were chasing randomly when It was pointed to nicehash. However the random crash has not occurred in last 18 hrs after I pointed to flypool.

sammy007 commented 8 years ago

@sanjay-shah

I'm seeing the same issue of Miner being stuck

Yes because miner skipped job message from pool :(

n1koo commented 8 years ago

@sanjay-shah that would explain it, I was mainly using nicehash. Trying another pool now to see if crashes would get better, but the issue of this issue, pun intended, is actually even worse than the crashes

sammy007 commented 8 years ago

This issue is not about crashes, issue is about stratum protocol compliance. Miner just ignores job from server after mining.authorize request. Spec violation leads to protocol fragmentations, but this is just a bug I guess, zog uses code from so called reference implementation and standalone-miner works well after connection. Both miners has an issue with pool restart when both submit invalid shares, but this is another issue https://github.com/str4d/zcash/issues/14

Compliance is necessary, especially if zog developers are going to spread it to a wide audience via sells of zogOS.