XMR closing

[sirmamay]

Hi, I got a 4 1060 6gb rig, trying to mine sumokoins, but I cant seem to make it work.

I mean, it starts mining, and it stays fine for a few minutes, then out of nowhere it closes without letting me see what error was it.

Heres the gpu threads part of the config. Been playing around with the first one since I saw that might be the problem, but still cant make it stay mining.

"gpu_threads_conf" : [ { "index" : 0, "threads" : 20, "blocks" : 10, "bfactor" : 8, "bsleep" : 100, "affine_to_cpu" : false, }, { "index" : 1, "threads" : 64, "blocks" : 30, "bfactor" : 8, "bsleep" : 100, "affine_to_cpu" : false, }, { "index" : 2, "threads" : 64, "blocks" : 30, "bfactor" : 8, "bsleep" : 100, "affine_to_cpu" : false, }, { "index" : 3, "threads" : 64, "blocks" : 30, "bfactor" : 8, "bsleep" : 100, "affine_to_cpu" : false, }, ],

what could the problem be? I have no clue. Also, how do you check the thread and block count? Cant seem to find anything about that either.

Thanks!

[MiningGit]

Same problem here, mines for about 5 minutes then closes by itself. Have no idea why

[MiningGit]

Reading through other threads the devs have suggested changing the bfactor value to 6 or 7, but with your setup not sure if this is good advice or not

[sirmamay]

I've actually tried that and it still closes. But now the problem is that Windows has blocked the app from accessing the graphics hardware it say. Wasn't able to fox that so o went with ccminer for the moment. Hoping someone can help me out.

[auroracoin]

Maybe it has something to do with timeout... just trying to help. I don't care for this type of miner. I did notice with xmrminer and the pool that the difficulty gets so high that the miner freezes for 60 seconds sometimes before the next accept.

From read me file.

• Network timeouts.
  • Because of the way this client is written it doesn't need to constantly talk (keep-alive) to the server to make
  • sure it is there. We detect a buggy / overloaded server by the call timeout. The default values will be ok for
  • nearly all cases. If they aren't the pool has most likely overload issues. Low call timeout values are preferable -
  • long timeouts mean that we waste hashes on potentially stale jobs. Connection report will tell you how long the
  • server usually takes to process our calls.
  • call_timeout - How long should we wait for a response from the server before we assume it is dead and drop the connection.
  • retry_time - How long should we wait before another connection attempt.
  • Both values are in seconds.
  • giveup_limit - Limit how many times we try to reconnect to the pool. Zero means no limit. Note that stak miners
  • don't mine while the connection is lost, so your computer's power usage goes down to idle. */ "call_timeout" : 10, "retry_time" : 10, "giveup_limit" : 0,

[LDibiase]

Same problem here with a GTX 1070. I cached some information in the event viewer. Hope it helps.

Application

Fault bucket LKD_0x141_Tdr:6_IMAGE_nvlddmkm.sys_Pascal_DmaCopy0, type 0 Event Name: LiveKernelEvent Response: Not available Cab Id: 76ff6e3f-8b81-4b73-8fff-2a2d379c6c62

Problem signature: P1: 141 P2: ffffcd869c38a4a0 P3: fffff8021e73647c P4: 0 P5: 658 P6: 10_0_15063 P7: 0_0 P8: 256_1 P9: P10:

System

Warning Display driver nvlddmkm stopped responding and has successfully recovered.

Regards, Lucas.

[sirmamay]

Hmm. Interesting, it does that a lot in my case. I've moved to another miner client (ccminer) and it's been working great but this problem persists. I've found that the keepalive option made the miner not to disconnect but what you says worries me. Maybe I shouldn't keep it alive if it's a stale share. The question is how to tell if it is?

Thanks for your comment !

El 9 oct. 2017 1:16 PM, "auroracoin" notifications@github.com escribió:

Maybe it has something to do with timeout... just trying to help. I don't care for this type of miner. I did notice with xmrminer and the pool that the difficulty gets so high that the miner freezes for 60 seconds.

From read me file.

• Network timeouts.

• Because of the way this client is written it doesn't need to constantly talk (keep-alive) to the server to make

• sure it is there. We detect a buggy / overloaded server by the call timeout. The default values will be ok for

• nearly all cases. If they aren't the pool has most likely overload issues. Low call timeout values are preferable -

• long timeouts mean that we waste hashes on potentially stale jobs. Connection report will tell you how long the

• server usually takes to process our calls.

• call_timeout - How long should we wait for a response from the server before we assume it is dead and drop the connection.

• retry_time - How long should we wait before another connection attempt.

•       Both values are in seconds.

• giveup_limit - Limit how many times we try to reconnect to the pool. Zero means no limit. Note that stak miners

•       don't mine while the connection is lost, so your computer's power usage goes down to idle.

*/ "call_timeout" : 10, "retry_time" : 10, "giveup_limit" : 0,

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fireice-uk/xmr-stak-nvidia/issues/146#issuecomment-335243261, or mute the thread https://github.com/notifications/unsubscribe-auth/AfDivk4p7MxQqA8mNoTO8xzi9dWMsonOks5sqmLjgaJpZM4PwFFO .

[psychocrypt]

@Lucas it looks like windows killed the miner because the kernel runs to long. Please increase bfactor or reduce threads or blocks.

[LDibiase]

Thanks @psychocrypt ! Now the application does not close and runs more stable.