3 nodes on the same machine (synology) using the same disks.
The three nodes have been coexisting since each was created (same input traffic!!!) and none has ever been full.
I really shouldn’t drink before posting…
All 3 nodes are fully vetted. The third node was vetted in less than a month a long time ago (6 months).
Instead of “vetted” I meant “still subject to held amount”.
All three nodes have been “ingressing” during all their common existence. Maybe during the vetting month of the third node it got a bit more ingress. So, should the present difference in egress be related to the extra ingress during the vetting month?
There is no strong relations between ingress and followed egress: the customers may upload some static data like pictures or videos then stream them from their site, generating egress from your nodes, but some uses it as a backup and never download them back, only deletes, so there is no stable usage pattern.
Yep. Nothing new, really…
Can you explain why one of my nodes get streamable pictures and videos and the other two get static data?
All three nodes have been ingressing in parallel since creation. If the older nodes would do more egress, that would be alright because they’ve got data that the newest node has never seen.
But the data that the newest node holds “is also present” in the other 2 nodes.
No stable usage pattern doesn’t mean that statistics should make no sense.
it’s pure random. This particular node is happen to get an active pieces. I guess all your nodes are behind the same /24 subnet of public IPs, thus they cannot get pieces of the same segment of the same file, so all three stores pieces of different segments of different files and likely - of different customers.
There are 20K+ of active nodes in the network. Why these customers should select your three nodes for the similar usage? Even if they happen to upload to your node nearly in the same time? How can statistics prove otherwise?
You are in denial…
The nodes are not only in the same subnet, they also have the same IP (same machine, synology)
Forget the previous ingress of the 2 oldest nodes. Let’s take into account only the ingress that the three nodes got since there are three nodes in parallel. Let’s pretend I created the 3 nodes on the day I actually started the third.
Each node gets roughly the same amount of ingress everyday. Therefore, let’s say each node holds now ~1.37TB.
Here is this month ingress for the three equal nodes started on the same day:
I can’t recover last month egress. The dashboard is not working (zero). But I remember seeing a day where the 3th node did more than 80GB while the other 2 nodes did 2 or 3 GB. This is statistically impossible!!!
It’s obviously not possible for the 3 nodes to have the same segments of a file. Whatever egress I have, it can not be chosen to come from a certain node instead of the others. If this “thing” is only happening to me and not to other node operators (excess egress from new nodes), then the statistically “impossible” is happening. But I don’t think it is happening…
I will tell you what the “thing” could be that would explain the absurd egress I showed you. You don’t have to tell me that it’s true or false. Just tell me if you agree or not that it would explain the absurd egress.
You have programmed on the network an egress preference for the new nodes (nodes that are not being paid 100%).
For honestly, I do not understand, why do you expect the same behaviour?
They’re even updated in a different time, I’m sure.
So, why do you expect the same behaviour for the independent nodes?
Yes, they are in the same subnet of public IPs (local IPs doesn’t matter), but why do you think, that they are dependent?
Of course, since they uses the same disk/pool, they are affect each other because of the concurrency access to the same resources, but it doesn’t make them depended regarding usage, moreover, they must be accessed by different customers, at least store different segments of different files.
By the way, there is no “egress preferring”, in this regard they are equal to other 79 nodes, keeps pieces of the same segment.
The satellite selects 39 different nodes, stores this segment for download, as soon the customer downloaded first 29 pieces, all remained got canceled.
Read what I wrote more carefully. I would expect the same average behaviour if the nodes had been created on the same day. Since the older nodes are larger, the expected average behaviour in terms of egress should favor the older nodes, not the new one.
The “old concept” of “new data having more egress” does not apply here, since the three nodes have always been working in parallel. They hold the same amount of “new data”.
I don’t know what you mean by the nodes being dependent. The only relation between them is not having common data.
The nodes reside in different disks. Same success rates.
You didn’t answer… would it explain the absurd egress or not?
Why do you expect the same behaviour? This part I do not understand. They are completely different nodes, they have a different NodeId, they are selected only one from the /24 subnet of public IPs, this is expected, that they will act differently, this is by design.
The problem likely start if they start to perform the same.
Just remember our goal - we want to be decentralised as much as possible (we are expect that nodes will act differently).
If three nodes are started at the same time, same IP, same machine, same brand/model of disks, I expect the same average behaviour. Let’s say, for nodes 1 and 2, I get roughly the same egress (on average) considering the different sizes of the two nodes. Never had 40 times more egress from one of the nodes.
Again, would such a preference, if it existed, explain the abnormal egress?
