Strange output with Kaspa invalid shares

[GauchoBois]

Hi, just to report a strange behavior that can only be seen in the terminal and not in the logs:

HeavyHash-Kaspa: GPU 9: Share is invalid or stale (93 ms) 
{
    "id": "29",
    "error": [
        "21",
        "Job not found"
    ],
    "result": "null"
}

HeavyHash-Kaspa: GPU 2: Share is invalid or stale (186 ms) 
{
    "id": "22",
    "error": [
        "21",
        "Job not found"
    ],
    "result": "null"
}
Etchash: GPU 2: Found a share of difficulty 7.86G 
Etchash: GPU 9: Found a share of difficulty 7.17G 
Etchash: Average speed (15s): 26.33 Mh/s | 27.96 Mh/s | 26.32 Mh/s | 30.09 Mh/s | 29.36 Mh/s | 25.84 Mh/s | 29.39 Mh/s | 29.48 Mh/s | 30.15 Mh/s Total: 254.92 Mh/s
HeavyHash-Kaspa: Average speed (15s): 111.91 Mh/s | 111.86 Mh/s | 111.87 Mh/s | 97.79 Mh/s | 88.07 Mh/s | 77.51 Mh/s | 88.16 Mh/s | 88.45 Mh/s | 97.97 Mh/s Total: 873.60 Mh/s
Pool not reacting to submitted shares for too long. Reconnecting. 
Etchash: Average speed (15s): 26.35 Mh/s | 27.99 Mh/s | 26.31 Mh/s | 30.10 Mh/s | 29.36 Mh/s | 25.74 Mh/s | 29.38 Mh/s | 29.44 Mh/s | 30.14 Mh/s Total: 254.80 Mh/s
HeavyHash-Kaspa: Average speed (15s): 111.99 Mh/s | 111.96 Mh/s | 111.82 Mh/s | 97.81 Mh/s | 88.08 Mh/s | 77.21 Mh/s | 88.14 Mh/s | 88.32 Mh/s | 97.96 Mh/s Total: 873.27 Mh/s
Etchash: GPU 6: Found a share of difficulty 4.87G 
Etchash: GPU 1: Found a share of difficulty 5.19G 
Etchash: GPU 6: Found a share of difficulty 31.17G 
Etchash: Average speed (15s): 26.39 Mh/s | 28.00 Mh/s | 26.31 Mh/s | 30.10 Mh/s | 29.37 Mh/s | 25.72 Mh/s | 29.35 Mh/s | 29.42 Mh/s | 30.13 Mh/s Total: 254.81 Mh/s
HeavyHash-Kaspa: Average speed (15s): 112.14 Mh/s | 112.00 Mh/s | 111.83 Mh/s | 97.83 Mh/s | 88.12 Mh/s | 77.17 Mh/s | 88.06 Mh/s | 88.27 Mh/s | 97.94 Mh/s Total: 873.36 Mh/s
Etchash: GPU 8: Found a share of difficulty 4.22G 
client_loop: send disconnect: Broken pipe

and then the miner crashed and the ssh connection just got interrupted.

I also saw it by watching the terminal output but the miner normally continues like nothing happened. It is very rare and not common... I'm not sure if it always happens with a kaspa rejected share or not. Saw it in 1.58 as well as 1.59a. I'm on ubuntu.

Just looks to be a minor issue. Hope it helps.
Thanks again.

[jgonzis]

Hi, just to report a strange behavior that can only be seen in the terminal and not in the logs:

HeavyHash-Kaspa: GPU 9: Share is invalid or stale (93 ms) 
{
    "id": "29",
    "error": [
        "21",
        "Job not found"
    ],
    "result": "null"
}

HeavyHash-Kaspa: GPU 2: Share is invalid or stale (186 ms) 
{
    "id": "22",
    "error": [
        "21",
        "Job not found"
    ],
    "result": "null"
}
Etchash: GPU 2: Found a share of difficulty 7.86G 
Etchash: GPU 9: Found a share of difficulty 7.17G 
Etchash: Average speed (15s): 26.33 Mh/s | 27.96 Mh/s | 26.32 Mh/s | 30.09 Mh/s | 29.36 Mh/s | 25.84 Mh/s | 29.39 Mh/s | 29.48 Mh/s | 30.15 Mh/s Total: 254.92 Mh/s
HeavyHash-Kaspa: Average speed (15s): 111.91 Mh/s | 111.86 Mh/s | 111.87 Mh/s | 97.79 Mh/s | 88.07 Mh/s | 77.51 Mh/s | 88.16 Mh/s | 88.45 Mh/s | 97.97 Mh/s Total: 873.60 Mh/s
Pool not reacting to submitted shares for too long. Reconnecting. 
Etchash: Average speed (15s): 26.35 Mh/s | 27.99 Mh/s | 26.31 Mh/s | 30.10 Mh/s | 29.36 Mh/s | 25.74 Mh/s | 29.38 Mh/s | 29.44 Mh/s | 30.14 Mh/s Total: 254.80 Mh/s
HeavyHash-Kaspa: Average speed (15s): 111.99 Mh/s | 111.96 Mh/s | 111.82 Mh/s | 97.81 Mh/s | 88.08 Mh/s | 77.21 Mh/s | 88.14 Mh/s | 88.32 Mh/s | 97.96 Mh/s Total: 873.27 Mh/s
Etchash: GPU 6: Found a share of difficulty 4.87G 
Etchash: GPU 1: Found a share of difficulty 5.19G 
Etchash: GPU 6: Found a share of difficulty 31.17G 
Etchash: Average speed (15s): 26.39 Mh/s | 28.00 Mh/s | 26.31 Mh/s | 30.10 Mh/s | 29.37 Mh/s | 25.72 Mh/s | 29.35 Mh/s | 29.42 Mh/s | 30.13 Mh/s Total: 254.81 Mh/s
HeavyHash-Kaspa: Average speed (15s): 112.14 Mh/s | 112.00 Mh/s | 111.83 Mh/s | 97.83 Mh/s | 88.12 Mh/s | 77.17 Mh/s | 88.06 Mh/s | 88.27 Mh/s | 97.94 Mh/s Total: 873.36 Mh/s
Etchash: GPU 8: Found a share of difficulty 4.22G 
client_loop: send disconnect: Broken pipe

and then the miner crashed and the ssh connection just got interrupted.

I also saw it by watching the terminal output but the miner normally continues like nothing happened. It is very rare and not common... I'm not sure if it always happens with a kaspa rejected share or not. Saw it in 1.58 as well as 1.59a. I'm on ubuntu.

Just looks to be a minor issue. Hope it helps. Thanks again.

Could you share the line config... I have never send before the client_loop...

[GauchoBois]

sorry for the lack of information... The client_loop is just because I was running a Tmux session on ssh from my laptop. So, when the miner crashes like this it "brakes the pipe" because I have a soft-watchdog to "sudo reboot" when there is no miner found in the list of processes. Just ignore that. I don't exactly know what made the miner to crash but this is what I normally see when there is a "Core dumped.... segmentation fault... ". It could have been just a coincidental crash but what looks "strange" to me are these "prints" to screen:

HeavyHash-Kaspa: GPU 2: Share is invalid or stale (186 ms) 
{
    "id": "22",
    "error": [
        "21",
        "Job not found"
    ],
    "result": "null"
}

so, just in case it helps this is my config line:

./lolMiner --algo ETCHASH --pool $ETCPOOL --user $ETCWALLET --worker $WORKER --pool $ETCPOOL2 --user $ETCWALLET --disable-dag-verify --log on --dualmode KASPADUAL --dualpool $KASPAPOOL --dualuser $KASPAWALLET --dualworker $WORKER --max-latency $LATENCY --tls on --dualtls on $ $@ 

where $LATENCY=300. The miner is lunched on startup after 60s in a Tmux session... maybe as a service it would be better but this is way more handy to debug the gpu failures.

I also wonder why there is "Core dumped" crash from time to time in the miner without any apparent reason (none of the GPUs go to 0Mh/s looking at the logs) and sometimes a soft reboot doesn't restart the Linux and only a hard reset through a raspberry hard-watchdog does... Similar problem also happens sometimes with the emergency.sh not managing to reboot the SO after a GPU going to 0Mh/s. It looks to be a problem of the SO not managing to call off the processes after a GPU super crash (tried rebooting in more aggressive ways without success through systemctl, -f, blablabla). It happens to almost every miner. I'll investigate a bit more about this and come back with another issue if I gather some more information.

Anyways, thanks very much again for the super quick responses! Genius.

[jgonzis]

Going to 0 is normally or Internet problems or Drivers crash for OC

[Lolliedieb]

Fixed with 1.60