Is it ok to boast about my bags? 
4 Likes
Aye OK on you go - just for a wee bit awright?
2 Likes
I’m totally thrilled that there is a new testnet already. The team is making great progress. 
Nessie wants to help out. Can she log in from underwater?
4 Likes
Dunno if Nessie would want to log on, this is slower than a wet Sunday in Stornoway
willie@gagarin:~$ time safe files -c 5 upload projects/maidsafe/test-sites/js
Built with git version: 8faf662 / main / 8faf662
Instantiating a SAFE client...
🔗 Connected to the Network Preparing (chunking) files at 'projects/maidsafe/test-sites/js'...
Making payment for 9 Chunks that belong to 3 file/s.
Transfers applied locally
After 25.715480518s, All transfers made for total payment of Token(144) nano tokens.
Successfully made payment of 0.000000144 for 3 records. (At a cost per record of Token(144).)
Successfully stored wallet with cached payment proofs, and new balance 99.999974832.
Successfully paid for storage and generated the proofs. They can now be sent to the storage nodes when uploading paid chunks.
Preparing to store file 'index.js' of 2799 bytes (1 chunk/s)..
Preparing to store file 'prefixfree.min.js' of 84359 bytes (4 chunk/s)..
Preparing to store file 'jquery.min.js' of 92556 bytes (4 chunk/s)..
Starting to upload chunk #0 from "index.js". (after 0 seconds elapsed)
Starting to upload chunk #0 from "prefixfree.min.js". (after 0 seconds elapsed)
Starting to upload chunk #3 from "jquery.min.js". (after 0 seconds elapsed)
Starting to upload chunk #0 from "jquery.min.js". (after 0 seconds elapsed)
Starting to upload chunk #3 from "prefixfree.min.js". (after 0 seconds elapsed)
Uploaded chunk #0 from "index.js" in 2 minutes 36 seconds)
Uploaded "index.js" in 2 minutes 36 seconds
Successfully stored 'index.js' to 43bd2bbb34626cb1fdb8ab9ba5b5c3fe9d146dab597ec37a9113019110569a9f
Starting to upload chunk #1 from "prefixfree.min.js". (after 2 minutes 36 seconds elapsed)
Uploaded chunk #3 from "prefixfree.min.js" in 2 minutes 37 seconds)
Starting to upload chunk #2 from "prefixfree.min.js". (after 2 minutes 37 seconds elapsed)
Uploaded chunk #3 from "jquery.min.js" in 2 minutes 53 seconds)
Starting to upload chunk #1 from "jquery.min.js". (after 2 minutes 53 seconds elapsed)
Uploaded chunk #0 from "jquery.min.js" in 3 minutes 39 seconds)
Starting to upload chunk #2 from "jquery.min.js". (after 3 minutes 39 seconds elapsed)
Uploaded chunk #0 from "prefixfree.min.js" in 5 minutes 21 seconds)
Uploaded chunk #1 from "prefixfree.min.js" in 4 minutes 35 seconds)
Uploaded chunk #1 from "jquery.min.js" in 4 minutes 20 seconds)
Uploaded chunk #2 from "prefixfree.min.js" in 4 minutes 48 seconds)
Uploaded "prefixfree.min.js" in 7 minutes 25 seconds
Successfully stored 'prefixfree.min.js' to a9ba85be24a112f0d2bd5e1b9c9349c477b678bb3e4485d4675e6ef0d3d2b128
Uploaded chunk #2 from "jquery.min.js" in 4 minutes 34 seconds)
Uploaded "jquery.min.js" in 8 minutes 14 seconds
Successfully stored 'jquery.min.js' to b0da55d3c1eeb5be4bc364a8d665f66bbc977acfa497b898adf83509c8499c91
Writing 166 bytes to "/home/willie/.local/share/safe/client/uploaded_files/file_names_2023-09-05_02-06-27"
real 8m58.109s
user 0m51.534s
sys 0m6.730s
But then I got better reults on a ~1Mb upload
Somebody please try downloading the .png
Successfully stored 'vroom.png' to 698ff7d68dac6ea21e97bea1204227e37f24541c2b151dc5650946dbf743e3d3
4 Likes
Is anybody uploading?
Not seeing any new chunks stored on 50 AWS nodes…
Registers fail
ubuntu@RewardNetNodesouthside01:~$ safe register create list01
Built with git version: 8faf662 / main / 8faf662
Instantiating a SAFE client...
🔗 Connected to the Network Successfully created register 'list01' at 1669dcb44877049a3fd4e507bf219e2dc17b97910cc689fa834a55e451db1d23894143f7fb346e5ea337c60b98c9b07fd8416feba05cbf6d1e0275d391c962913386c72148e7caefa179809944b2cbc7!
ubuntu@RewardNetNodesouthside01:~$ safe register edit list01 firstthing
Built with git version: 8faf662 / main / 8faf662
Instantiating a SAFE client...
🔗 Connected to the Network Error: Failed to deserialize hex RegisterAddress
Location:
sn_cli/src/subcommands/register.rs:162:20
ubuntu@RewardNetNodesouthside01:~$ safe register get list01
Built with git version: 8faf662 / main / 8faf662
Instantiating a SAFE client...
🔗 Connected to the Network Error: Failed to deserialize hex RegisterAddress
Location:
sn_cli/src/subcommands/register.rs:162:20
ubuntu@RewardNetNodesouthside01:~$ safe wallet get-faucet http://139.59.181.245:8000
Built with git version: 8faf662 / main / 8faf662
Error: Bincode error:: deserialized bytes don't encode a group element
Caused by:
deserialized bytes don't encode a group element
Location:
sn_cli/src/subcommands/wallet.rs:148:18
ubuntu@RewardNetNodesouthside01:~$ which safe
/home/ubuntu/.local/bin/safe
2 Likes
My uploads went overnight and still going in the morning at 1MB/s for 11 tiny files - I eventually control-c’d the op. It’s worked in the past, so something is definitely amiss with this net for me.
1 Like
Uploading a 1.8 GiB file fails for me with this error:
Making payment for 3770 Chunks that belong to 1 file/s.
Error: Failed to send tokens due to Network Error Not enough store
cost quotes returned from the network to ensure a valid fee is paid.
Uploading a 3 MiB file worked, took 1m25s to finish.
7 Likes
While trying to send tokens from node wallet to client wallet, I found little problem with documentation:
safe help wallet send describes <amount> as The number of nanos to send, however in reality it expects fractional value.
I was able to successfully merge tokens from two wallets, but UI is… not intuitive. Did anyone else was able to achieve such merge?
7 Likes
Went to sleep before reading this. My log was set to be SN_LOG=all safenode
My node is running though, below are the about 40 lines of logs that keep popping up.
[2023-09-05T05:39:00.849703Z INFO sn_node::log_markers] OperationFailedAfterNetworkInactivityTimeout
[2023-09-05T05:39:02.319317Z DEBUG sn_networking::event] AutoNAT outbound probe: Error { probe_id: ProbeId(408), peer: None, error: NoServer }
[2023-09-05T05:39:02.752338Z DEBUG sn_logging::metrics] {"physical_cpu_threads":8,"system_cpu_usage_percent":0.20030046,"system_total_memory_mb":8251.675,"system_memory_used_mb":2404.6755,"system_memory_usage_percent":29.141668,"process":{"cpu_usage_percent":0.0,"memory_used_mb":19.382273,"bytes_read":0,"bytes_written":0,"total_mb_read":0.036864,"total_mb_written":23.457792}}
[2023-09-05T05:39:07.758031Z DEBUG sn_logging::metrics] {"physical_cpu_threads":8,"system_cpu_usage_percent":0.22522523,"system_total_memory_mb":8251.675,"system_memory_used_mb":2405.7488,"system_memory_usage_percent":29.154673,"process":{"cpu_usage_percent":0.2002002,"memory_used_mb":19.386368,"bytes_read":0,"bytes_written":0,"total_mb_read":0.036864,"total_mb_written":23.457792}}
[2023-09-05T05:39:12.762684Z DEBUG sn_logging::metrics] {"physical_cpu_threads":8,"system_cpu_usage_percent":0.20035061,"system_total_memory_mb":8251.675,"system_memory_used_mb":2405.032,"system_memory_usage_percent":29.145987,"process":{"cpu_usage_percent":0.0,"memory_used_mb":19.382273,"bytes_read":0,"bytes_written":4096,"total_mb_read":0.036864,"total_mb_written":23.461887}}
[2023-09-05T05:39:17.767478Z DEBUG sn_logging::metrics] {"physical_cpu_threads":8,"system_cpu_usage_percent":0.2252816,"system_total_memory_mb":8251.675,"system_memory_used_mb":2405.2654,"system_memory_usage_percent":29.148813,"process":{"cpu_usage_percent":0.0,"memory_used_mb":19.386368,"bytes_read":0,"bytes_written":8192,"total_mb_read":0.036864,"total_mb_written":23.47008}}
[2023-09-05T05:39:22.772306Z DEBUG sn_logging::metrics] {"physical_cpu_threads":8,"system_cpu_usage_percent":0.2004008,"system_total_memory_mb":8251.675,"system_memory_used_mb":2405.7324,"system_memory_usage_percent":29.154474,"process":{"cpu_usage_percent":0.2004008,"memory_used_mb":19.382273,"bytes_read":0,"bytes_written":0,"total_mb_read":0.036864,"total_mb_written":23.47008}}
[2023-09-05T05:39:27.776012Z DEBUG sn_logging::metrics] {"physical_cpu_threads":8,"system_cpu_usage_percent":0.1752629,"system_total_memory_mb":8251.675,"system_memory_used_mb":2405.8552,"system_memory_usage_percent":29.155964,"process":{"cpu_usage_percent":0.0,"memory_used_mb":19.386368,"bytes_read":0,"bytes_written":0,"total_mb_read":0.036864,"total_mb_written":23.47008}}
[2023-09-05T05:39:30.850669Z TRACE sn_node::api] NetworkEvent inactivity timeout hit
[2023-09-05T05:39:30.850718Z INFO sn_node::log_markers] NoNetworkActivity(30s)
[2023-09-05T05:39:30.850766Z DEBUG sn_node::api] No network activity in the past 30s, performing a random get_closest query to target: NetworkAddress::PeerId( - 002064912a48b637bbfbcd1f277fa9c249722d5ddc48c5cce4ac954b940a85d26d09)
[2023-09-05T05:39:30.850794Z TRACE sn_networking] Getting the closest peers to NetworkAddress::PeerId( - 002064912a48b637bbfbcd1f277fa9c249722d5ddc48c5cce4ac954b940a85d26d09)
[2023-09-05T05:39:30.851142Z DEBUG sn_networking::replication_fetcher] Number of records still missing: 0
[2023-09-05T05:39:30.851205Z TRACE sn_networking::replication_fetcher] Sending out replication fetching 0 keys []
[2023-09-05T05:39:30.851263Z TRACE sn_networking::event] Query task QueryId(1224) returned with peers GetClosestPeersOk { key: [0, 32, 100, 145, 42, 72, 182, 55, 187, 251, 205, 31, 39, 127, 169, 194, 73, 114, 45, 93, 220, 72, 197, 204, 228, 172, 149, 75, 148, 10, 133, 210, 109, 9], peers: [] }, QueryStats { requests: 0, success: 0, failure: 0, start: Some(Instant { tv_sec: 37013, tv_nsec: 684070108 }), end: Some(Instant { tv_sec: 37013, tv_nsec: 684070108 }) } - ProgressStep { count: 1, last: true }
[2023-09-05T05:39:30.851367Z WARN sn_networking] Not enough peers in the k-bucket to satisfy the request
[2023-09-05T05:39:30.851376Z WARN sn_node::api] get_closest query failed after network inactivity timeout - check your connection: Could not get enough peers (8) to satisfy the request, found 1
1 Like
Can you double check the safe version you’re using. I’ve seen that with incompatible versions.
That sounds like a bug in the parsing perhaps. I’ll have a look.
@toivo seems like we’re seeing the DialNet issue here and with @josh perhaps? cc @bzee .
@Southside that does seem very slow for you indeed. Yesterday I was getting ~40s per chunk.
Most of this time will be verification though… We’re sending txs as well as the data, and each of those txs must be verified before we accept the data.
We’ve made no attempts to optimise this flow yet though, there may well be some low hanging fruit to be had.
In the short term you’ll probably get faster uploads with a higher concurrency setting, that’ll depend on your machine though.
5 Likes
1mb/s upload is not bad all things considered. What are we calling tiny here though? < 1mb files? 50mb files? If it’s uploading 1mb/s all that time, I’d find that very odd.
The command should itself time out after a number of retries.
Do you have some logs for this run? Or are you able to replicate with some logs?
5 Likes
safe.log.zip (193.9 KB)
11 files various sizes down to KB level, all totalling to 89.4 MiB
Does not appear to be timing out this go round - but I think it has in previous testnets.
Edit, also there is a whole folder of log files which were created from this one event - I just zipped the most recent one.
3 Likes
It’s looping over attempting to put files. So I’d wager we’re missing a limit on the loop somewhere there… hard to say without all the logs though, could you have a look and see how many times you have Attempting to PUT record of a788c563403801971b62f000 in your logs?
And then we have a Q over why the PUT failed… Which is proooobably price related. (ie, maybe the expected price changed… or maybe we’ve a bug in there; we’re still not retrying with a fresh store cost query eg yet).
edit:
I can see the PUT requests coming in to some nodes for this, but they’re not finding any DBC for them for some reason and so not storing the data. So something is bugging here 
4 Likes
In the log folder I did:
grep -o "Attempting to PUT record of a788c563403801971b62f000" * | wc -l
and received a result of 10.
edit: noticed there are lot of gzipped log files, so the grep wouldn’t have counted the searched for string in those. Unzipped and looked again, but got the same result of ‘10’
2 Likes
This all sounds truly amazing, looks like you have the finish line in sight!! 
I am still waiting for the quic / libp2p version before joining with a node (port forwarding did not do the trick properly here), but reading all this is fantastic! 
6 Likes
This might point to the issue. It is not doing AutoNAT. Are there any early log lines indicating dial errors? Perhaps you can upload your full log file, would be really helpful!
3 Likes
Here are all the lines of another try for a node last night, that I thought was dead after no more logs after a couple minutes. The current one started out the same:
[2023-09-04T19:45:19.333225Z INFO safenode]
Running safenode v0.89.16
=========================
[2023-09-04T19:45:19.333240Z DEBUG safenode] Built with git version: 8faf662 / main / 8faf662
[2023-09-04T19:45:19.333243Z INFO safenode] Node started with initial_peers ["/ip4/159.65.7.57/tcp/35367/p2p/12D3KooWL7A4j2PoZyXaiwhPxZaHcPvjNfejNgQL1BBeqV3S6bZW"]
[2023-09-04T19:45:19.333904Z INFO safenode] Starting node ...
[2023-09-04T19:45:19.335062Z INFO sn_networking] Node (PID: 4463) with PeerId: 12D3KooWKQ3KoMsdMLMwua18FKvXnrkNgAgXG2SFPD1ASio6gquu
[2023-09-04T19:45:19.335079Z INFO sn_networking] PeerId: 12D3KooWKQ3KoMsdMLMwua18FKvXnrkNgAgXG2SFPD1ASio6gquu has replication interval of 369.119422383s
[2023-09-04T19:45:19.335125Z DEBUG sn_networking] Using Kademlia with NodeRecordStore!
[2023-09-04T19:45:19.335746Z DEBUG sn_networking] Preventing non-global dials
[2023-09-04T19:45:20.038792Z DEBUG sn_logging::metrics] {"physical_cpu_threads":8,"system_cpu_usage_percent":3.107861,"system_total_memory_mb":8251.675,"system_memory_used_mb":2381.1729,"system_memory_usage_percent":28.856844,"process":{"cpu_usage_percent":0.0,"memory_used_mb":15.233024,"bytes_read":0,"bytes_written":0,"total_mb_read":0.12288,"total_mb_written":0.073728}}
EDIT:
My current node, that is active, though not doing anything, is also missing record_store and wallet folder, and the secret key. Theres only logs folder
2 Likes
Curious, if that is all the logs there are, did the node get killed?
1 Like
Killed it myself. I DM you the logfiles of my current node. They are also bit weird as it seems to me that the first logfile is empty?
1 Like