Re: Vdash
It must be kept running the whole time, or only very short down time. The reason is that it’s a log parser, and the node logs (especially home-node logs) grow pretty quickly. Node’s will rotate to a new log file every 20MB. So if you miss a rotation, vdash will be out of sync.
Testnet is working fine for me, got some test tokens, uploaded and downloaded an image.
Then tried with a larger file (1GB) and it chunked and split into 2048 chunks, and the speed was a bit slow - took around 27 minutes to upload, which might be a drawback for people that wish to upload a lot of media content. The progress loader is great, helps to know it’s moving along.
Did you try setting your --batch-size higher on the upload default batch size is 12 I think try 100 
Update.
I’m not a network guy, so just general observation here: nodes running better than last test-net for me.
Twice as many nodes from home, Half as much shunned.
Half as many errors.
Ram average staying the same around 33.
Thousands of records more, than the last one.
Earning thousands of more nanos too.
This train looks steady to me. Cheers
wow network is running very nicely
5GB randome data file as i can not find any more Linux iso that have not already been uploaded to use
upload went up first time with no repayment errors in 22 minutes batch size 224
home network fiber broadband 1000 down 100 up
ubuntu@sha:~$ time safe files upload -p 5GB-test.txt --batch-size 224
Logging to directory: "/home/ubuntu/.local/share/safe/client/logs/log_2024-05-14_18-58-52"
safe client built with git version: 16f3484 / stable / 16f3484 / 2024-05-09
Instantiating a SAFE client...
Connecting to the network with 49 peers
🔗 Connected to the Network Chunking 1 files...
"5GB-test.txt" will be made public and linkable
Splitting and uploading "5GB-test.txt" into 10244 chunks
**************************************
* Uploaded Files *
**************************************
"5GB-test.txt" 7f3d626274d70ba0dd3a1e61b7e23cd86e508d9ca102ea55a5bc540b74c804c2
Among 10244 chunks, found 0 already existed in network, uploaded the leftover 10244 chunks in 20 minutes 19 seconds
**************************************
* Payment Details *
**************************************
Made payment of NanoTokens(690337839) for 10244 chunks
Made payment of NanoTokens(121819371) for royalties fees
New wallet balance: 3.187842374
real 22m34.521s
user 37m27.946s
sys 10m3.102sIt seems like my router can’t handle the 100 nodes I’ve set up from home this week. My internet connection randomly drops. Has anyone else experienced this?
yes try using a 5 min interval for the nodes starting and start with 30 nodes then slowly add more till you find the sweet spot.
Thanks, I will try
and if you are using Ubuntu and would like some monitoring you could checkout NTracking
sn_networking version should be Semvar compatible + it requires the same protocol.
Ie, it’s possible launch a testnet that is restricted, so to join that you need to have the same restriction set when building code (As well as the same sn_networking version). If we do this, we’ll document this in a post for that network for folk wanting to self-build 
Otherwise for stable networks it’s sn_networking version numbering.
(cc @roland correct me if I’m wrong there!)
Here lies a new version of the launchpad.
There’s a few tweaks and bits here:
sudo on unix platformsDiscourse or Discord? I gather this is for the upcoming beta program
good spot. I’m forever choosing the wrong one here. Comment updated for that! thanks @neo
(and yes, it’s for beta scheme!)
We may be at cross purposes here because I’m still not understanding how to use the information you are giving.
My app uses several (~5 from memory) sn_ crates, I’m not sure sn_networking is one of them. Maybe.
They represent the API, not just the protocol, so I am asking how to manage what is in my Cargo.toml both for builds using crates.io and, on occasion if I’m debugging more deeply with a local copy (or fork) of safe_network.
Thanks for your input on this!
Is the Peer ID the same as the XOR address of the node? If not how can I find the xor address of the node?
I have been noticing that when a machine starts exhibiting high cp usage it generally never returns down the cpu levels that other machines running the same amount of nodes are using.
after getting one machine that got into trouble when I increased the node count from 50 to 60.
I stopped the additional 10 nodes last night this morning it was still using around 90% cpu.
after greping the logs for considered as bad I stopped those safe nodes.
ubuntu@s26:~$ grep -r "$(date '+%Y-%m-%dT')" /var/log/safenode/ | grep "us as BAD"
/var/log/safenode/safenode3/safenode.log.20240515T053229:[2024-05-15T01:37:22.843118Z WARN sn_networking::event::request_response] Peer NetworkAddress::PeerId(12D3KooWBFpe5QCrktZbPLtvLCJdF1kbyWdmNCxVbSrs9eqgcx73 - 44db808313a1ec5eec0b5fc598e3f3ff940c4e642539166c35da012cd059a0ac) consider us as BAD, due to "ConnectionIssue".
/var/log/safenode/safenode28/safenode.log:[2024-05-15T13:50:37.858167Z WARN sn_networking::event::request_response] Peer NetworkAddress::PeerId(12D3KooWAgyeUcAJWhj5Vf5ZwZJr82zsiG8KH1XZx6mWgKKmbFAn - 6569eccc37729abb183032e30450334228d9fb7c23da2332b2558af6d103a9c3) consider us as BAD, due to "ConnectionIssue".
/var/log/safenode/safenode18/safenode.log:[2024-05-15T10:19:28.752135Z WARN sn_networking::event::request_response] Peer NetworkAddress::PeerId(12D3KooWL7BFKxFVNxAfJd1ySzJmN97hMsJFYgYv3BQF3BECcYha - de7388488efcba7341e9b8db80eff32c230a48f86c46f8779f0db70845e2447b) consider us as BAD, due to "ConnectionIssue".
/var/log/safenode/safenode4/safenode.log:[2024-05-15T10:08:39.363549Z WARN sn_networking::event::request_response] Peer NetworkAddress::PeerId(12D3KooWN65jGMmUWZKaCXzdQ4CBgGQdxBMSa9LRKaujVFUnsM2E - 7cd860bba6ac02d263d372ff0e9ff89e41c273bf6690583f76b6515ed7619ebf) consider us as BAD, due to "ConnectionIssue".
/var/log/safenode/safenode19/safenode.log.20240515T085726:[2024-05-15T02:21:25.003916Z WARN sn_networking::event::request_response] Peer NetworkAddress::PeerId(12D3KooWSDqDMx81b9po2QF8zVzC4qUxCdNvQa9Lnx9MofTzhLVh - e60a3cb90212eaa6f5c7f0b75624cfd9412708e2f7e8d90e597dbccd2ad95f3c) consider us as BAD, due to "ReplicationFailure".
/var/log/safenode/safenode21/safenode.log.20240515T073114:[2024-05-15T04:11:47.698150Z WARN sn_networking::event::request_response] Peer NetworkAddress::PeerId(12D3KooWDBz3RMmt39RzaVeUQZuXVVYReso6sYLzDRyrxcASLdgu - afd0f26a46619457612a31acda0f2bfd6ec5fdacdfc525f4ad930d5b791c369e) consider us as BAD, due to "ConnectionIssue".
/var/log/safenode/safenode12/safenode.log:[2024-05-15T12:43:17.528340Z WARN sn_networking::event::request_response] Peer NetworkAddress::PeerId(12D3KooWBxRd75NtUVyGUR5C5CwgPoUyMAY8nCJXS5EQ6fyacPjr - f6af1e9f1ae8f73836d1a63ee067f6b8ecacd04b0586180506700c5465b6363a) consider us as BAD, due to "ConnectionIssue".
/var/log/safenode/safenode46/safenode.log:[2024-05-15T14:18:28.926536Z WARN sn_networking::event::request_response] Peer NetworkAddress::PeerId(12D3KooWAbR3SoewCWPgSmbJUqeVuTLfj1V8UfTMhznAqHMKZtEW - fadfc3c9921ad4e804b2a8901f708cce84d4e8e74e449b207c93d5884b13cf3b) consider us as BAD, due to "ConnectionIssue".
/var/log/safenode/safenode46/safenode.log.20240515T132758:[2024-05-15T06:24:45.691154Z WARN sn_networking::event::request_response] Peer NetworkAddress::PeerId(12D3KooWNgFt2S1nyHVCL6TQQcnK7d3QgCSfgqWPx4vmFUjnJv1r - f83cfd6810a64496884d86a4355c4a103a3359e77b3b41774650ac3e3fae3788) consider us as BAD, due to "ConnectionIssue".
/var/log/safenode/safenode37/safenode.log.20240515T123301:[2024-05-15T05:07:22.221516Z WARN sn_networking::event::request_response] Peer NetworkAddress::PeerId(12D3KooWRFXYez35pHU8ovv17aFTokTuS5iCSU5JQaibUvKn3FmB - ac77b40dca40bc6622d353f0ee31efe24ce3b1ac672deb79ac159caed5d883a9) consider us as BAD, due to "ReplicationFailure".
/var/log/safenode/safenode31/safenode.log.20240515T131953:[2024-05-15T01:52:44.080612Z WARN sn_networking::event::request_response] Peer NetworkAddress::PeerId(12D3KooWDX2yhNuRqHVxhHWxP3K9hDyzQB2ft8KEYxjRZ3ek7zfc - 8d017b81bcf61826df8d8b0f8262967359da00bd1732268ed1b0d780a67940b9) consider us as BAD, due to "ConnectionIssue".
ubuntu@s26:~$
ubuntu@s26:~$
ubuntu@s26:~$ sudo $HOME/.local/bin/safenode-manager stop --service-name safenode28 --service-name safenode18 --service-name safenode4 --service-name safenode19 --service-name safenode21 --service-name safenode12 --service-name safenode46 --service-name safenode37 --service-name safenode31
╔════════════════════════════╗
║ Stop Safenode Services ║
╚════════════════════════════╝
Refreshing the node registry...
Attempting to stop safenode28...
✓ Service safenode28 with PID 64249 was stopped
Attempting to stop safenode18...
✓ Service safenode18 with PID 34913 was stopped
Attempting to stop safenode4...
✓ Service safenode4 with PID 6542 was stopped
Attempting to stop safenode19...
✓ Service safenode19 with PID 37283 was stopped
Attempting to stop safenode21...
✓ Service safenode21 with PID 42508 was stopped
Attempting to stop safenode12...
✓ Service safenode12 with PID 19826 was stopped
Attempting to stop safenode46...
✓ Service safenode46 with PID 148154 was stopped
Attempting to stop safenode37...
✓ Service safenode37 with PID 100015 was stopped
Attempting to stop safenode31...
✓ Service safenode31 with PID 75318 was stopped
after those nodes were stopped the cpu usage dropped down to 49%
it apears that "us as BAD" nodes start hogging the cpu and jam up the machine they are running on.
here are the logs from the "us as BAD" nodes in case they are useful.
thx for sharing the info.
Had a quick scan through the shared logs.
It seems the internal usage report , for example:
sn_logging::metrics] {"physical_cpu_threads":4,"system_cpu_usage_percent":28.893938,"process":{"cpu_usage_percent":13.062615,
doesn’t show there is high CPU usage.
the usage does rise sometime to say 13% but will drop back to say 4%-6% after sometime.
Will have a further look on it.
That means that I need to run it in the background like this?
vdash -g /var/log/safenode/*/safenode.log > /dev/null 2>&1 &
I think you won’t then be able to connect to it. I run it in screen.
type screen. You’ll then be presented with a blank screen. run vdash with vdash -g /var/log/safenode/*/safenode.log as you were going to.
Then to detach from the screen hold down ctrl and then press a then d.
Then to attach to the screen again do:-
screen -r
Read the man page for screen for more useful commands.
Yes, this. I also find it useful to give screens names of you’re going to use more than one
screen -S *name here* *command here*
Then you can reconnect to a named screen with
screen -r *screen name*
The command you gave, @Future, will send all output to null. So your logging / checkpointing will work, but you’d need to kill that command before running again in the foreground so the checkpoint files won’t get messed up.
Edit : @storage_guy beat me to the edit.
Also, key point. Once in a “screen” the key combo
Ctrl +a, then ctrl +d will detach you from the screen back to your normal terminal.