NodeDiscoveryNet [07/07/23 Testnet] [Maidsafe nodes offline]

What is the current plan for target node size?

hmm… , if the client find enough 20 peers for long time, the put_record could be risky as well ?

Diving about our nodes, looks like the stats script is broken and we’re overreporting record counts here. (one node reports > 2048 records, but checking on the machine it has ~

Going about fixing that now.

edit: aye a tweak was missing after the data-dir refactor. Grabbing some more stats now.

3 Likes

Okay that’s fixed. Now we’re not counting log files per node also :man_facepalming:

And with that, I can see we do not have any full nodes yet.

4 Likes

That is right, the Working Set Size (windows)/Resident Set Size (linux) contains both the shared + private data, with some minor differences across OS.
Currently, we make use of the sysinfo rust crate to fetch the mem usage. It uses the rss/wss values as you had mentioned. It is the similar case across the other rust crates and there is no easy drop in replacement to just fetch the private bytes.

So we might have to write a custom “private bytes” fetcher if we were to display that. But I do think the rss/wss provide a reading that is accurate enough for our current use case.

9 Likes

If folk make changes to MAX_RECORDS_COUNT will those nodes get rejected?

Just for clarity not saying this should be done but shouldn’t be done is rarely enough to stop things from happening.

1 Like

Not at the moment. I’m not sure how we’d detect that. I don’t think there’s an issue to doing it, so much as it’s not beneficial to that node?

(That would effectively be becoming an archive node, perhaps.)


Wee updates:

  • heaptrack has consistently told us high mem is coming from new connection’s being established. We’ve just been looking over some logs and found a suspiciously high amount of connections going to each peer (sometimes even hundreds!). This is something libp2p should be handling for us, so either we’re doing something wrong , or we’ve found a bug!. @bzee is diving about here just now. (It’s even more suspect as we’re supposed to have stream multiplexing in place, it is configured w/ defaults etc, but new conns are always going to new ports.)
  • we’re still eyeballing the suspect data replication flows to see if we can turn up a bug there
9 Likes

I was leaning slightly more toward negative for the network.

The way I understand it general consensus is smaller nodes are better for the network, so does that mean an attacker benefits from launching a bunch of large nodes and then killing them at once.

But as you say, essentially an archive node.

2 Likes

It is accurate in case where OS have plenty of free RAM and have no need to make swapping.

Other approach may be to keep track of allocated bytes inside of a program. But I don’t know how easy to do this in Rust.

This is odd, no? 3 days ago my DO node had this,

today it has,

du -sh record_store 301M	record_store
ls -1 record_store | wc -l 836

On the face of it (simply looking at logs) it is running just fine.


Second node running from home with port forwarding.

du -sh record_store 601M	record_store
ls -1 record_store | wc -l 1605
5 Likes

Unfortunately I did not manage to join the tests in time, but as they say “better late than never”.

Please give me instructions on how to get the client up and running - maybe I will be useful for something :slight_smile:

4 Likes

Next run
safeup client -v 0.79.5

Then
export SAFE_PEERS="/ip4/54.82.83.176/tcp/35175/p2p/12D3KooWPhVptRnwNXfqtENhq1GNxCnyNBPcJu7xALPFQ72KTBii"

and you should be good to upload/download.

4 Likes

There would appear to be an effective limit on the size of uploads between approx 11-15Mb. Can anyone else confirm?

Begblag 15Mb mp3 fails
slow-blow-debug1.txt 11Mb text is stored OK


willie@gagarin:~$ safe files upload begblag.mp3 
Built with git version: 95b8dad / main / 95b8dad
Instantiating a SAFE client...
⠂ Connecting to The SAFE Network...                                             The client still does not know enough network nodes.
🔗 Connected to the Network                                                     Storing file "begblag.mp3" of 15766382 bytes..
Did not store file "begblag.mp3" to all nodes in the close group! Network Error Record not put to network properly.
Writing 8 bytes to "/home/willie/.local/share/safe/client/uploaded_files/file_names_2023-07-10_17-41-47"
willie@gagarin:~$ safe files upload slow-blow-debug
slow-blow-debug1.txt  slow-blow-debug.txt   
willie@gagarin:~$ safe files upload slow-blow-debug.txt 
Built with git version: 95b8dad / main / 95b8dad
Instantiating a SAFE client...
⠂ Connecting to The SAFE Network...                                                                                                                                          The client still does not know enough network nodes.
🔗 Connected to the Network                                                                                                                                                  Storing file "slow-blow-debug.txt" of 9452831 bytes..
Successfully stored file "slow-blow-debug.txt" to 80d6abd59b44971972899968ab52337602a3f61babf65fdae2c0115bfb289267
Writing 67 bytes to "/home/willie/.local/share/safe/client/uploaded_files/file_names_2023-07-10_17-53-13"
willie@gagarin:~$ safe files upload slow-blow-debug1.txt 
Built with git version: 95b8dad / main / 95b8dad
Instantiating a SAFE client...
⠂ Connecting to The SAFE Network...                                                                                                                                          The client still does not know enough network nodes.
🔗 Connected to the Network                                                                                                                                                  Storing file "slow-blow-debug1.txt" of 11193884 bytes..
Successfully stored file "slow-blow-debug1.txt" to 4cbe70994d84a2be8f1dadccde9de5ce9b1a1ca1e542def9a93691f1d0c11837
Writing 68 bytes to "/home/willie/.local/share/safe/client/uploaded_files/file_names_2023-07-10_17-53-58"

Unfortunately after entering the command : safeup client -v 0.79.5 the binaries do not install

Am I doing something wrong?

Actually on Powershell it’s a bit different to set the peer:

$env:SAFE_PEERS = "/ip4/54.82.83.176/tcp/35175/p2p/12D3KooWPhVptRnwNXfqtENhq1GNxCnyNBPcJu7xALPFQ72KTBii"
safe files upload -- <path>
1 Like

Are you pasting three commands there?

Better to run them individually.

1 Like

After entering the command: safeup client -v 0.79.5
there was no response.

I later entered another one to try it out.

Open a new Powershell session please, and run each of these commands individually:

safeup --version
safeup client -v 0.79.5
safe --version

Post a screenshot of the output please.

1 Like

Btw, I would highly recommend installing/using the new Windows Terminal:

2 Likes

I understand that this is a Windows update for, among other things, PowerShell?