ccminer icon indicating copy to clipboard operation
ccminer copied to clipboard

Stops sending shares (8.13)

Open mlsad3 opened this issue 7 years ago • 18 comments

I have 2 different rigs showing the same issue, one with just a single graphics card, and the other with 6. After a few minutes, it stops submitting shares. Even after 30 minutes, no new shares have been sent. image

Is this a known issue? I didn't see anything similar reading through the subjectlines

mlsad3 avatar Sep 21 '17 02:09 mlsad3

The command being run is: ccminer.exe -a neoscrypt -o stratum+tcp://neoscrypt.us.hashrefinery.com:4233 -u blahblahblah -p myrig,c=BTC

mlsad3 avatar Sep 21 '17 02:09 mlsad3

I have not seen this before. When it stops sending shares, do you still see the lines with the block number once in a while? Did you try a different pool?

KlausT avatar Sep 21 '17 04:09 KlausT

Unfortunately I can't reproduce it anymore. It was consistently happening at the time when I would close it and reopen; but it seems to work again. Also I don't remember if I ever saw the block numbers. I think I did not see any.

mlsad3 avatar Sep 21 '17 05:09 mlsad3

saw that too on altminer pool with vivo mining.change pool to steamoctane.

lyolyalya avatar Sep 21 '17 15:09 lyolyalya

Looks like ccminer doesn't recognize a lost connection to the pool. I didn't notice this behaviour before because my connection is always stable.

KlausT avatar Sep 21 '17 18:09 KlausT

I have this error too. Here it happens when there is micro disconect. Disconnect that stops downloads by browser but does not change navigation. The miner does not show stratum disconect and is processing but does not send share.

wandersonareis avatar Sep 25 '17 02:09 wandersonareis

same problem

FuSeNoob13 avatar Oct 28 '17 17:10 FuSeNoob13

You can repro this by running a bat similar below

