Sometimes it happens.
Usually mine start to misbehave as AU# instead of ANU#, but allways power up as ANU#
I've even downgraded to 4.9.2 since they were quite unstable on 4.10.0.
I have mine at 261 but even at 255 they become zombies - do yours run stable at 275?!

Being rejected by the pool is different to getting all rejected shares which is what that is for. There is no command for what you're asking. If you're being rejected by the pool you are having a configuration issue with your pool setup, or your pool is shit.

All of the sudden the is inactive, although it's listed as shown in the attached, how do I fix this?

https://imgur.com/a/8aeO0

Hello,

I installed my own bitcoin mining pool using unomp (ubuntu VM) and I now try to run cgminer to test GPU mining on it.

I am new in mining, and do not manage to make cgminer run...

Here is my actual .bat



and my cgminer.conf file :



But I got errors :
 
[2018-02-20 13:16:14] Init GPU thread 0 GPU 0 virtual GPU 0
 [2018-02-20 13:16:14] CL Platform vendor: NVIDIA Corporation
 [2018-02-20 13:16:14] CL Platform name: NVIDIA CUDA
 [2018-02-20 13:16:14] CL Platform version: OpenCL 1.2 CUDA 9.1.92
 [2018-02-20 13:16:14] List of devices:
 [2018-02-20 13:16:14]  0       GeForce GTX 1050 Ti
 [2018-02-20 13:16:14] Selected 0: GeForce GTX 1050 Ti
 [2018-02-20 13:16:14] Selecting scrypt kernel
 [2018-02-20 13:16:14] Initialising kernel scrypt130511.cl without bitalign, 1 vectors and worksize 256
 [2018-02-20 13:16:14] Maximum buffer memory device 0 supports says 1073741824
 [2018-02-20 13:16:14] Your scrypt settings come to 1608908800
 [2018-02-20 13:16:14] initCl() finished. Found GeForce GTX 1050 Ti
 [2018-02-20 13:16:14] 1 gpu miner threads started
 [2018-02-20 13:16:14] Work update message received
 [2018-02-20 13:16:14] Network diff set to 3.01T
 [2018-02-20 13:16:14] New block: 0000000000000000005cabc1047747a12e81bcd18bdb7e8e41e6a4a1ed450244... diff 3.01T
 [2018-02-20 13:16:16] Error: clEnqueueReadBuffer failed error -5. (clEnqueueReadBuffer)
 [2018-02-20 13:16:16] GPU 0 failure, disabling!
 [2018-02-20 13:16:24] ALL (10s):0.000 (avg):0.000h/s | A:0  R:0  HW:0  WU:0.0/m
 [2018-02-20 13:16:32] Work update message received
 [2018-02-20 13:16:34] ALL (10s):0.000 (avg):0.000h/s | A:0  R:0  HW:0  WU:0.0/m

I use CGMiner 3.7.2 and I have a NVIDIA 1050 TI

What did I miss?

Thank you for your help,

Alex

I hope this isn't a dumb question...

Going through some of my debug logs, I noticed that the generated stratum header has the version like this:

[2018-02-15 23:08:23.772] Generated stratum header 20000000ed37665c908b8f6b9120d09918afa1ef1c3bd3fa0024d3f700000000000000005fb360c99001606 f4f9aeb9293c5776d6e3e666adf0e6dacdbb9526ae3561fa95a86592f1761e9f800000000000000 8000000000000000000000000000000000000000000000000000000000

Shouldn't it be like this?:

[2018-02-15 23:08:23.772] Generated stratum header 00000020ed37665c908b8f6b9120d09918afa1ef1c3bd3fa0024d3f700000000000000005fb360c99001606 f4f9aeb9293c5776d6e3e666adf0e6dacdbb9526ae3561fa95a86592f1761e9f800000000000000 8000000000000000000000000000000000000000000000000000000000

I didn't see anywhere in the code where the bbversion was reversed.  Unless I missed it.  I did see some previous posts from way back where the block version is shown in the logs like my second example.  

The version gets put in the header_bin as in the first example, not reversed.    Raw block headers have the version reversed and when test hashed, produce the correct hashes.

Thanks,

-Ken

Thanks ck!

My question was geared more towards how the version is placed into header_bin, pool->header, and eventually work->data prior to being hashed.

The older block you listed gets hashed as:  https://blockchain.info/block/00000000000000001ed61d4b7dd337c8eb1de0f21a0bd310a8733fb35f21991cformat=hex
02000000ea7ee4542a0d7496954302e67b99a4d1a3d1c2724f8ddb1a00000000000000007d28ed3cb6e06dc df8267afaa908999d48f2d4deba94b4e344c3e126a3c8b00b174e1f54e9db2418e5bc702

The newer as (and current blocks):  https://blockchain.info/block/00000000000000000077140243064000ba35b22d3e2440e936a722b90cd09365?format=hex
00000020633a9073c5b1a5f32afefa4c1116c5bb9c593dfa419812000000000000000000515b81eeca6c575 93c90264ee1a1cb581fc3b7052e8adc23ec16db9917cf828bd33d575ac19100184dbccd28

Current blocks manually double sha256 hashed give correct results with the second format.

I guess I am not seeing in the code where the version is flipped after it is placed in as "20000000" prior to being hashed.

Thanks again for your help!

-Ken

Dragonmint T1 driver and asicboost rolling support for cgminer is now part of the public master cgminer code.

https://github.com/ckolivas/cgminer/commit/e7128f35d9b5ba816113e7f959aba47c6a870a3b

Yes

No.

Then you're asking for help in the wrong place.

The mempool snapshot is done at the server level in the bitcoin daemon which is handed off to the mining pool, about once per minute so they're always up to date. Cgminer is at the client end and does not do any of this unless you are solo mining with it.