Pages:
Author

Topic: [ANN][POOL] ZERGPOOL.com - Multialgo, autoexchange, 0.5% fee, 250+ coins - page 3. (Read 57448 times)

member
Activity: 1022
Merit: 19
I have a question though. I'm getting an error about duplicate jobs when mining the algo kawpow with xmrig:

That shouldn't be an error, I see no reason for the miner to check it. If the duplicate job was treated as any other job it would work.
Whether the pool shoud not send the same job twice is a trivial issue.

Edit: after further thought my opinion is the miner is at fault here. The issue should be raised with the xmrig devs.

When the miner starts there is a race condition between the miner threads and the stratum thread receiving the first job from the pool.
Sometimes the miner threads start hashing before the first job which could result in the miner crashing, submitting invalid hash based on
hashing random data, or it may go completely unoticed.

I have seen this problem and have fixed it in cpuminer-opt by adding a first job flag so the miner threads will wait until the first job is received
before they start hashing. I also saw this problem with verthash miner and open an issue https://github.com/CryptoGraphics/VerthashMiner/issues/32
but no action has been taken.

It seems kawpow may have tried to solve the issue by sending the first job automatically at login to speed things up. Resending it should not be a
problem. It's effectively a NULL change and a NULL change should never be an error.

Just my opinion.


I was also in contact for verthash miner in discord, for the same issue. But never got any reply, unfortunately. Had to introduce artificial waiting time at pool side for the first job.

newbie
Activity: 35
Merit: 0
Hello! Please help me set up mining for your pool.

I mine on Hive OS. I have all NVidia cards. When mining, I use lolMiner (SRBMiner is unfortunately not suitable). The main coin for mining is ETC + ZIL. I would like to set up a third coin (on your pool). This coin is oBTC. But I can't figure out how to correctly register it in lolMiner...

I'm trying to write like this:
--ethstratum ETHPROXY
--dualmode KASPADUAL
--dualpool stratum+tcp://heavyhash.eu.mine.zergpool.com:5137
--dualuser myETH address
--dualpass c=ETH,mc=OBTC,pl=0.06,ID=Rig-01

I use KASPADUAL because the KASPA coin also belongs to the heavyhash algorithm.

But, unfortunately, nothing works for me... I am getting this error:
Code:
DNS over HTTPS resolve failed - switching to standard resolve
Connected to heavyhash.eu.mine.zergpool.com(141.95.55.97):5137  (TLS disabled)
Authorized worker: my ETH address
New target received: 000000007fffffff (Diff 2)
Warning: index out of bounds
Lost connection to stratum server heavyhash.eu.mine.zergpool.com:5137 or server not reachable.
Trying to connect in 5 second(s)

Maybe I need to set up another miner (not lolMiner), but I'm pretty bad at it...

Thank you in advance for your help!
hero member
Activity: 1008
Merit: 960
I have a question though. I'm getting an error about duplicate jobs when mining the algo kawpow with xmrig:

That shouldn't be an error, I see no reason for the miner to check it. If the duplicate job was treated as any other job it would work.
Whether the pool shoud not send the same job twice is a trivial issue.

Edit: after further thought my opinion is the miner is at fault here. The issue should be raised with the xmrig devs.
~snip~
I had a look at the xmrig source code and found that it closes the connection when it receives a duplicate job from a pool.

There's no real reason to do that in this case so I just commented out that part of the code and tested it.

After that change, xmrig works fine mining kawpow with zergpool even though the pool sends a duplicate job.

So it is safe to assume this is an xmrig issue, not a zergpool one.
full member
Activity: 1397
Merit: 221
I have a question though. I'm getting an error about duplicate jobs when mining the algo kawpow with xmrig:

That shouldn't be an error, I see no reason for the miner to check it. If the duplicate job was treated as any other job it would work.
Whether the pool shoud not send the same job twice is a trivial issue.

Edit: after further thought my opinion is the miner is at fault here. The issue should be raised with the xmrig devs.

When the miner starts there is a race condition between the miner threads and the stratum thread receiving the first job from the pool.
Sometimes the miner threads start hashing before the first job which could result in the miner crashing, submitting invalid hash based on
hashing random data, or it may go completely unoticed.

