forgot to post yesterday
Another day of mostly repair ingress.
If some random SNO does graceful exit and some of their data comes to my node as ingress, is that ingress categorized as repair or usage?
There are two states of data on the network…
Good data and data in need of repair…
when a erasure code / string / segment / whatever think they call it a segment, a segment is a bunch of pieces… each piece is then located on different nodes and thus when a node goes offline less pieces exist, if the number of piece is to low repair is triggered.
the repair process will read the existing pieces (thus paying nodes for repair egress) and then uploads the new pieces to new nodes as repair ingress, it’s why repair is cheaper…
it’s internal network data maintenance… i most likely didn’t explain it 100% correctly, but should be accurately enough from a conceptual stand point.
a graceful exit uploads the data back to the network, thus i don’t understand it as repair ingress… but might be… it’s actually a very good question… i could see an argument for either case…
tho since it’s most likely storj that will need to pay for the graceful exit ingress on remaining nodes, then it’s most likely at the 10$ pr tb ingress…
customers pay full price, storj pays half price… i would think is decent rule of thumb
quickly gets expensive if one has to pay full customer price for data maintenance…
ofc the graceful exist might essentially pass the pieces off to another Storagenode…
if that is the case then there would be no overlap… old node starts GE… when new node’s and old node has verified all data is passed back to the network, then GE is done… and the customer contract with the old node ends at that date and the new “contract” begins with the new nodes, thus no data or billing overlap because it’s all customer… and thus GE would in that case most likely be regular ingress…
i think the latter one is the right one… but by no means sure… but its how i would do it…
saves a lot of costs for data maintenance for storj which is the main goal of GE
no ingress is paid. neither repair nor normal. So it doesn’t really matter if GE traffic is repair ingress or normal ingress.
Ingress isn’t paid at all. And in the case of graceful exit, neither is egress, since the SNO running it does it to get their held amount back.
I’m 99% sure GE traffic just shows up as a normal upload.
Edit: Whoops, @kevink was faster
Nice!
36 kb/s per TB!
My numbers - ~25
Also difference between your 24 GB ingress vs my 18 GB - (my node is fully vetted now) probably second node is stealing some traffic.
Date | IngressT | EgressT [GB] | StoredT [TB] | egress ‰ | egressT | EgressT [kb/s /TB] |
---|---|---|---|---|---|---|
21.07.2020 | 157.32 | 14.76 | 2.27 | 6.50 | 170.87 | 75.27 |
22.07.2020 | 40.28 | 8.39 | 2.31 | 3.63 | 97.11 | 42.06 |
23.07.2020 | 20.98 | 7.76 | 2.34 | 3.32 | 89.81 | 38.45 |
24.07.2020 | 24.36 | 7.10 | 2.35 | 3.02 | 82.15 | 34.93 |
25.07.2020 | 9.40 | 3.67 | 1 842 | 1.99 | 42.49 | 23.07 |
26.07.2020 | 14.43 | 4.00 | 1 850 | 2.16 | 46.35 | 25.05 |
It would be nice if we could check if there’s any other node on our subnet.
Anyone has an idea on how we could do that ?
If you have cool features in your router, probably you can get some reports per computer (with nagios), to narrow down computers that send traffic constantly, then ask users? or if you’re admin - check out their computers
Other possible tools for linux:
darkstat - i read on its site that it can turn your network card to promiscuous mode (but it is not developed for few years now)
another possibilities
SARG – Squid Analysis Report Generator link: SARG - Squid Analysis Report Generator and Internet Bandwidth Monitoring Tool
Cacti – Network Monitoring and Graphing Tool
Install Cacti (Network Monitoring) on RHEL/CentOS 8/7 and Fedora 30
Zabbix – Application and Network Monitoring Tool
Nagios – Monitors Systems, Networks and Infrastructure - i think this was used in my last corpo (national-level size bank) to monitor LAN traffic for security purposes How to Install Nagios 4.4.5 on RHEL/CentOS 8/7 and Fedora 30
If they don’t mess up with ports, you can just try to check their ip and if port 28967 is open (try to telnet to this port) or use some white hat hacking tools to see if this port is open.
@kevink
well ingress for repair has to be created from egress else where… or so i assume, else there doesn’t seem to be much point to having the different prices
@BrightSilence
the GE isn’t paid, but the storage is paid, which is what move during the GE, and thus there is a cost equation related to it, even if not directly but over time… and any double booking would cost either customer or storj or SNO is lost capacity / profit.
so… well… not that i really understand it… bright most likely have the best idea about whats going on, without a doubt xD
oh yeah and i do seem to have gotten some of it wrong in my post…
i remember it as thinking about the overlap of the storage cost… might have written it wrong tho
might just have forgotten that GE egress was free…
@kevink and I were both responding to this quote, which we also both included in our post…
You mentioned ingress twice, not storage. And you mentioned a price of 10$, which is the price for repair EGRESS. So yeah, ingress isn’t paid ever.
Storj doesn’t pay for the GE transfers at all since it’s a direct transfer between 2 nodes. So there aren’t even costs for bandwidth on the satellites (other than some exchange of metadata). There is no duplicate payout, from the moment the piece is transferred, the new node will be paid and the old one is no longer paid. So effectively no additional payout is applicable.
yeah but GE is to help limit repair egress which is used to created repair ingress…
yeah i explained it wrong…
i should start writing shorter posts… less points of failure in what i’m saying lol
also had 16 GB repair egress…
completely agree
i need a better screen, my resolution is so crappy, its tricky to get the screenshot simply…
oh yeah and broke 13 TB stored woop woop on one internet connection… thank you
would be kinda nice to know if multiple ip/subnets are allowed or not…
doesn’t seem like i got an easy option for getting multiple subnets… aside from maybe getting a slow extra connection, or setup online servers to redirect the connections… but it just can’t be okay,
i mean if one could get on all subnets, then about ½ of all storj data could be stored in one data center… and just a matter of time before a bot could set that up…
tho the real question becomes how to see it from the outside, if storj cannot detect that the data is stored in the same location, then how can they counter it…
alas i digress… there is my screen for the 27th
new and improve capture tactic so one can see the bandwidth graph fully
I agree with SGC and I’ll take it a step further: the logic Storj has implemented (treat all groups of ~250 IP addresses the same) is shamefully simplistic as to be pedantic and could easily be undermined. Let’s hope that doesn’t happen for the health of the network. A better plan than hoping would be to create a better test of distance - routers do it all the time. Anyone else learn Dijkstra in algorithms class? Graph theory abounds with solutions to this problem. Puh-lease.
Regarding the change in traffic: I am not happy at all. I just ran around upgrading my two nodes from 1-3TB each to ~20TB + caching SSDs based on the ingress/growth at the time. Now that looks to have been misguided. I was seeing 150GB/day so I didn’t want to have to upgrade every month, so I built a couple ugly “box of drives” PCs that would last 4-6 months at that rate. Now, I’ve lost the chance to be graceful and incremental because no one at Storj cared to tell us this was just test data.