tried running at 100% cpu it dident work out to well lol
What are you running per machine? I was ok on 45 got too ambitious at 55 I think.
Never know unless you try. Id rather have it at set it and forget it level than need to baby it all day.
got a range running some machines at 50 nodes 60 nodes 70 nodes and some at 80 nodes.
still trying to get the right number 50 is definitely okay 80 not so much !!
takes a couple of days to get an accurate reading on what ok or not ok
My worry is, is 50 too much when more than a obscure corner of the worlds population comes prodding.
Just guessing it happens with more users, why else would it spike?
also a good factor the network is quiet now
just pondering if a script on a cron job that can stop or add nodes if the cpu is above or below a thresh hold is a good idea.
It would need to stop the nodes that are currently using those resources to have meaningful impact which seems counterproductive.
Kill the working node in favor of the inactive node.
Unless of course it is legit using unintended resources.
Aye, it’s not simple here.
I guess the main thing is “You just can’t guarantee to handle this”, so some node should be stopped. But you have sampling intervals, or some other process which needs to manage state + make decisions around all of this.
At the moment, it’s a bit out of scope, we’re starting initial “resource allocation”, in a simpler “HD space” fashion. But we’ll get towards something more solid here as we progress I think,.
on the up side apart from the repayments error being a pest network is doing great
just slung up a 5gb ubuntu image on batch size 224
"ubuntu-23.04-desktop-amd64.iso" 80d88c666263718d9ee271acdf38710065d4cc235837eed7fa7314f0a53d8080
@joshuef is there an easy way to ensure that clients built by third parties use the appropriate SN crate versions (and maybe forked modules when bugfixing), to ensure compatibility with particular public test networks?
I guess it may not always be ‘latest’ on crates.io
, even with recent changes to publishing there.
But also, sometimes we need to reference forks in a local safe_network repo.
What’s the best way for third parties to keep apps in step, and would it be reasonable to have a short section in the OP of each public test topic, aimed at those developing apps?
I have 10 Nodes up, all with records and earning. nothing interesting to report - it just works. I just wanted to share that I’m present.
You will only pay the one that replied with a PaymentQuote.
Meanwhile, paying a node that you are not connected to
is normal, as not all nodes will be in your RT ?
regarding to tell among two quotes, who is old and who is new, it’s a <
check without any margin (is_newer_than
function)
but these two quotes supposed to be generated by the same node, which shall have no glitch ?
Would it be possible to kill a node if it reached a certain cpu threshold. I usually have 1 or 2 using a lot more cpu than the others?
yes but I am still not convinced it deserves to be killed because it is using some cpu, perhaps after x amount of time but from what I can see they cycle and are not misbehaving as such.
So unless they are doing something wrong why kill it.
The issue from where I sit is too many nodes are the issue not nodes in particular but that may not be your experience.
The base way would be the protocol definition. I’m not sure that’s enforceable though.
This seems doable. Perhaps just listing the protocol
for this network. (And perhaps linking to a readme explaining how that’s derived from the network versioning?)
@storage_guy @Southside After 4 days of uptime it shows that 2 nodes got shunned and rewards are low. Vdash appears as not synchronised, it initially showed all nodes as ok. Everytime that I launch it updates the info a bit and not totally. (For example the rewards of node 1 are 1000 nano. If I launch the command vdash it shows 100 nanos , after the second launch it shows 300 nano, then 400 and so on… it doesn’t get updates immediately to the current situation)
If DCUtR fails, then no, the hole punch isn’t successful. Communication over the relay should be fine, although it is less efficient.
I hadn’t yet heard of AutoRelay, but appears to be a mechanism in the Go library. We are using our own relay manager that attempts to connect to relays it finds. It currently is only going to connect if we are home nodes (specified by flag).
I’m not sure how ‘protocol’ relates to building an app using the sn_client and related crates. I’m using several ATM.
I was thinking about module versions, ie what to put in Cargo.toml
.
How can we determine determine the version of each crate we are using, to ensure it is compatible with a given public test?
Maybe that’s what you mean, but I don’t understand.
@bzee could you please make it clear to those who don’t have a doctorate in this stuff cause it is not simple.
We now have, --home-network, upnp and port forwarding to choose from when setting nodes up.
Which one should be the go to in terms of the best option, not the easiest to do, but the most robust if we had to pick the ideal.

We now have, --home-network, upnp and port forwarding to choose from when setting nodes up.
Which one should be the go to in terms of the best option
--home-network
uses relays and hole punching, which is more complex. If your router has UPnP, I think it’s fine to use that. But the most robust would be to forward ports to your machine.
Same here. Running 80 nodes + 16 nodes with home network, low rewards, vdash not synced.