Replies: 1 comment
-
Then, don't disconnect. The whole point of the protocol is to have you not interfere with it and let it sort things out. Your node needs only one/two full-height nodes to sync. The only thing that you may want to check is whether the Up/Down MB column has download values (it has, if you are fully synced). Of course, unless you like the 24/7 job. The whole thing started during the first dust storm, where people incorrectly suggested to kill those zero-height nodes, as those were "starving" nodes. However, those zero-height nodes are just indication that your own node is SOL and cannot fully handle the handshake (thus read heights or getting / pushing data). The fact that it was kind of helping was that the node was overwhelmed and couldn't handle that many peers, where by disconnecting those "starving" peers in bulk was giving some breathing room for the node, until it got CPU saturated again. Unfortunately, that BS is still being peddled. This problem is there, as the peer protocol depends on a garbage magic number (peer count: 80), and applies that number to every single node, without looking at the node capabilities. Also is not doing dynamic peer adjustment depending on the node state (e.g., drop connections that are stalled, and not ask for more for some time - thus reducing the peer count). Kind of work around for that is permanently dropping the number of peers in config.yaml (e.g., down to 10 or so). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
1,282,105 coming from behind. Similar connections are repeated even if I disconnect

.
Beta Was this translation helpful? Give feedback.
All reactions