Updates on Test Data

[vovannovig]

@littleskunk

To me it looks like we might have a problem with the number of connections now. If I run a single node I have almost 100% success rate. If I add a second node on the same IP they split the load and still almost 100% success rate. I can continue like that up until 4 nodes. If I add more nodes they start to get long tail canceled. My reading of this is that TCP fast open or connection pooling gives me 100% success rate for a single node but the more nodes I add the higher the chance that a new connection needs to be established and that makes me lose the race. Not much so I could as well just ignore it but it is visible on my grafana dashboard.

@vovannovig

Please tell me, in the previous mention it was said that if there are more than 4 nodes on the /24 subnet (or 1IP address), then there is a problem, and as I understand it, it is better to take into account a larger number of catches in one subnet?
What is the rational limit?

The question is that just like 1 node - one disk, if you expand, you need to create a separate node, but I already have several of them.

This is a very important question for me, since I do not use RAID, but create new nodes on new disks (realizing that I am losing a lot of money on retention), I would like to offer several solutions for consideration:

1. Allow operators who have nodes in one /24 network to set priority between their nodes, thereby regulating and redistributing the load during service time.
2. Allow operators to specify what TTL they would like to have the minimum, this will also relieve the load if a node cannot cope or several nodes in the /24 subnet or for maintenance.

I want to emphasize that this is the WISH of the operator, and not a hard and fast rule. The desire will be to know the satellite, and decide to send data or not. If everything is fine in the network, we accept the wishes of the node - it will help remove the long tail, and if there is not enough space in the network, the satellite will send all the data, ignoring the WISH of the operator.

Thus, this will allow us to balance the load, and the satellites will decide for themselves, as before, to whom and how much to send.
My proposals are an addition to the concept of a “slow” node, which is now being tracked by the satellite, knowing that the node is losing the race.

Please consider my suggestions.