I have seen this problem and have fixed it in cpuminer-opt by adding a first job flag so the miner threads will wait until the first job is received
before they start hashing. I also saw this problem with verthash miner and open an issue https://github.com/CryptoGraphics/VerthashMiner/issues/32
but no action has been taken.

It seems kawpow may have tried to solve the issue by sending the first job automatically at login to speed things up. Resending it should not be a
problem. It's effectively a NULL change and a NULL change should never be an error.

Just my opinion.
newbie
Activity: 7
Merit: 4
Great pool, thanks for making it.

I have a question though. I'm getting an error about duplicate jobs when mining the algo kawpow with xmrig:

Quote
[2022-09-13 11:21:11.641]  net      new job from kawpow.mine.zergpool.com:3638 diff 2155M algo kawpow height 2449678
[2022-09-13 11:21:11.641]  net      stratum+tcp://kawpow.mine.zergpool.com:3638 duplicate job received, reconnect
[2022-09-13 11:21:11.641]  net      no active pools, stop mining
[2022-09-13 11:21:11.661]  opencl   READY threads 1/1 (21 ms)
[2022-09-13 11:21:18.694]  net      use pool kawpow.mine.zergpool.com:3638
[2022-09-13 11:21:18.694]  net      new job from kawpow.mine.zergpool.com:3638 diff 2155M algo kawpow height 80232
[2022-09-13 11:21:18.696]  net      new job from kawpow.mine.zergpool.com:3638 diff 2155M algo kawpow height 2449678
[2022-09-13 11:21:18.696]  net      stratum+tcp://kawpow.mine.zergpool.com:3638 duplicate job received, reconnect
[2022-09-13 11:21:18.696]  net      no active pools, stop mining

I'm trying to solo mine ravencoin if that matters. Also tried to solo mine other coins with kawpow but they all give me the same error with xmrig.

Others have seen the same issue for years: https://github.com/xmrig/xmrig/issues/459

I updated to the latest xmrig but the issue remains. Seems like the pool is sending duplicate jobs.

The same happens if I just mine in shared mode, but the error appears a bit later.

Note that other algos work fine in zergpool and xmrig like randomxmonero for example.

Any help would be great, thanks!
newbie
Activity: 4
Merit: 0
Can BTC minimum payout balance be adjusted higher so payout isn't as frequent? What is the max and can we send payout manually after minimum?
member
Activity: 1022
Merit: 19
UPDATE

1. $YERB enabled for mining at ghostrider, @Yerbas_Endeavor
2. $JGC enabled for mining at ghostrider
3. $KAW added to kawpow algorithm, @kawkawcoin
4. $MTBC added to scrypt for mining, @mateable
5. $ONX added to yespower mining
member
Activity: 1022
Merit: 19
kawpow.na.mine.zergpool.com:3638 (for NEOX)  is acting up for few weeks now. Constant time outs, ping between 140-2000ms, stratum errors.


Issues have been resolved
newbie
Activity: 9
Merit: 0
kawpow.na.mine.zergpool.com:3638 (for NEOX)  is acting up for few weeks now. Constant time outs, ping between 140-2000ms, stratum errors.
member
Activity: 1022
Merit: 19
Thanks for detailed debug log. I think I have fixed this issue now on lyra2z. Could you please check it once again from your side now?

I immediately noticed the pool reporting diff = 6, the same as the miner. I'll let it run for a bit to confirm correct targetting.
Will follow up.

Edit: looks good, previously this share would have been rejected for low difficulty:

Code:
[2022-07-17 13:00:25] 15 Submitted Diff 0.024303, Block 2445941, Job 71
[2022-07-17 13:00:25] 15 Accepted 15 S0 R0 B1, 97.131 sec (162ms)

Will the fix solve it for all algos or will each algo need a fix once a problem is identified?

I am in process to analyse which algos were affected, and rolling out bug fix accordingly
full member
Activity: 1397
Merit: 221
Thanks for detailed debug log. I think I have fixed this issue now on lyra2z. Could you please check it once again from your side now?

I immediately noticed the pool reporting diff = 6, the same as the miner. I'll let it run for a bit to confirm correct targetting.
Will follow up.

