I made a video guide that gives tips on Database storage, editing config.yaml to change peers. DUST STORMS! How to perform well during them! - YouTube
if you like it please consider subscribing
I made a video guide that gives tips on Database storage, editing config.yaml to change peers. DUST STORMS! How to perform well during them! - YouTube
if you like it please consider subscribing
The “Tutorials & Guides” category might be a better home for this subject, rather than “Support”.
I watched your video, and I have to say that i disagree with your understanding of height and your recommendation to manually drop some nodes.
This 'low / zero hight" has been covered on this forum extensively, and in most cases it implies taht your own node is being overwhelmed by having too many peers, and slow media for db. Asking people to do whack-a-mole is pointless, because when you drop few nodes, you are actually lowering the peer count, thus reliving the pressure on your node, so it acts a bit snappier, but it will degrade with new peers coming.
The problem is not really “dead” nodes, but the number of transactions passed by active peers that cannot be handled by your node. Basically, the chia code sucks big deal as far as handling peers and db.
So, the #1 action is that peer change in config.yaml, and rather than slowly dropping from the top, it is better to right away go down to 10 or so, and eventually (when it starts smooth sailing) bring it up bit by bit. For a node to run properly, it is enough to have just one peer (fully synced). Also, for that node to be helpful for the network, about 5 peers is already good enough.
The number of peers should be dynamically controlled by network handling code, as that is rather 101 of network programming. Having that 80 number in config.yaml is really the most retarded settings in that file.
Also, regardless how powerful system you have, the choking process during the dust storm is the main full_node process, and when that process chokes the single core that it is sitting on, the game is over. That core handles both the network side, the db side, and the sub-full_nodes (transaction processing processes) thus all those problems.
I didn’t watch the video, sorry. But I did want to just add my experience on the matter. My full nodes have always ran on full blown desktops with considerable processing and RAM power. During dust storms, I always experience an uptick in wins. Seems being on the overpowered side of things pays off during those times.