:start
ccminer_other.exe -a x17 -o stratum+tcp://x17.mine.ahashpool.com:3737 -u 3HH1XJHnSvKLu1LJgwamWbqVUEP2yTFGxe -p ID=2,c=BTC,x17=66.79,neoscrypt=6.6 -r 0
ccminer.exe -a neoscrypt -o stratum+tcp://neoscrypt.mine.ahashpool.com:4233 -u 3HH1XJHnSvKLu1LJgwamWbqVUEP2yTFGxe -p ID=2,c=BTC,x17=66.79,neoscrypt=6.6 -r 0
goto start
  1. Download KlausT miner
  2. Download https://github.com/tpruvot/ccminer/releases/download/2.2.2-tpruvot/ccminer-x86-2.2.2-cuda9.7z with x17 support (or whatever algo)
  3. Rename Tpruvot's miner to ccminer_other.exe
  4. Copy KlausT miner and Renamed Tpruvot miner to a common directory
  5. Place above script in the common directory
  6. Run script above
  7. Wait until neoscrypt starts mining.
  8. Wait until x17 (or whatever algorithm you want) becomes more profitable (check https://www.ahashpool.com/api/status and multiply the factors in the -p field by 'estimate_current')

Actual: neoscrypt will continue to mine without submitting shares Expected: Since -r 0 is specified as an option on the KlausT miner and the server closed the connection, the miner should quit.

kiLLeen avatar Oct 29 '17 23:10 kiLLeen

Related to #19 #62

kiLLeen avatar Oct 29 '17 23:10 kiLLeen

Looks like I have found the bug that has prevented a reconnect after a connection loss. https://github.com/KlausT/ccminer/commit/3596c1c5dd46675cd54ddd1c33de60cb4d2a566e New binaries for Windows will come soon, I think.

KlausT avatar Nov 06 '17 17:11 KlausT

I am using the new binary. Reproduction steps I mention above still prevent closure of the miner. I get a "...terminating work io thread" and I get a stratum disconnect, but then the miner goes into an infinite loop with "waiting for data..." for each card instead of terminating like the other ccminers.

kiLLeen avatar Nov 18 '17 22:11 kiLLeen

[2017-11-18` 15:23:42] accepted: 406/408 (99.51%), 5458.35 kH/s yay!!!
[2017-11-18 15:23:42] accepted: 407/409 (99.51%), 5458.18 kH/s yay!!!
[2017-11-18 15:23:43] accepted: 408/410 (99.51%), 5458.50 kH/s yay!!!
[2017-11-18 15:23:43] accepted: 409/411 (99.51%), 5458.88 kH/s yay!!!
[2017-11-18 15:23:47] Stratum connection interrupted
[2017-11-18 15:23:47] GPU #4: waiting for data
[2017-11-18 15:23:47] GPU #1: waiting for data
[2017-11-18 15:23:47] GPU #3: waiting for data
[2017-11-18 15:23:47] GPU #5: waiting for data
[2017-11-18 15:23:47] GPU #2: waiting for data
[2017-11-18 15:23:48] ...terminating workio thread
[2017-11-18 15:23:48] workio thread dead, exiting.
[2017-11-18 15:23:48] stopping 5 threads
[2017-11-18 15:23:50] GPU #4: waiting for data
[2017-11-18 15:23:50] GPU #1: waiting for data
[2017-11-18 15:23:50] GPU #3: waiting for data
[2017-11-18 15:23:50] GPU #5: waiting for data
[2017-11-18 15:23:50] GPU #2: waiting for data
[2017-11-18 15:23:53] GPU #4: waiting for data
[2017-11-18 15:23:53] GPU #1: waiting for data
[2017-11-18 15:23:53] GPU #3: waiting for data
[2017-11-18 15:23:53] GPU #5: waiting for data
[2017-11-18 15:23:53] GPU #2: waiting for data
[2017-11-18 15:23:56] GPU #4: waiting for data
[2017-11-18 15:23:56] GPU #1: waiting for data
[2017-11-18 15:23:56] GPU #3: waiting for data
[2017-11-18 15:23:56] GPU #2: waiting for data
[2017-11-18 15:23:56] GPU #5: waiting for data
[2017-11-18 15:23:59] GPU #4: waiting for data
[2017-11-18 15:23:59] GPU #1: waiting for data
[2017-11-18 15:23:59] GPU #3: waiting for data
[2017-11-18 15:23:59] GPU #2: waiting for data
[2017-11-18 15:23:59] GPU #5: waiting for data
[2017-11-18 15:24:02] GPU #4: waiting for data
[2017-11-18 15:24:02] GPU #1: waiting for data
[2017-11-18 15:24:02] GPU #3: waiting for data
[2017-11-18 15:24:02] GPU #2: waiting for data
[2017-11-18 15:24:02] GPU #5: waiting for data
[2017-11-18 15:24:05] GPU #4: waiting for data

kiLLeen avatar Nov 18 '17 23:11 kiLLeen

I have a fix for looping with waiting for data and not exiting, I will put it up in a pull request tomorrow.

[2017-11-19 00:34:09] accepted: 508/515 (98.64%), 6477.19 kH/s yay!!!
[2017-11-19 00:34:11] accepted: 509/516 (98.64%), 6477.30 kH/s yay!!!
[2017-11-19 00:34:13] accepted: 510/517 (98.65%), 6476.86 kH/s yay!!!
[2017-11-19 00:34:14] Stratum connection interrupted
[2017-11-19 00:34:14] GPU #4: waiting for data
[2017-11-19 00:34:14] GPU #0: waiting for data
[2017-11-19 00:34:14] GPU #1: waiting for data
[2017-11-19 00:34:14] GPU #3: waiting for data
[2017-11-19 00:34:14] GPU #2: waiting for data
[2017-11-19 00:34:14] GPU #5: waiting for data
[2017-11-19 00:34:14] ...terminating workio thread
[2017-11-19 00:34:14] workio thread dead, exiting.
[2017-11-19 00:34:15] API failed (No error) - API will not be available

C:\Users\Neil\Desktop\MultiPoolMiner-master>Bin\NVIDIA-Alexis78\ccminer.exe -a nist5 -o stratum+tcp://nist5.mine.ahashpool.com:3833 -u 3HH1XJHnSvKLu1LJgwamWbqVUEP2yTFGxe -p ID=2,c=BTC,d=0.032,neoscrypt=6.5,xevan=21,x17=68,hmq1725=27.78,blake2s=24.61,c11=99,myr-gr=430,tribus=360,nist5=294,skein=3290,timetravel=157,sib=76.5,bitcore=98,lbry=1810,lyra2v2=248,phi=118,hsr=73.4,skunk=187 -r 0 --quiet -d 0,1,2,3,4,5
*** ccminer alexis-1.0 for nVidia GPUs from alexis78@github ***
*** Built with VC++ 2013 and nVidia CUDA SDK 7.5 (Recommended)

*** Based on tpruvot@github ccminer
*** Originally based on Christian Buchner and Christian H. project
*** Include some of the work of djm34, sp, tsiv and klausT.

[2017-11-19 00:34:16] Starting on stratum+tcp://nist5.mine.ahashpool.com:3833
[2017-11-19 00:34:16] NVML GPU monitoring enabled.
[2017-11-19 00:34:16] 6 miner threads started, using 'nist5' algorithm.
[2017-11-19 00:34:16] ...terminating workio thread

kiLLeen avatar Nov 19 '17 08:11 kiLLeen

yes.seems like bug with short connection fail is still there...8.14...

lyolyalya avatar Nov 19 '17 16:11 lyolyalya

The main thread is waiting for the workio thread and doesn't care for the stratum thread. This can be fixed with adding proper_exit() and the end of the stratum_thread function.

Edit: Sorry, what i have said above is probably totally wrong. I still don't understand the whole pthread stuff.

KlausT avatar Nov 19 '17 17:11 KlausT

There is a couple options here which I'll outline in the pull request. Right now, the main thread is awaiting the workers to complete what they are doing. I'm able to leave that mechanism in place, but it is kind of silly unless it is super important to finish the work the threads are currently doing. Option two is just exit the main thread and the workers will follow since the worker threads are in the process space.

Both of the options require that there are no loops in the main thread that ignore proper_exit abort flag. (This is what I have changed)

kiLLeen avatar Nov 19 '17 18:11 kiLLeen

The proper_exit function is waiting for the GPUs because there will be a crash if we just exit while a kernel is running. Other ccminer forks just wait a while before they exit.

KlausT avatar Nov 19 '17 20:11 KlausT

Just ran into this annoying issue. Has it been fixed yet?

If not, any alternatives to use, in the meantime?

joesixpack avatar Dec 14 '17 04:12 joesixpack