Edit: looks good, previously this share would have been rejected for low difficulty:

Code:
[2022-07-17 13:00:25] 15 Submitted Diff 0.024303, Block 2445941, Job 71
[2022-07-17 13:00:25] 15 Accepted 15 S0 R0 B1, 97.131 sec (162ms)

Will the fix solve it for all algos or will each algo need a fix once a problem is identified?
member
Activity: 1022
Merit: 19
full member
Activity: 1397
Merit: 221
Did some checks, findings are that pool has issued new difficulty(increased) after 2 submitted shares, but the miner has not yet processed it, sending another work in 3 seconds after the 2nd. Making it fail again newly anticipated difficulty at stratum server side.

We could confirm if you would be able to run the same miner in debug more, so it prints communication messages(must be JSON format).
And also send a bit of logged events after the Low difficulty share error. (e.g. I assume the next log should be about new stratum difficulty arriving from server)

Vardiff will change the difficulty based on the share rate. If that occurs the problem goes away. The problem only occurs on lyra2z with stratum diff 6. You can see in
the logs below the mining.set_difficulty specifies 6 but the web page says 6.4. Anything submitted between 6 & 6.4 is rejected. I've seen it with another
algo but I can't recall which one but it was a different difficulty. The problem is rare because it seems to only occur at one difficulty for each affected
algo. I don't know if any more than 2 algos are affected. You also need a hash rate that will cause vardiff to choose the difficulty that has the
problem.

It looks like 6 is the lowest diff for lyra2z, maybe the lowest diff doesn't match in the pool. I let it run for 20 minutes, one more reject, stratum
diff never changed.


Code:
./cpuminer -a lyra2z -o stratum+tcp://mine.zergpool.com:4553 -u XXX -p c27,c=btc,sd=1 -D -P

         **********  cpuminer-opt 3.19.9  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AVX512, SHA and VAES extensions by JayDDee.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT

CPU: Intel(R) Core(TM) i9-9940X CPU @ 3.30GHz
SW built on Jul 12 2022 with GCC 9.3.0
CPU features:  AVX512  AES
SW features:   AVX512  AES
Algo features: AVX512

Starting miner with AVX512...

