I’m definitely running Win 10 Pro, there were such bugs in previous tests and I posted about them on the forum, I thought they were taken into account in the bug analysis.
Do you think I should try changing my Windows antivirus settings? 
However, I was able to run the client and transfer files in earlier tests.
Roll up, roll up, join the quicnet. Be amazed by how quic it is, your data will be in the SafeCloudsTM before your realise. Roll up, roll up …
The year of solutionNets continue.
This testnet seems to be very QUIC
Installed on Linux! Started my node with no issue.
The machine is on a VPN connected to NAT router.
Amazing!
So uploading for the past hour and yep, blazing fast speed this time. I’ve a slow connection so was unsure if I’d get the same level of increase others are getting, but it’s easily 4x what it was in the past.
Great work team - QUIC is quick.
i have 1 node running in AWS and 5 at home and all getting records and earning.
1 home node is at 137MB. It doesn’t have the most PUTs at 647 but it does have the most GETs with 851.
The home nodes joined without an issue like previous testnets.
Do remember to switch your Firewall Rules or AWS Security Groups from TCP to UDP!
Given the rapid growth in records - already about 40% full after just an hour - which is presumably because of the faster uploads I think we’re going to run out of capacity a lot quicker than normal. Which is good in a way as the speed is real progress. But this testnet might burn brightly but briefly.
It didn’t solve them, but it did change the behaviour somewhat:
Previously:
Now:
Other problems:
My 2 GB upload just does not finish, not even after several router reboots. It is just 5 chunks shy and stays so despite several retrys. This happens over and over. It also charges some coins each time:
time safe files upload ubuntu-18.04.4-desktop-amd64.iso -p
Logging to directory: "/home/topi/.local/share/safe/client/logs/log_2024-01-31_09-08-51"
Built with git version: a15b141 / main / a15b141
Instantiating a SAFE client...
Trying to fetch the bootstrap peers from https://sn-testnet.s3.eu-west-2.amazonaws.com/network-contacts
Connecting to the network with 43 peers
🔗 Connected to the Network "ubuntu-18.04.4-desktop-amd64.iso" will be made public and linkable
Starting to chunk "ubuntu-18.04.4-desktop-amd64.iso" now.
Uploading 5 chunks
⠉ [00:00:55] [----------------------------------------] 0/5 Retrying failed chunks 5 ...
Unverified file "ubuntu-18.04.4-desktop-amd64.iso", suggest to re-upload again.
**************************************
* Uploaded Files *
**************************************
Among 5 chunks, found 0 already existed in network, uploaded the leftover 5 chunks in 2 minutes 23 seconds
**************************************
* Payment Details *
**************************************
Made payment of 0.000000090 for 5 chunks
Made payment of 0.000000009 for royalties fees
New wallet balance: 599.997637373
real 2m23,703s
user 0m11,205s
sys 0m5,442s
Also another weird thing, paging @qi_ma and @joshuef:
I killed my nodes in one terminal window, but the information about the termination was printed in another, where downloads were going on, like this:
Uploading 5 chunks
⠉ [00:01:15] [----------------------------------------] 0/5 Retrying failed chunks 5 ...
Unverified file "ubuntu-18.04.4-desktop-amd64.iso", suggest to re-upload again.
**************************************
* Uploaded Files *
**************************************
Among 5 chunks, found 0 already existed in network, uploaded the leftover 5 chunks in 2 minutes 46 seconds
**************************************
* Payment Details *
**************************************
Made payment of 0.000000030 for 5 chunks
Made payment of 0.000000003 for royalties fees
New wallet balance: 599.997637472
[1]- Terminated nohup safenode --port=12000
[2]+ Terminated nohup safenode --port=12001
real 2m47,050s
user 30m0,518s
sys 11m31,094s
Also, this apparently successful upload was not written to my uploaded files list, and thus didn’t download with the safe files download -command. Two other files did.
$ time safe files upload Waterfall_slo_mo.mp4
Logging to directory: "/home/topi/.local/share/safe/client/logs/log_2024-01-30_21-07-36"
Built with git version: a15b141 / main / a15b141
Instantiating a SAFE client...
Trying to fetch the bootstrap peers from https://sn-testnet.s3.eu-west-2.amazonaws.com/network-contacts
Connecting to the network with 43 peers
🔗 Connected to the Network Starting to chunk "Waterfall_slo_mo.mp4" now.
Chunking 1 files...
Uploading 114 chunks
**************************************
* Uploaded Files *
* *
* These are not public by default. *
* Reupload with `-p` option *
* to publish the datamaps. *
**************************************
"Waterfall_slo_mo.mp4" c61ffa6aa89fc1e518e9f114e24738cc11bf7f78812a698d3fd3671257d12076
Among 114 chunks, found 0 already existed in network, uploaded the leftover 114 chunks in 49 seconds
**************************************
* Payment Details *
**************************************
Made payment of 0.000043444 for 114 chunks
Made payment of 0.000007606 for royalties fees
New wallet balance: 599.999947601
real 0m51,270s
user 0m32,083s
sys 0m13,493s
I’m on Ubuntu 22.04.3 LTS.
I had the same issue with my large upload. Some chunks wouldn’t go up, and couldn’t download the parts that were uploaded.
Hoping the cause of this can be identified, as so far this test is very close to extremely awesome!
Edit: My upload was 35.7gb with 66 bad chunks on first go and I think around 80 on the second attempt, so both of us were getting around 2 to 2.5 bad chunks per GB.
By the way I actually uploaded first without the -p flag, and after the first upload, that was 980 chunks shy, added the -p. Now, when I tried to re-upload the remaining 5 without -p, I got two more chunks in, but after that no more with or without -p.
I’m seeing that behaviour as well on a cloud vps and a home connection on 1gbs line so it might not be your router
Do you guys also get charged even when no advance is made?
Yes. Every time I retry the failed chunks.
I’m not sure you’ll get many rewards, but we’ll see.
I think autonat would normally shut down such nodes, so it may be that the network suffers as a consequence.
Hmm, that’s client side for the most part, I think? Would have been available in the last client versions during the last testnet. (Although I may be wrong).
I think with the last one going so long, I may well be missing features out of the notes here as you have noted! There’s more cleanup going on the background as per a few client version ago. So that’s probably what you’re seeing here.
Oh interesting. Something wrong in verificaiton there. @qi_ma did put in a fix related to uploads yesterday, and there was another follow up going in just now. So that mayyy help.
I’d be curious to get logs of the initial upload and any failing re-upload if you have them?
Just to confirm, it was another terminal, not the one you’d used to kill nodes being reused after that? (I have seen that with a variety of CLIs in general if output is printed from bg processes. Another terminal window all together is very odd. cc @chriso here in case you’ve any idea?)
Can you or @DavidMc0 shoot us some logs for this recharge w/ no upload? 
Yeap, same here. I tried a few files over 200mb and getting some chunks not getting uploaded even after a few retries, and charged for it.
But overall I have to say it feels much QUICker!
Nodes also chunking away with good distribution.
PS been AFK for a while…but great to be back testing! 
I have to go out just now, but will get them to you later today if Toivo (Edit: or Stout!) doesn’t get there first.
You got me there! The nodes were started in that terminal and the kill command was given in another. So I guess it went just right. I usually keep node and CLI windows separate, but this time I used the node terminal to proceed with CLI stuff.
Logs below if needed @joshuef
"log_2024-01-30_21-06-21.zip" cac80665144dd0d825eb3c612f7a2f15f776bcd891e05d7931e5a9b3e82ff90b
15 nodes from home not earning anything (around 12h uptime).
I’ve just opened the same ports for UDP, just in case TCP was enough. I couldn’t read much more into details…
I was earning with the same setup in the previous testnet.
Apologies, I think those might have been the initial logs at connection.
Here are the latest ones:
"safe1.log" 91f7252ea2debff36c5ed5c7c86addd3b2dfb7f4c385ba6af9f565059e273c10
"safe2.log" 1b2c316a2679b66d9c6ec0343965d84556a9f06a2398f208b57f250eb74c220a
"safe3.log" 4f287e269b823028b636e5ed558d5a6d5becca986b1de849e19d4e2eaea915dd
"safe4.log" a39862e2ccb0f6f677c74598663d18583c3095db7569ccb00714b2c23c92645b
"safe5.log" 5463cd43345a2b65c23429f3ebbe480b3c5d0339e2b640f0b9f9e0d86a80c612
"safe6.log" 15ccf1d3c7c38420850f02732c0dd5f5fc2701fdb46dd93f5e7814b972366654
Unless you forwarded ports then these nodes are not really connected to the network to receive payment.
It’s really best right now if you are behind a NAT router to manually port forward or just leave it for now. Hopefully the libp2p guys will get this NAT traversal sorted soon though.