--max-diff option works not as expected in solo mode

[YetAnotherRussian]

Version is 3.21.1 cpuminer-avx2-sha-vaes.exe -t 8 --cpu-affinity 0x5555 -a algo -o http://127.0.0.1:54321 -u aaa -p bbb --max-diff=0.45

Seems this option makes sense, mining stops somehow on a high diff job, but then it continues.

I'm not sure if u got some solo env, gonna make detailed logs, if needed.

There's another micro issue nearby:

This demotivating block ttf on start makes people to close and forget rather than to wait for a correct stats :'( Better to slow it down a bit on start, but I'm not sure.

[JayDDee]

The only thing I noticed are TTF 0 and solutions aren't reported as BLOCK SOLVED. I suspect they're both related to netdiff being zero. I don't expect net TTF to be correct for multi-algo coins because it's calculated using the current algo's diff and the total hashrate of all algos.

If all found blocks were accounted in the wallet all is good.

I've submitted v3.21.5, The netdiff issue should be fixed now.

[JayDDee]

Two thing of interest in this extract from the log.

The hash was rejected for unknown reasons. The hash was below target so if wasn't low diff. However, the reject was immediately followed by a new block so either you got it or someone else did just before you, in other words stale.

The other thing is the debug log trying to report Xnonce2, there's no xnonce in GBT. This log is unnecessary. The nonce is output is in the blockheader data of another debug log. The xnonce2 value can also be included in th eother log for stratum. The thread was never of any real value but the log include the lane which was very useful during 4way development. Removing that log will reduce the debug log noise level a bit.

[2023-03-15 11:01:42] 16 Submitted Diff 0.00059184, Block 3422330, Ntime 627b1164 [2023-03-15 11:01:42] Thread 4, Nonce 7c050080, Xnonce2  [2023-03-15 11:01:42] Data[0:19]: 04049b00 d8abe317 9a25841b 424d39e3 fb150e25 60f791f6 9e4695e5 33946c3f a6a40557 aa577dd4 [2023-03-15 11:01:42] : 8d666413 f1ff1ad7 bafc0381 ee01a29c a9dac0f0 ddbf615b d8939f22 627b1164 feb00b1e 7c050080 [2023-03-15 11:01:42] Hash[7:0]: 00000699 a536f62f 83955dbe 56d4bd8b 02a64653 63231bf4 2b26ce59 12686867 [2023-03-15 11:01:42] Targ[7:0]: 00000bb0 fe000000 00000000 00000000 00000000 00000000 00000000 00000000 [2023-03-15 11:01:42] 16 A15 S0 Rejected 1 B0, 58.394 sec (6ms)  Reject reason: inconclusive [2023-03-15 11:01:42] Mining info: diff 0.00035081, net_hashrate 306496393718.552430, height 3422330 [2023-03-15 11:01:42] GBT new work received in 1.00 ms [2023-03-15 11:01:42] New Block 3422331, Net Diff 0, Ntime 667b1164 Miner TTF @ 2646.04 h/s 0m00s, Net TTF @ 306.50 Gh/s 0m00s [2023-03-15 11:01:42] Threads restarted for new work.

Edit: the logs also prove the misaligned crash is solved: AVX2, misaligned pointer, and no crash.

[YetAnotherRussian]

in other words stale.

Yes, stale. I got these before, checked some timestamps on different chains, were confirmed as stales. I've forgot about them.

I've submitted v3.21.5, The netdiff issue should be fixed now.

Great! I'm on it. Need some time to confirm everything is okay. "Block solved" message is on it's place:

[JayDDee]

Looks good, miner TTF looks reasonable, net TTF is zero due to the extremely high shad256d hashrate.

A little hint about target and diff. GBT provides a precise target hash, the net_diff is calculated from it. Stratum provides the diff encoded in the nbits field in the blockheader, the net_diff and the target are calculated from that.

[JayDDee]

