Yes, I’m using a cloud server like that. And JuiceSSH to login from my tablet where I can also run vdash to monitor it.
So you could help by doing that, or just uploading stuff for now.
7 Likes
I guess the launch of the completely ready, impeccable network is scheduled then. Gotta just finish a test or two before that 
3 Likes
Would be interesting to know how the client is approaching the upload of a file… as it seems perhaps not just a matter of using a utility like split and uploading given that the CPU bursts are getting longer?..
So, it started like this
and becomes more like this with noticeably longer CPU bursts…
I wonder if it’s optimised client side for there is more CPU available and uploading seems to be a lump that follows the CPU work done. Perhaps not a priority atm but would like to see CPU and upload network maxed out… perhaps it is affected atm by the network being able to accept chunks and waiting for replies to action the next step… all guesswork.
4 Likes
I noticed CPU bumps even when I was not doing upload (made some other requests) - so I think they may be not directly related to upload process.
Look at your RAM usage by the way. System is not going to swap memory pages?
My impression was swap is only used when running low on RAM?.. it’s 6.0 GB atm.
If you have lots of RAM available, then all is fine.
I have 8 GB of RAM total.
And ~1GB file upload uses almost all of it.
Will there be a debrief / update / article after this testnet. For us semi non-technical it would be good to have a summary about the positives and how things went as well as a list of the main items to touch up on?
3 Likes
This is sooo cool!! what tool did you use to create it? At some point I wanted to have something like that for the node run-baby-fleming command, a nice baby crawling image before launching the nodes.
3 Likes
Awesome! … and I can safe cat from my cloud server if not my laptop.
6 Likes
You devs are the bomb. This should prove to the whiners that behind the scenes work is happening flat out and you are all not sitting back having cups of tea
8 Likes
Yes it will definitely be possible to upload the same data again, and any file/folder that you uploaded to testnet v1 will have an identical XOR URL when uploaded to testnet v2. The only exception to this will be if the file/folder has been edited in any way since it was uploaded to v1.
This first batch of fixes will hopefully be ready so quickly that it doesn’t make sense to try tracking the owners of the 2 nodes down, plus the same thing could be on the verge of happening in other sections, or could easily happen in that same section if these 2 nodes were to leave. This particular one is a quick fix.
Something to note for all readers - once testnet v2 is released we’ll lock this thread and create a new topic for v2. This will help keep the comments in a single thread and hopefully stop any getting missed.
10 Likes
What are the plans for arm platforms ?
I just tried starting the testnet on my pi4 because the linux pc is busy atm with other tasks, and the safe binary that was installed by the install script fails without surprise :
.safe/cli/safe: cannot execute binary file: Exec format error
I had successfully managed to build from source a few monthes ago, so I guess it is still possible, but are there plans for the @maidsafe team to release arm binaries ?
1 Like
Thank you to everyone who had a look at the SN Testnet Review spreadsheet, I suspect this will be used more and more as we iron out all the little obvious bugs and UX issues with the testnet in each iteration.
We’ve now replied to everyone who logged an error in there.
3 Likes
Hey @nice we hope to officially build and support for arm platforms at some point, but it’s just not a priority right now.
I seem to remember reading comments from others who I’m sure have got it working on arm in this thread - have a search through and see what you can find.
3 Likes
It is very silent on the apology front isn’t it.
Usual suspects are very quiet, no strength of character to say sorry… but
I don’t think they had good constructive and honorable intentions anyway.
LOLing @ them.
6 Likes
It is the error you have is your target architecture was not arm.
We probably will, but it really is super simple to compile and link for arm. There are several posts showing that in the forum. All good.
4 Likes
will do my homework 
4 Likes
See: GitHub - happybeing/safenetwork-farming: SAFE Network (Test) Farming
and Raspberry Pi SAFE Thread - #7 by nbsp1
PRs welcome!
7 Likes
This is interesting. I believe it has interesting implications for the worst case catastrophe scenarios that have been discussed on the forum. So 7 lose 2 represents a 29% global catastrophic loss of nodes in an instant and the network keeps on ticking like nothing happened, correct? So whether it’s 7 lose 2 or 9 lose 3, or 12 lose 4, we’re still at the limit of maintaining 66% of the original set rather than ensuring that a 2/3 vote can be achieved with the resulting set. This also means that a larger global catastrophe where 50% or up to 80% of nodes are lost requires a network reboot? Seems reasonable as long as reboot has some guarantees.
In the past, the 8 copies of redundancy was theorized. I had always presumed that this protected against data loss for a 75% to 80% global catastrophe. I also got the sense that backup sections would allow for up to 16 redundant copies for greater protection (4 copies per section, one primary section and up to 3 backup sections).
Can you shed more light on this?
1 Like