No but I expect there will be other attempts along soon.
If you want to fire one up yourself @anon26713768 or @folaht have the most recent experience. You will need a good few cloud instances to start with to achieve any kind of critical mass - I think the least that a network was started with was 17? . If you just want to see if folk can connect to you then start a node and publish the IP, port and genesis key. If enough folks join soon enough then it may take off.
3 Likes
Is it possible to get value, which represents how much network is close to losing data because of people joining and leaving too fast?
It may be both that such situation happened many times with testnets and that it never happened yet (because of lots of “centralized” nodes).
2 Likes
It’s difficult as nodes notice they need to replicate data do so, but then may churn before they finish. So we have 4 replicas right now. The best thing is to see how many nodes do churn and ensure there’s enough replicas covering the address space of a chunk (say 8), but there is always a limit. We need to ensure we have a replicant count that puts the probability of survival of various churn rates?
Ofc as nodes restart they do save the data again (store on the network) and there will be archive nodes etc. So it’s all part of a bigger picture.
5 Likes
I remember talk about prioritization data preserving tasks over serving data to clients, is that already in or not yet?
1 Like
We do have basic msg priorities but will need to measure/tune that. It’s part of the quic protocol so not an invention of ours.
3 Likes
Just wondering, why is all the free network space not simply used for pre-replicas? If one of the 4 routable copies becomes unavailable you could promote a node that holds a pre-replica? The additional copies are sacrificial, as those nodes aren’t actually part of the network serving data. It kinda works as a useful “Proof of Resource” commitment while they wait to join.
I have always wondered if the “python swallowing the pig” problem would become an issue. (python is the data line (e.g. 10gbps) and the pig is a huge network churn event)
It’s always going to take time to copy, but if as much as possible existed already copied in a distributed bittorrent like fashion, you would increase the size of the data line reducing the impact and time of huge network churn events.
Simply, when the network is healthy it can use spare bandwidth to reduce bandwidth requirements during churn events. Is this something that already happens?
4 Likes
The chances of data being in the right place after a node is relocated are too small but I think there will still be ways to improve the efficiency of things like this. I hope so anyway, although some ‘inefficiencies’ will always remain, and be the cost of network security.
Another inefficiency I began wondering about today is all the data an Adult no longer needs after promotion to Elder. It seems both a shame not to make use of that, and a strange situation for a node to no longer need lots of disk space once it becomes an Elder. All that storage (and the data in it) suddenly have no use, and become wasted resource.
I don’t know what can be done about that, except perhaps for Elders to provide archive storage for all the data they had at the time of promotion. So they would only be required to deliver it in rare and exceptional circumstances, although there may be problems with that too!
10 Likes
As an elder, he will use that data as its cache. So not totally lost and hopefully none is lost.
12 Likes
How does that fit with making requests going direct to Adults, does it make that change less worthwhile?
3 Likes
I think so @happybeing as it may be best to never expose adults to clients and vice versa, but a debate well worth having, of course.
4 Likes
Can anyone tell me why when I compile sn_node it uses more memory than when I use Maidsafe’s releases.
This is consistently the case and the difference is significant.
my sn_node starts up using:
165.22.112.18: 646MB
Maidsafe’s sn_node starts up using:
165.227.232.225: 51MB
2 Likes
Are you sure you did cargo build --release ?
Cos otherwise you will get a build with shitloads(1) of debugging stuff in it
(1) Genuine Technical Term
2 Likes
Make sure you are compiling in “release” mode with optimizations turned on. Otherwise you will be running slow “debug” code…
1 Like
absolutely with --release. I am in the process of compiling with cross to see if I get a different result.
3 Likes
TBH, I did not think this was a mistake you would make - but it had to be asked…
2 Likes
Funny how we responded at the same time. 
4 Likes
if there is a dumb mistake to be made, always the best place to start!
I compiled using cross with the same result.
So using cross build --release OR cargo build --release
gives the same results:
134.209.19.204: 518MB
134.209.23.24: 645MB
134.209.25.66: 645MB
138.68.159.165: 647MB
134.209.27.110: 518MB
134.209.29.254: 518MB
134.209.21.206: 518MB
134.209.21.102: 452MB
134.209.21.168: 452MB
using Maidsafe’s releases I get,
167.99.196.73: 112MB
159.65.28.8: 112MB
159.65.60.231: 51MB
138.68.161.154: 117MB
159.65.53.250: 112MB
165.227.232.225: 51MB
138.68.174.17: 117MB
159.65.20.186: 51MB
138.68.155.18: 51MB
159.65.48.210: 51MB
2 Likes
Post exactly what you are building and I’l try to replicate it here. Interesting to see you also have three discrete sizes for the maidsafe release - which versions?
2 Likes
Building latest (but this has been the case with previous versions too), steps are.
git clone https://github.com/maidsafe/safe_network.git
cd safe_network/sn
cargo build --release
1 Like
I get 31MB from your steps
willie@gagarin:~/projects/maidsafe/safe_network/target/release$ ./sn_node -V
safe_network 0.54.1
willie@gagarin:~/projects/maidsafe/safe_network/target/release$ ll sn_node
-rwxrwxr-x 2 willie willie 31394752 Jan 24 23:41 sn_node
willie@gagarin:~/projects/maidsafe/safe_network/target/release$
1 Like