It feels good to close this issue. It was a leaning experience.

[JayDDee]

In your last screenshot I noticed that mining info log reported a different net diff than new block log, also a different block height. Besides the mining info data being stale I don't know if the diff changed or if they are reported different for the same block. Look for corresponding new block log and mining info log for the same block to confirm the net diff. If they are different what happens to the shares in between is interesting. It could take a long time to find such shares. I predict if mining info reports lower diff those shares would be submitted but only reoported as accepted but would in fact solve a block. If the new block reports lower diff I expect no effect.

The provided target is used by GBT to test candidate hash for submision, new block netdiff is used to estimate TTF and grade a share as block solved.

I you see any discrepencies feel free to open another issue. It's not complicated, I can switch to use mininginfo net diff instead. I may end up doing that anyway for GBT, but it would help to have some supporting data. It would also help to determine if my math is introducing the error.

[YetAnotherRussian]

In your last screenshot I noticed that mining info log reported a different net diff than new block log, also a different block height.

"blocks" in wallet vs height (in cpuminer-opt)

So the new "job" is "blocks + 1":

Hope that helps.

[JayDDee]

Hope that helps.

I Need the new block log for the same block as getmininginfo so I can compare the diff.

Edit: Another possibility is that diif in getmininginfo is also for the previous block. That needs to be confirmed. If the getmininginfo diff matches the diff in the new block log with the same block height then everything is ok, if they don't match I need to follow up.

I also got WSL working. It creates a VM with a network connection to the host. That's how it can bypass the Windows kernel. With full CPU compatibility and speed it seems like the preferred way to go. Only issue is the lack of CPU temp. Edit: affinity doesn't seem to work on WSL. With -t 1 --cpu-affinity 1 the thread moves around to different cores. I won't be following up.

[YetAnotherRussian]

diif in getmininginfo is also for the previous block

It is.

affinity doesn't seem to work on WSL

My common settings ("-t 4 --cpu-affinity 21760", "-t 4 --cpu-affinity 85" or "-t 8 --cpu-affinity 0x5555") do work well.

Is your version WSL1 or WSL2? (wsl --status)

[JayDDee]

diif in getmininginfo is also for the previous block

It is.

I assume they match the calculated diff for the same block so there is no issue?

affinity doesn't seem to work on WSL

My common settings ("-t 4 --cpu-affinity 21760", "-t 4 --cpu-affinity 85" or "-t 8 --cpu-affinity 0x5555") do work well.

Is your version WSL1 or WSL2? (wsl --status)

wsl2, Win10, ubuntu 20.04 (default). I tried to set distro to ubuntu-22.04 but it wouldn't accept the -D option. I tested -t 1 --cpu affinity 1 and the load floated around to other cores. I assume it's the VM doing this. I also assume the lack of affinity is causing my observed 10% performance drop over either mingw builds. The affinity is set on guest Ubuntu kernel, not the host Windows kernel ulnless WSL explicitly passes it along to the host. The CPU on the test system for Windows has a hot core so I typically use t 3 with 0xa2 to keep the hot core idle and cool. This works fine with the binaries or MSys2 builds. I used coretemp to monitor physical core temps to determine load.

Edit: 0x5555 is overkill for -t 4, that's 8 bits set. It works because the excess bits are ignored but 0x55, binary 01010101, is correct.

[YetAnotherRussian]

I assume they match so there is no issue?

Yes, no issues here.

0x5555 is overkill for -t 4

No, it's for -t 8, check above :)

[JayDDee]

Thanks. It's nice to confirm the accuracy of converting hash to diff. I was previously able to test diff_to_hash and hash_to_diff together by repeatedly converting back and forth to see if error would creep in. Now I have a point of reference proving hash_to_diff_is correct, so diff_to_hash is also correct. This is critical for stratum because diff_to_hash is used for share submission decisions. For GBT it only affects log reporting of solved blocks.