[2022-07-17 02:55:59] CPU affinity [!!!!!!!!!!!!!!!!!!!!!!!!!!!!]
[2022-07-17 02:55:59] Creating stratum thread
[2022-07-17 02:55:59] Stratum connect stratum+tcp://mine.zergpool.com:4553
[2022-07-17 02:55:59] Threads restarted for new work.
[2022-07-17 02:55:59] Default miner thread priority 0 (nice 19)
*   Trying 103.249.70.7:4553...
* TCP_NODELAY set
* Connected to mine.zergpool.com (103.249.70.7) port 4553 (#0)
* Connection #0 to host mine.zergpool.com left intact
[2022-07-17 02:55:59] > {"id": 1, "method": "mining.subscribe", "params": ["cpuminer-opt/3.19.9"]}
[2022-07-17 02:55:59] < {"id":1,"result":[[["mining.set_difficulty","64"],["mining.notify","16a6524c2c668b573c65f6a15f0343c3"]],"8101adb2",4],"error":null}
[2022-07-17 02:55:59] Stratum session id: 16a6524c2c668b573c65f6a15f0343c3
[2022-07-17 02:55:59] Stratum extranonce1 0x8101adb2, extranonce2 size 4
[2022-07-17 02:55:59] > {"id": 2, "method": "mining.authorize", "params": ["XXX", "X"]}
[2022-07-17 02:55:59] < {"id":2,"result":true,"error":null}
[2022-07-17 02:55:59] > {"id": 3, "method": "mining.extranonce.subscribe", "params": []}
[2022-07-17 02:56:00] < {"id":null,"method":"mining.set_difficulty","params":[6]}
[2022-07-17 02:56:00] Stratum connection established
[2022-07-17 02:56:00] < {"id":null,"method":"mining.notify","params":["31672","7210f86e98886f2ad5af03c27207f9d129c41cba4d4c6ba333169d0ec96cc14a","02000000010000000000000000000000000000000000000000000000000000000000000000ffffffff1f03c64c0d0475b2d36208","7a657267706f6f6c2e636f6d0000000000020000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf900f902950000000017a91459dd91ee761d256af824aba2229aaa94a3d7b8f58700000000",[],"60000000","1b5bb148","62d3b264",true]}
[2022-07-17 02:56:00] CPU temp: curr 40 C max 0, Freq: 1.200/1.509 GHz
[2022-07-17 02:56:00] Threads restarted for new work.
[2022-07-17 02:56:00] New Stratum Diff 6, Block 871622, Job 31672
                      Diff: Net 714.73, Stratum 6, Target 0.023438
                      TTF @ 560.00 h/s: Block 173y173d, Share 2d01h
[2022-07-17 02:56:00] < {"id":3,"result":true,"error":null}
[2022-07-17 02:56:00] < {"id":null,"method":"mining.notify","params":["31674","8ff5b9bdb44be5d111d517f3cb9c66210eb05e14a1b0e5f95a19b918b089d3e4","02000000010000000000000000000000000000000000000000000000000000000000000000ffffffff1f03664c25047db2d36208","7a657267706f6f6c2e636f6d000000000001c0496e0a000000001976a91490df51a56fd5a9fbe7ea3512de486c77c124b57688ac00000000",[],"20000000","1c2142c6","62d3b26c",true]}
[2022-07-17 02:56:00] Threads restarted for new work.
[2022-07-17 02:56:00] New Block 2444390, Net diff 7.6966, Job 31674
                      Diff: Net 7.6966, Stratum 6, Target 0.023438
                      TTF @ 560.00 h/s: Block 1y1d, Share 2d01h
[2022-07-17 02:56:17] < {"id":null,"method":"mining.notify","params":["31676","6afe57fc8493efe1cc421b15e2cfaab91ddee8b2347ae3810ac159b7564cdc5e","02000000010000000000000000000000000000000000000000000000000000000000000000ffffffff1f03674c250491b2d36208","7a657267706f6f6c2e636f6d000000000001c0496e0a000000001976a91490df51a56fd5a9fbe7ea3512de486c77c124b57688ac00000000",[],"20000000","1c2147ce","62d3b280",true]}
[2022-07-17 02:56:17] Threads restarted for new work.
[2022-07-17 02:56:17] New Block 2444391, Net diff 7.6921, Job 31676
                      Diff: Net 7.6921, Stratum 6, Target 0.023438
                      TTF @ 4234.74 kh/s: Block 2h10m, Share 0m23s
[2022-07-17 02:56:18] 1 Submitted Diff 0.097783, Block 2444391, Job 31676
[2022-07-17 02:56:18] > {"method": "mining.submit", "params": ["XXX", "31676", "00000000", "62d3b280", "56eb4b52"], "id":4}
[2022-07-17 02:56:18] Thread 9, Nonce 524beb56, Xnonce2 00000000
[2022-07-17 02:56:18] Data[0:19]: 00000020 fc57fe6a e1ef9384 151b42cc b9aacfe2 b2e8de1d 81e37a34 b759c10a 5edc4c56 822f7b06
[2022-07-17 02:56:18]           : c50cbcd9 ffc202b2 ff05298f e0e05a5a 43c98498 2ba8c440 d634cd75 80b2d362 ce47211c 524beb56
[2022-07-17 02:56:18] Hash[7:0]: 0000000a 3a0d1ef1 d767f69a c51fb4fb cdee6a46 244caedf 33e90ce9 a706f2eb
[2022-07-17 02:56:18] Targ[7:0]: 0000002a aaaaaaaa aaaa0000 00000000 ffffffff ffffffff ffffffff ffffffff
[2022-07-17 02:56:18] < {"id":4,"result":true,"error":null}
[2022-07-17 02:56:18] 1 Accepted 1 S0 R0 B0, 19.309 sec (166ms)
                      Diff 0.097783, Block 2444391, Job 31676
[2022-07-17 02:56:55] < {"id":null,"method":"mining.notify","params":["31677","231d9a1408114d11262e9cdd2d40e167384310e1d7f013eeffdc0277fb6c1a97","02000000010000000000000000000000000000000000000000000000000000000000000000ffffffff1f03684c2504b7b2d36208","7a657267706f6f6c2e636f6d000000000001c0496e0a000000001976a91490df51a56fd5a9fbe7ea3512de486c77c124b57688ac00000000",[],"20000000","1c21491c","62d3b2a6",true]}
[2022-07-17 02:56:55] Threads restarted for new work.
[2022-07-17 02:56:55] New Block 2444392, Net diff 7.6909, Job 31677
                      Diff: Net 7.6909, Stratum 6, Target 0.023438
                      TTF @ 4473.65 kh/s: Block 2h03m, Share 0m22s
[2022-07-17 02:57:10] > {"method": "mining.submit", "params": ["XXX", "31677", "00000000", "62d3b2a6", "a2346f12"], "id":4}
[2022-07-17 02:57:10] 2 Submitted Diff 0.024655, Block 2444392, Job 31677
[2022-07-17 02:57:10] Thread 2, Nonce 126f34a2, Xnonce2 00000000
[2022-07-17 02:57:10] Data[0:19]: 00000020 149a1d23 114d1108 dd9c2e26 67e1402d e1104338 ee13f0d7 7702dcff 971a6cfb ffc9a71a
[2022-07-17 02:57:10]           : daa10652 8fda9673 454daeb4 85c82321 cbe29727 4fd90a69 45ba4d67 a6b2d362 1c49211c 126f34a2
[2022-07-17 02:57:10] Hash[7:0]: 00000028 8f1a0b53 00a8cb64 5560440f 7ba90cbe 5cfe280c 3d90646b fe49ecf7
[2022-07-17 02:57:10] Targ[7:0]: 0000002a aaaaaaaa aaaa0000 00000000 ffffffff ffffffff ffffffff ffffffff
[2022-07-17 02:57:10] < {"id":4,"result":false,"error":[26,"Low difficulty share",null]}
[2022-07-17 02:57:10] 2 A1 S0 Rejected 1 B0, 52.211 sec (164ms)
                      Diff 0.024655, Block 2444392, Job 31677
[2022-07-17 02:57:10] Reject reason: Low difficulty share
                      Hash:   000000288f1a0b5300aa000000000000ffffffffffffffff
                      Target: 0000002aaaaaaaaaaaaa000000000000ffffffffffffffff
[2022-07-17 02:57:14] > {"method": "mining.submit", "params": ["XXX", "31677", "00000000", "62d3b2a6", "15972f80"], "id":4}
[2022-07-17 02:57:14] 3 Submitted Diff 0.039369, Block 2444392, Job 31677
[2022-07-17 02:57:14] Thread 14, Nonce 802f9715, Xnonce2 00000000
[2022-07-17 02:57:14] Data[0:19]: 00000020 149a1d23 114d1108 dd9c2e26 67e1402d e1104338 ee13f0d7 7702dcff 971a6cfb ffc9a71a
[2022-07-17 02:57:14]           : daa10652 8fda9673 454daeb4 85c82321 cbe29727 4fd90a69 45ba4d67 a6b2d362 1c49211c 802f9715
[2022-07-17 02:57:14] Hash[7:0]: 00000019 669e5188 dc9b1ce3 445a5404 c26590b4 fcbd197e 12918b98 1ef90dee
[2022-07-17 02:57:14] Targ[7:0]: 0000002a aaaaaaaa aaaa0000 00000000 ffffffff ffffffff ffffffff ffffffff
[2022-07-17 02:57:14] < {"id":4,"result":true,"error":null}
[2022-07-17 02:57:14] 3 Accepted 2 S0 R1 B0, 3.941 sec (164ms)
                      Diff 0.039369, Block 2444392, Job 31677
[2022-07-17 02:57:27] > {"method": "mining.submit", "params": ["1FXaRoufZC6LyPzjNrs7wS47tpgzEpBSiw", "31677", "00000000", "62d3b2a6", "f9f14dc0"], "id":4}
member
Activity: 1022
Merit: 19
I have noticed on some occasions that the pool stratum difficulty doesn't match the miner.
It seems to only happen for certain algos and certain difficulties.

I'm seeing it right now on lyra2z. The pool is operating at diff 6.2 but he miner says it's 6.
This result in some low difficulty shares when the submitted share diff is between 6 and 6.2.
The rejected shares are mostly noise and don't affect performance.

I have not noticed the pool difficulty being lower than the miner but that would be a silent error
not easilly noticed. This would result in lost performance because the miner would discard shares
that would be accepted by the pool.

Changing stratum difficulty sometimes resolves the issue unless vardiff changes it back.

I had used sd=1 on the command line, stratum responded with 6 but the pool used 6.2.
I tried with sd=6.2 but stratum still responed with 6.

I tried sd=8 and it was accepted, both the stratum response and the pool said 8 as they should.
But vardiff stepped in and lowered the diff and they mismatched again.


Would like to investigate this issue more, if you could confirm above scenario was done on lyra2z? what miner did you use?
If possible reach me out in discord for more details. (e.g. wallet URL and time frame, so I can search in logs).

Sorry for coming with delay, not checking forum as frequently as other zergpool support channels


Didn't take long to reproduce. No discord, check PM for wallet details. Timezone is UTC-4.

Code:
./cpuminer -a lyra2z -o stratum+tcp://mine.zergpool.com:4553 -u x  -p c=btc,sd=6

         **********  cpuminer-opt 3.19.9  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AVX512, SHA and VAES extensions by JayDDee.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT

CPU: Intel(R) Core(TM) i9-9940X CPU @ 3.30GHz
SW built on Jul 12 2022 with GCC 9.3.0
CPU features:  AVX512  AES
SW features:   AVX512  AES
Algo features: AVX512

Starting miner with AVX512...

[2022-07-16 15:06:01] CPU affinity [!!!!!!!!!!!!!!!!!!!!!!!!!!!!]
[2022-07-16 15:06:01] Stratum connect stratum+tcp://mine.zergpool.com:4553
[2022-07-16 15:06:01] 28 of 28 miner threads started using 'lyra2z' algorithm
[2022-07-16 15:06:01] Stratum extranonce1 0x8101aa9f, extranonce2 size 4
[2022-07-16 15:06:02] Stratum connection established
[2022-07-16 15:06:02] CPU temp: curr 43 C max 0, Freq: 1.200/1.201 GHz
[2022-07-16 15:06:02] New Stratum Diff 6, Block 871343, Job 30ed0
                      Diff: Net 815.85, Stratum 6, Target 0.023438
                      TTF @ 560.00 h/s: Block 198y198d, Share 2d01h
[2022-07-16 15:06:04] New Block 2443568, Net diff 6.4418, Job 30ed2
                      Diff: Net 6.4418, Stratum 6, Target 0.023438
                      TTF @ 2554.88 kh/s: Block 3h00m, Share 0m39s
[2022-07-16 15:06:45] 1 Submitted Diff 0.040106, Block 2443568, Job 30ed2
[2022-07-16 15:06:45] 1 Accepted 1 S0 R0 B0, 43.750 sec (160ms)
[2022-07-16 15:06:54] 2 Submitted Diff 0.025962, Block 2443568, Job 30ed2
[2022-07-16 15:06:54] 2 Accepted 2 S0 R0 B0, 9.543 sec (158ms)
[2022-07-16 15:06:57] 3 Submitted Diff 0.024287, Block 2443568, Job 30ed2
[2022-07-16 15:06:57] 3 A2 S0 Rejected 1 B0, 2.446 sec (162ms)
                      Diff 0.024287, Block 2443568, Job 30ed2
[2022-07-16 15:06:57] Reject reason: Low difficulty share
                      Hash:   000000292cbdd9322c0a000000000000ffffffffffffffff
                      Target: 0000002aaaaaaaaaaaaa000000000000ffffffffffffffff
[2022-07-16 15:07:11] New Work: Block 2443568, Net diff 6.4418, Job 30ed5


Did some checks, findings are that pool has issued new difficulty(increased) after 2 submitted shares, but the miner has not yet processed it, sending another work in 3 seconds after the 2nd. Making it fail again newly anticipated difficulty at stratum server side.

We could confirm if you would be able to run the same miner in debug more, so it prints communication messages(must be JSON format).
And also send a bit of logged events after the Low difficulty share error. (e.g. I assume the next log should be about new stratum difficulty arriving from server)
full member
Activity: 1397
Merit: 221
I have noticed on some occasions that the pool stratum difficulty doesn't match the miner.
It seems to only happen for certain algos and certain difficulties.

I'm seeing it right now on lyra2z. The pool is operating at diff 6.2 but he miner says it's 6.
This result in some low difficulty shares when the submitted share diff is between 6 and 6.2.
The rejected shares are mostly noise and don't affect performance.

I have not noticed the pool difficulty being lower than the miner but that would be a silent error
not easilly noticed. This would result in lost performance because the miner would discard shares
that would be accepted by the pool.

Changing stratum difficulty sometimes resolves the issue unless vardiff changes it back.

I had used sd=1 on the command line, stratum responded with 6 but the pool used 6.2.
I tried with sd=6.2 but stratum still responed with 6.

I tried sd=8 and it was accepted, both the stratum response and the pool said 8 as they should.
But vardiff stepped in and lowered the diff and they mismatched again.


Would like to investigate this issue more, if you could confirm above scenario was done on lyra2z? what miner did you use?
If possible reach me out in discord for more details. (e.g. wallet URL and time frame, so I can search in logs).

Sorry for coming with delay, not checking forum as frequently as other zergpool support channels


Didn't take long to reproduce. No discord, check PM for wallet details. Timezone is UTC-4.

Code:
./cpuminer -a lyra2z -o stratum+tcp://mine.zergpool.com:4553 -u x  -p c=btc,sd=6

         **********  cpuminer-opt 3.19.9  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AVX512, SHA and VAES extensions by JayDDee.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT

CPU: Intel(R) Core(TM) i9-9940X CPU @ 3.30GHz
SW built on Jul 12 2022 with GCC 9.3.0
CPU features:  AVX512  AES
SW features:   AVX512  AES
Algo features: AVX512

Starting miner with AVX512...

[2022-07-16 15:06:01] CPU affinity [!!!!!!!!!!!!!!!!!!!!!!!!!!!!]
[2022-07-16 15:06:01] Stratum connect stratum+tcp://mine.zergpool.com:4553
[2022-07-16 15:06:01] 28 of 28 miner threads started using 'lyra2z' algorithm
[2022-07-16 15:06:01] Stratum extranonce1 0x8101aa9f, extranonce2 size 4
[2022-07-16 15:06:02] Stratum connection established
[2022-07-16 15:06:02] CPU temp: curr 43 C max 0, Freq: 1.200/1.201 GHz
[2022-07-16 15:06:02] New Stratum Diff 6, Block 871343, Job 30ed0
                      Diff: Net 815.85, Stratum 6, Target 0.023438
                      TTF @ 560.00 h/s: Block 198y198d, Share 2d01h
[2022-07-16 15:06:04] New Block 2443568, Net diff 6.4418, Job 30ed2
                      Diff: Net 6.4418, Stratum 6, Target 0.023438
                      TTF @ 2554.88 kh/s: Block 3h00m, Share 0m39s
[2022-07-16 15:06:45] 1 Submitted Diff 0.040106, Block 2443568, Job 30ed2
[2022-07-16 15:06:45] 1 Accepted 1 S0 R0 B0, 43.750 sec (160ms)
[2022-07-16 15:06:54] 2 Submitted Diff 0.025962, Block 2443568, Job 30ed2
[2022-07-16 15:06:54] 2 Accepted 2 S0 R0 B0, 9.543 sec (158ms)
[2022-07-16 15:06:57] 3 Submitted Diff 0.024287, Block 2443568, Job 30ed2
[2022-07-16 15:06:57] 3 A2 S0 Rejected 1 B0, 2.446 sec (162ms)
                      Diff 0.024287, Block 2443568, Job 30ed2
[2022-07-16 15:06:57] Reject reason: Low difficulty share
                      Hash:   000000292cbdd9322c0a000000000000ffffffffffffffff
                      Target: 0000002aaaaaaaaaaaaa000000000000ffffffffffffffff
[2022-07-16 15:07:11] New Work: Block 2443568, Net diff 6.4418, Job 30ed5
member
Activity: 1022
Merit: 19
I have noticed on some occasions that the pool stratum difficulty doesn't match the miner.
It seems to only happen for certain algos and certain difficulties.

I'm seeing it right now on lyra2z. The pool is operating at diff 6.2 but he miner says it's 6.
This result in some low difficulty shares when the submitted share diff is between 6 and 6.2.
The rejected shares are mostly noise and don't affect performance.

I have not noticed the pool difficulty being lower than the miner but that would be a silent error
not easilly noticed. This would result in lost performance because the miner would discard shares
that would be accepted by the pool.

Changing stratum difficulty sometimes resolves the issue unless vardiff changes it back.

I had used sd=1 on the command line, stratum responded with 6 but the pool used 6.2.
I tried with sd=6.2 but stratum still responed with 6.

I tried sd=8 and it was accepted, both the stratum response and the pool said 8 as they should.
But vardiff stepped in and lowered the diff and they mismatched again.


Would like to investigate this issue more, if you could confirm above scenario was done on lyra2z? what miner did you use?
If possible reach me out in discord for more details. (e.g. wallet URL and time frame, so I can search in logs).

Sorry for coming with delay, not checking forum as frequently as other zergpool support channels
full member
Activity: 1397
Merit: 221
That's ll fine and good but the pool should be using the same difficulty it tells the miner to use.
hero member
Activity: 1008
Merit: 960
I have noticed on some occasions that the pool stratum difficulty doesn't match the miner.
It seems to only happen for certain algos and certain difficulties.

I'm seeing it right now on lyra2z. The pool is operating at diff 6.2 but he miner says it's 6.
This result in some low difficulty shares when the submitted share diff is between 6 and 6.2.
The rejected shares are mostly noise and don't affect performance.

I have not noticed the pool difficulty being lower than the miner but that would be a silent error
not easilly noticed. This would result in lost performance because the miner would discard shares
that would be accepted by the pool.

Changing stratum difficulty sometimes resolves the issue unless vardiff changes it back.

I had used sd=1 on the command line, stratum responded with 6 but the pool used 6.2.
I tried with sd=6.2 but stratum still responed with 6.

I tried sd=8 and it was accepted, both the stratum response and the pool said 8 as they should.
But vardiff stepped in and lowered the diff and they mismatched again.


You're setting sd=8 correctly, but a lower difficulty, sd=6 fails. That looks to me that is related to the limit the pool has on this number.


Quote from: zergpool.com
sd=
You may want to use it in case of more powerful hardware so your miners bypass low starting difficulty provided by pool with first connection.
Or you may want to use it in case of less modern hardware so your miners get low difficulty job to work on from the start.(minimum start diff can be 20x smaller than default).
Use sd= to set starting difficulty setting for you miner. It will get adjusted during your mining to most appropriate value based on your hardware power.

Notice that the minimum sd has to be 20x less than default. My guess is that sd=6 is lower than this, but 8 is fine.
member
Activity: 124
Merit: 10
member
Activity: 1558
Merit: 69
I have noticed on some occasions that the pool stratum difficulty doesn't match the miner.
It seems to only happen for certain algos and certain difficulties.

I'm seeing it right now on lyra2z. The pool is operating at diff 6.2 but he miner says it's 6.
This result in some low difficulty shares when the submitted share diff is between 6 and 6.2.
The rejected shares are mostly noise and don't affect performance.

I have not noticed the pool difficulty being lower than the miner but that would be a silent error
not easilly noticed. This would result in lost performance because the miner would discard shares
that would be accepted by the pool.

Changing stratum difficulty sometimes resolves the issue unless vardiff changes it back.

I had used sd=1 on the command line, stratum responded with 6 but the pool used 6.2.
I tried with sd=6.2 but stratum still responed with 6.

I tried sd=8 and it was accepted, both the stratum response and the pool said 8 as they should.
But vardiff stepped in and lowered the diff and they mismatched again.


I noticed this problem 6 months ago, but i thought this is normal. Pool did not response to the sd=* argument. So now i know it is not normal - i hope we get an information about that.
Pages:
Jump to: