TP v.0.1.14 takes a lot to complete handshakes after the first one
#80
Comments
|
TP logs: Pool logs: Pool restarted: |
|
@Sjors as you can see from the logs, the second time I run the Pool, it's at But from the TP logs, it's not possible to see the second noise connection request until So that demonstrates how the Pool gets stuck for about 18 seconds |
|
This is probably not related to the changes in More likely the problem is that once the TP has a connection, it's (partially) blocked from listening to new connections. This might be tricky to debug. I'm going to try the laziest solution first, namely to update the I'll ping you when that's done so you can test it. If it works I'll tag a new release, otherwise I'll investigate more but it might be two weeks before I get to that. |
|
I can't reproduce this with the latest But also not with the Both compiled from source as a debug build: For the pool I used your PR at c76a161cfe6e7ea6b5b2f11381a6eb6ebb62035b. Both on the same machine, using SRI signet. I didn't mine. Tested on (Apple Silicon) macOS 15.3.1 Let me know how it goes on your end... Do you get the same issue when you keep the pool connected, and then connect from another role? If not, then maybe the problem is related to the disconnection. Also, did you test whether v.0.1.13 has the same issue? (maybe just dropping the |
|
It's also a good idea to wipe the |
|
Sorry I was stuck in other stuff during last days. I just compiled your last commit (5fe5296) and tested again. Unfortunately I still get the same behaviour..
I get the same issue also if I connect a JDC to the TP after the Pool.
v.0.1.13 doesn't have this issue at all, I tested it last week and everything was fine. |
|
Thanks for the update. Difficult to debug until I can reproduce... I noticed you're using macOS 13, is that an Intel machine? I'll try that later, maybe it helps in reproducing. How are you building and compiling both Bitcoin Core and the pool role? Are you running them straight from the command line terminal, or some Docker like setup? Have you tried on a linux machine? |
Yes, it is. I'm running everything from the command line. |
Maybe there's detail there that I'm doing different. Also, are you using the SRI signet, or testnet4 or mainnet? |
I'm using On ubuntu I just used the binary provided by you btw, I haven't tried to compile it from latest commit. |
This would be useful for comparison. Can you try again with more verbose logging: When building, can you add I'd also like to know if this only happens when you disconnect and reconnect, or if it also happens if you get a second connection (e.g. from a JDC). The timing here suggests that our main thread is blocked, and then suddenly becomes available again and serves both a normal peer (p2p) and your pool (sv2). cc @vasild I can't reproduce with testnet4 either, but will try on an Intel Mac next week. |
Is there an existing issue for this?
Current behaviour
I tested
v.0.1.14together with my corresponding PR on SRI: stratum-mining/stratum#1456, to test the newCoinbaseOutputConstraintsmessage.Using just the Pool, it's easy to see that the first time it connects to the TP, everything is fine.
But if I restart the Pool, the second handshake takes a lot of time to finish, and sometimes it doesn't finish at all.
Expected behaviour
As with previous versions, the handshakes should be completed quickly
Steps to reproduce
Run the latest version of TP (
v.0.1.14) and checkout my PR on SRI: stratum-mining/stratum#1456.Then run the Pool role for the first time, kill it, and then start it again.
Relevant log output
No response
How did you obtain Bitcoin Core
Compiled from source
What version of Bitcoin Core are you using?
TP v.0.1.14
Operating system and version
Mac OS 13.0.1
Machine specifications
No response
The text was updated successfully, but these errors were encountered: