2% difference in egress / ingress, and the salary 5.76 times higher … um … strange … not all SNs take part in the test?
If this SN remains, I will lose my friend, if I want this friend, another SN will disappear from the network.
Unless a solution is found … and the colleague is happy
There are some exceptions like using the network connected drives for storage or SMR drives or use devices with too low RAM (less than 500GB), which can significant lower income because such hardware become a bottleneck,
Wait, how much RAM?
Thanks! 
fixed the response.
The ping time does not include the latency in the software, only the transit time between ports, unfortunately there is no information about the full latency in the storagenode’s databases.
@stob @peem What is your bandwidth? Up and down, especially - up.
500Mbps down / 500Mbps up
Speedtest shows:
Download: 549.57 Mbit/s
Upload: 66.11 Mbit/s
Seems this makes a difference. But I didn’t expect so linear dependency.
So if a colleague changes the contract for the connection speed, he will eventually earn like other SNOs?
Does anyone guarantee that it will be so?
In the results of the “successrate” program for downloading from the node, should I look at “download”?
Could you give your results for September for comparison?
A colleague has:
Ingress 402.5GB
Egress 98.89GB
Have you seen this thread:
Earnings don’t seem to be evenly distributed.
If you are lucky and your node stores data that get downloaded frequently then even a node with a size of only 500 GB can earn $20 a month as the node operator has stated.
Ingress 467.13GB
Egress 836.39GB
My ingress is only slightly higher at 463GB, but I have 1.5TB egress. I also have more than 15TB of data stored on that node though. This matters a lot. But it doesn’t explain this big of a difference.
No one can guarantee that, there are too many variables and connection speed is just one of them. I personally highly doubt that this is actually the bottleneck in this case. We’ve seen node operators with lower upload speeds have better performance than that. As @Alexey pointed out before, the speed that matters is the speed from receiving the data request to sending the full piece. This includes upload speed, but it also includes HDD speeds and anything else impacting that process.
It is for 2 nodes that were receiving data during the same time period though. For the most part at least. @Stob’s node provides a useful comparison for this as it is the same amount of months old.
I just noticed something comparing the results of the success rate script from both @peem and @stob. @peem has around 30k downloads initiated and @stob has 300k. The success rate is close, but the number of total downloads to begin with is 1/10th. I can’t really explain how that could possibly be. Anyone else have an idea?
I would like to suggest to compare the remained hardware to remove it from the equation.
Thank you very much.
Could you please reveal how much data your node has accumulated over these 17 months?
Here: Used 2.46TB
And where is your node geographically located?
2 posts were split to a new topic: What about Geo-centralization requirements?
Obviously, you get the idea.
I would love to read the more exact answer. With numbers. And rationales behind.
I can’t recall exactly. But I think it was early this year. I will go mining anyway.
Different download algorithms for a given geolocation? But this Storj will not tell you what they test …
