Thanks Chris - I’m about to chuck it for the night anyway and try to get my sleep patters back to normalish
2 Likes
I ended up just moving safenode to /usr/local/bin alongside safe binary itself.
willie@gagarin:~/projects/maidsafe/safe_network$ cd ~/projects/maidsafe/safe_network && git pull && cargo build --release --features statemap,otlp,build-bin,data-network && sudo cp target/release/safenode target/release/safe /usr/local/bin`
then start a 30-node testnet with
willie@gagarin:~/projects/maidsafe/safe_network$ cargo run --release --bin testnet --features data-network
which has just put 4.3Gb of data in ~8 mins
willie@gagarin:~$ du -hs /fgfs/Scenery/Scotland/
4.3G /fgfs/Scenery/Scotland/willie@gagarin:~$ time safe files put -r /fgfs/Scenery/Scotland/
FilesContainer created at: “safe://hyryyrywot5n51gjqs5xjrcyfoyx8mbjxhnjxmnqmy1nirh8wm95dsmjgbwnra?v=hknba7aapdozt6hsbqt6x7wi7x8hbha3fpsu3qczje6iu3fnaw3oy”
±–±---------------------------------------------------------------±-------------------------------------------------------------------+
| + | /fgfs/Scenery/Scotland/Orthophotos | |
|—±---------------------------------------------------------------±-------------------------------------------------------------------|
| + | /fgfs/Scenery/Scotland/Orthophotos/w010n50 | |
|—±---------------------------------------------------------------±-------------------------------------------------------------------|
| + | /fgfs/Scenery/Scotland/Orthophotos/w010n50/w002n57
snip ---------------------------------
-±---------------------------------------------------------------±-------------------------------------------------------------------|
| + | /fgfs/Scenery/Scotland/Orthophotos/w010n60/w002n60/2925995.dds | safe://hyryyyyqfd7gnqpg4bss3nnnmpjgaw8zsqx1xmt5dugnxz4j3o1ctbt968r |
|—±---------------------------------------------------------------±-------------------------------------------------------------------|
| + | /fgfs/Scenery/Scotland/Orthophotos/w010n60/w003n60 | |
|—±---------------------------------------------------------------±-------------------------------------------------------------------|
| + | /fgfs/Scenery/Scotland/Orthophotos/w010n60/w003n60/2909571.dds | safe://hyryyyyx1xzmkf87x5kkca8ahfiwybobhsk1jow3bi4wuowz9heetzc31wa |
±–±---------------------------------------------------------------±-------------------------------------------------------------------+real 8m36.447s
user 8m49.943s
sys 0m23.534s
1 Like
Cool. I’m going to be working on a release for testnet.
Just bear in mind btw, the performance of the network launched is unrelated to testnet. It’s just making it easier to get the local network up.
1 Like
Indeed - I should have timed it from thinking "Lets put up a test network and dump 4.3 gig of Scenery files in it (cos there are lots of them, all just <10Mb) and it is now considerably faster and easier between that thought and seeing the Files Container delivered.
Still I think it is encouraging for others to see that network performance remains good, despite major changes happening.
2 Likes
Need to tidy up the USAGE: for safenode as well…
willie@gagarin:~/projects/maidsafe/safe_network$ safenode bin-version
error: Found argument ‘bin-version’ which wasn’t expected, or isn’t valid in this contextUSAGE:
sn_node [OPTIONS]For more information try --help
safenode -V is our new friend here
willie@gagarin:~/projects/maidsafe/safe_network$ safenode -V
sn_node 0.79.0
I think bin-version comes from safe node and was never present in sn_node.
1 Like
This confusion just confirms that consolidating this functionality as safenode is a Good Thing
I never liked bin-version anyway… 
always felt non-std and -V is much more Unixy and “correct”.
Am I correct in thinking that sn_node will live on as the name of the crate and eventually all refs to sn_node in the docs will simply be to the crate itself and not any executable?
If so the USAGE clause in safenode needs brought into line. But thats just me nit-picking - thanks again @chriso for all your work on this 
1 Like
The crate name will remain as sn_node, yeah. The crate for the testnet binary is sn_testnet. It keeps a naming convention that’s inline with our other crates. Both crates have code in them beyond the binaries. They can be referenced by other crates, as both are.
Edit, also. yeah, I’ll change the the reference to sn_node in the help. Please continue to raise mistakes like that if you notice them. As small as they are, we want them to be corrected. I’ve taken a note to correct that one.
3 Likes
Dunno if this strictly the correct place for this…
New release Release Safe Network v0.1.0/v0.15.5/v0.20.6/v0.6.3/v0.82.3/v0.80.0/v0.80.2/v0.74.1 · maidsafe/safe_network · GitHub has no checksums for the binaries.
Im building from source so I’m not all that bovvered – but others might be…
Yeah thanks, I already have that bug on my list. It’s because the assets have been renamed from sn_node and sn_cli to safenode and safe, respectively. It will be fixed for the next release.
2 Likes
I have nearly the same GPU - NVIDIA GeForce GTX 1660 Ti - and also sometimes have the GPU fall off the bus and cause a freeze. I’ve only had it a couple of times in normal usage but I get it a bit when exiting a game.
If it’s the same issue you’ll no doubt have found that not even restarting the desktop manager or anything else works and the only thing for it is to reset using the power button which isn’t good. Not even a ‘sudo shutdown -r now’ from a remote terminal works for me. I’ve never totally got to the bottom of it and I’ve spent a lot of time going through Nvidia specific forums. It just seems to be something Linux isn’t doing properly with Nvidia GPUs and no one is bothering to fix it and the Nvidia people are saying it’s Linux’s fault and the Linux people are saying it’s Nvidia who are to blame, blah, blah.
The issue seems to be when something stops using the graphics card it can go unresponsive. The error seen in syslog is literally, ‘GPU has fallen off the bus.’
The thing that seems to help quite a bit is switching on persistence mode for the graphics card:-
nvidia-smi -pm 1
Apparently that will be deprecated soon and there is a new way of keeping the GPU kind of a bit active all the time detailed on this page:-
https://docs.nvidia.com/deploy/driver-persistence/index.html#persistence-daemon
nvidia-persistenced --user foo
but I’ve not got that to work yet.
When it does happen one step better than using the power button is the Magic SysReq B command. Just press Alt-SysReq-B in quick succession. No need to keep SysReq held down while pressing ‘B’. Just keep Alt held. It’s kind of the equivalent of Ctrl-Alt-Del but not many people know about it because linux never crashes, right?
details all the key combinations. A lot of which are obsolete or irrelevant now.
But anyway, it sounds like the same thing as with mine and if so the GPU isn’t faulty. But the relationship between the Nvidia and Linux developers is and the next Nvidia GPU you get will likely do the same thing. I might go AMD next time.
5 Likes
Thank you.
Yes I get the same hassle - only reliable fix for now is a power-cycle.
I’ll have a look at the nvidia-persistenced and see where I get with that but yes, looks like AMD for me next time as well.
Is safeup working or am I thick as a brick?
safeup ?
My impression was safeup will be along later. @chriso has yet to implement it.
Maybe I missed it…
I was under the impression it should work for safe but not for safenode?
Not entirely sure that impression is well founded
1 Like