After 12 hours earning at the new increased rate this table is a fair comparison between starlink using home-network and a NBN (HFC) land line connection
Starlink
home-network
30Mbps uplink (unmetered)
30 nodes for 1 eth address
running on SBC 4 core 4 thread box
approx 6GB RAM in use
HFC Land-line
port-forward
35Mbps uplink (queued/smoothed & unmetered)
35 nodes per eth address
running on 24 core 48 thread machine
approx 80GB RAM used
As you can see from the image the starlink/home-network is earning on par with port-forwarded nodes.
While this is an example of 1, it still shows much promise that using home-network as the connection type can indeed work satisfactorily. I am not suggesting everyone should switch to it as that would be bad because who then are the relay nodes
Autonomi’s own set of production nodes are broken in nodes that are behind a simulated router/nat setup on the cloud (without port forwarding), and nodes that are on public WAN IP equivalent of a NAT port forwarded setting. We have internal testnets with both types of environments.
If there was as huge discrepancy here, the team would have likely picked up on this internally first, prior to a release build going out to the public, based on our own comparison reports process and methodology. Though, this type of environment (automatic provisioning and setup) wasn’t there in the early days (months and months ago).
The reliance on --home-network is absolutely the last option to consider. Team is working hard to get DCUTR working so once a relay connection is established, DCUTR takes over, and if achieved from both the nodes (parties), there is less reliance on the middle man.
Yeah all good. I was just stating that the team does have both type of environments as part of the ongoing testing and validation process, for those who weren’t aware off it, .
I indeed wasn’t and we have never heard of it and for sure not seen any data
I do not trust others to simply do the ideal thing - no matter who they are… (And I’m sure the team doesn’t test for e.g. Internet connections behind routers like mine because otherwise my network interaction experience might be better than it is now…)
My last status on home network was from around a year ago where I was running 3 nodes from home on community networks and had the impression they were earning worse… But couldn’t really say because I didn’t get a chance to do real testing on this…
Thank you very much for sharing @neo without you I would have always assumed there are probably discrepancies
As an update to this, before bed last night I checked on it again and the starlink was starting to fall behind, by a small but noticeable amount. Not serious and since it had only 30 nodes as opposed to the 35 of the others it was to be expected anyhow. The figure was 25% lower than the lowest landline account.
But seemed a few % more than just the lesser nodes.
So I bumped it up to 50 nodes and went to sleep.
This morning it is catching back up to the lower earning accounts of the landline nodes. As it should with 50 nodes. Instead of 25% lower it is 8% lower (0.023 vs 0.025)
My takeaway from this for my one example (remember one example) of the combination of home-network & starlink (something the team is not testing, no chastisements please) is showing a minor amount less earned than for landline with port-forwarding. Maybe marginally higher error rates and missing the very occasional quote request? Cannot tell at the moment because I am not monitoring that.
It would need much more testing with more people in a reasonably controlled situation where systems work properly and not stopped/started during the test.
From my example, and mileage may vary, is that starlink with home-network is a viable setup and will earn nicely within the ballpark of landline with port-forwarding, but seems to be marginally lower.
50 nodes on starlink has earned a total of approx 0.036 tokens. The lowest landlink batch of 35 nodes has earned 0.043 tokens and its a different lowest one than was yesterdays. There is randomness in these earnings of course, so using one account for starlink is still not any sort of conclusive test.
This suggests there is a definite difference in earnings between starlink+home-network and landline+port-forwarding. But is it significant enough to make any sort of conclusion? No it is not conclusive in any manner.
My take after approx 2 days is that it is worth while running home-nodes with a starlink connection. But from the indications it is not quite as much a earner as the more secure connection wise landline with port-forwarding. Reasonable still
I would definitely still run nodes on starlink connection even if I have to use home-network as the connection type. Teaser - I hope to get around to trying a mikrotik router with the starlink and test port-forwarding, but this experiment is for home-network on starlink which is the most likely way others will do it.
@Shu I have noticed that even though I have plenty (over 1/2) of RAM still available, that my SBC the nodes are now offloading pages to swap, but the nodes seem to only report what memory is in active RAM only.
Is this correct that the metrics value for RAM usage is only the active RAM? Or does it include the amount in swap?
It depends on the rust sysinfo crate’s implementation of memory usage (I don’t know the details off that at the moment). I would think memory usage would include everything it consumed (virtual address space) for the pid itself regardless if it paged or not to disk.
I run my LXCs with 0 byte swap space, so the memory being reported was in the ball park compared to the LXC’s own total memory used divide by number of antnodes running.
I don’t know what OS and other tweaks you have running on theSBC, but why would it even be paging on standard swap algo, hmm .
Stock install of opensuse. The swapping will just be standard linux style. I am not sure why it has any use of swap space. I have VMs running the same standard install of opensuse that run for months using no swap (firefox, kate, terminals, various other apps)
Only noticed swap used with nodes on the SBC and the other computer (150GB free RAM) with the 700 nodes. And only happening more recently as I don’t remember it happening months ago with the beta nets
Linux, moreso than FreeBSD, seems eager to page out to swap. I’ve explored this somewhat and apparently it’s opportunistically moving rarely used data out of RAM, rather than RAM going to waste.
On my setups it seems to be only happening to the nodes. Other systems with this install do not seem so eager to swap. Its some behaviour that is causing it here, not sure why yet. I left swap on here deliberately. My windows with 128GB has no swap, and prefer no swap. But hey these are test systems with swap on
After some work on my routers and SBCs (mounting them a rack) I have a mikroTik rb 5009 router connected to the starlink replacing completely the Gen 1 router box.
2 x SBC computers (4 core, 4 thread, 8GB RAM, 2TB SSDs, opensuse linux) connected into 2 ports on the router.
Testing the NanoKVM to access the SBCs over the local network. Laggy but seems to do an adequate job viewing the HDMI stream and supplying keyboard/mouse via a USB connection. Using graphical UI for the SBCs rather than SSH for these tests.
One SBC is setup with 60 nodes using home-network and 2 ETH addresses
The other SBC is setup with 60 nodes using port-forwarding and 2 ETH addresses
Will report back as to a comparison between the earnings using home-network and port-forwarding through the one router to starlink. Also will compare with the landline.
Note: starlink has always supposedly not supported port-forwarding or upnp on its network. I suspected it was just in their quite reasonable routers that are limited in functionality. My port-forwarded nodes are earning, so it seems at this time my suspicions were correct.
Do you notice that memory usage is much lower with home network too? Certainly, resident memory seems to be nearly half vs port forwarding for me.
It could be a good option for boxes which are memory constrained. In fact, I hope the incentive to run port forwarded (or fully connected) nodes is sufficiently high to offset this benefit.
.
.
