Announcement: Latest Release Feb 27, 2025

Development Updates
1

:loudspeaker: Announcement: Latest Release :loudspeaker:

Please follow these instructions to upgrade your nodes to the newest version to ensure the best performance and stability for everyone! We removed Home Network from the connection modes. Relay can only be selected by using Automatic in the case where UPnP fails. We are trying to avoid the use of relays when UPnP is available. Check out the Github Release with changelog details.

For Node Launchpad Users:

  1. Open Node Launchpad v0.5.5 if you are not already on that version
  2. Press O to access the Options screen.
  3. Then, press Ctrl + U, and hit Enter. This will upgrade your nodes. Upgrading can take several minutes for each node. Please don’t close the app or stop your nodes during this process.
  4. Your nodes will now stop
  5. Press Ctrl + S to start your nodes again
  6. We recommend using the Automatic mode if you want to use UPnP or relays.

For CLI Tool Users:

  1. If you’re using the CLI tool, please update and upgrade. Run the update first: antup update
  2. Then run the upgrade: antctl upgrade --interval 60000
  3. The add command will now use --upnp by default, and if you don’t want to use it, you need to explicitly use --no-upnp

For ALL Users:

  • Please start your nodes gradually — especially if you plan on running multiple nodes.
  • Be conservative with CPU allocation to maintain stability

Binary Versions:

  • antnode: v0.3.7
  • antctld: v0.12.0
  • antctl: v0.12.0
  • ant: v0.3.8
  • nat-detection: v0.2.17
  • node-launchpad: v0.5.5
17 Likes
2

image
image474×289 31.1 KB

Thank you.

You guys are moving lightning fast.

8 Likes
3

Anyone have nodes running via antctl after running antup update? I’ve tried using port forwarding, UPnP, and relay, and I end up with nothing running.

3 Likes
4

nope can’t get them started, even adding the --no-upnp flag to antctl add, just investigating…

reboot cleared it :smiley:

6 Likes
5

Should this be the command to add new nodes with port forwarding?

antctl add --count 500 --node-port 50001-50500 --rewards-address address evm-arbitrum-one

Check out the Dev Forum

2 Likes
6

For the antctl, yes.

Then if firewall you need to open the ports
Then if behind a router, then port forward the ports to that PC

Extra info for anyone who needs it

3 Likes
7

You must put --no-upnp after the number of nodes, otherwise they will not start:

antctl add --count 500 --no-upnp --node-port 50001-50500 --rewards-address address evm-arbitrum-one

Check out the Dev Forum

4 Likes
8

ant v0.3.8

ant file cost. (4GB)

Error:
0: Failed to calculate cost for file
1: Cost error: Not enough node quotes for 62f5f8(01100010)…, got: 4 and need at least 5
2: Not enough node quotes for 62f5f8(01100010)…, got: 4 and need at least 5

‘ant file cost’ takes a long time and uses a lot of resources for movie sized files (4GB)

I’d like to see a ‘quick quote’ function that is maybe within 10% of actual cost, to get a ball park figure. Just divide file size by chunk size or something…I’m guessing currently it’s actually chunking the file into memory.

1 Like
9

First, I (accidentally) tried the using the old client again, with (hopefully) lots of upgraded nodes.

I tried an upload of an Ubuntu ISO over wifi and I had my old friend ‘wifi disconnect’. Right before that, my internet speed was dog slow, which presumably was a sign of impending wifi collapse doom.

Note that this is to a router that does not do the NATing. It is purely routing wifi traffic to a Mikrotik router that handles the heavy lifting.

Eventually, it gave up (my wifi flashed up and down a few times, but couldn’t complete the task), with the following:

ant file upload -p ubuntu-24.04.1-live-server-amd64.iso
Logging to directory: "/home/paul/.local/share/autonomi/client/logs/log_2025-02-28_09-40-21"
🔗 Connected to the Network                                                                                                                                                             Uploading data to network...
Encrypting file: "ubuntu-24.04.1-live-server-amd64.iso"..
Successfully encrypted file: "ubuntu-24.04.1-live-server-amd64.iso"
Paying for 663 chunks..
Error: 
   0: Failed to upload file
   1: Failed to upload file
   2: Error occurred during payment.
   3: Cost error: CouldNotGetStoreQuote(f7a39e(11110111)..)
   4: Could not get store quote for: f7a39e(11110111).. after several retries

Location:
   ant-cli/src/commands/file.rs:70

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

So, updated to latest client. Wifi was once again slow, with web pages taking many seconds to load (which are usually instant). Then it dropped again… it took out the wifi router (Fritz.Box 7530), dropping other devices off the wifi network too.

I’ve not seen this wifi error for a while, but it was a frequent flyer just after the QUIC window size was made large during the tests. When it was small, my wifi survived well. Up until today, I’d not seen this issue for a while though.

Sadly, the new version failed too, with a similar error:

paul@mini-vader:~/Downloads$ ant --version
Autonomi Client v0.3.8
Network version: ant/1.0/1
Package version: 2025.1.2.6
Git info: stable / c7c15e9 / 2025-02-27
paul@mini-vader:~/Downloads$ ant file upload -p ubuntu-24.04.1-live-server-amd64.iso
Logging to directory: "/home/paul/.local/share/autonomi/client/logs/log_2025-02-28_09-52-18"
🔗 Connected to the Network                                                                                                                                                             Uploading data to network...
Encrypting file: "ubuntu-24.04.1-live-server-amd64.iso"..
Successfully encrypted file: "ubuntu-24.04.1-live-server-amd64.iso"
Paying for 663 chunks..
Error: 
   0: Failed to upload file
   1: Failed to upload file
   2: Error occurred during payment.
   3: Cost error: CouldNotGetStoreQuote(d09c29(11010000)..)
   4: Could not get store quote for: d09c29(11010000).. after several retries

Location:
   ant-cli/src/commands/file.rs:77

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

Wifi only went down the once though… small mercies! :sweat_smile:

3 Likes
10

I have not been involved in the quoting side, but this seems a bot too fragile. cc @qi_ma (who knows more). But requiring ALL 5 close nodes seems to mean we want 100% of close nodes involved and that is too high. I wonder if this should in fact be just get a majority of quotes (so 3) and use that to work out the accepted cost (the middle one).

This looks like it is a major factor in uploads failing.

10 Likes
11

It’s not, acutally to be 5 out of the close 7 nodes

We have experimented that, won’t help much.
it also affects the quoting and payment as well.

Yes, however the root reason is mostly client outgoing connection error that can cantacted some of the close 7 nodes.
And there could be multiple factors result in this, for example:

  • client choked by uploading tasks
  • node choked by other tasks, say relaying
  • outdated node info got returned
13 Likes
12

So these factors are causing a clients request for storage cost to fail?

1 Like
13

Can you explain this part a wee bit more. So our CLOSE group size is 5. So 5 nodes store the data close to them. If we are asking another 2 nodes that are not part of those who should store then why would they respond?

This seems like we deviate from CLOSE group here and ask folk not responsible of the data to quote.

I wonder is a majority of the CLOSE group would not be better, faster and simpler?

5 is a supermajority of 7 though, 4 would be a majority of 7 as 3 would be a major of 5. So this seems like we require more than a majority of nodes that are not in fact the nodes responsible for the data.

Can we explore the thought process here in more detail as we have some folk here who are motivated to see the reasons why we chose this. We may get some great help in discussing this one.

10 Likes
14

large file uploads have not worked consistently throughout all the beta testnets dating back almost 12 months.

10 Likes
15

Yea, it’s one I am heading towards trying to fix here. It should definitely work

9 Likes
16

yeah. there could be others as well, and we are currently working on pin the root

Anyone got paid will store the data, and then replicate it to others.
i.e. 5 closest shall 100% guaranteed to hold the copy eventually, meanwhile other closer around node might hold the copy as an extra backup

5 Likes
17

The problem here is not the majory, but just got too high dialing errors with an exploded network size.

6 Likes
18

I am not sure @qi_ma It seems people are telling us this has been consistent well before any network growth.

4 Likes
19

Is there a form of contention that emerges in a larger group that’s consulted to store? If so, maybe if the size of the consulted group was smaller it would be faster to generate a success/fail, and if fail then just start the retry code?

2 Likes
20

The entire client upload failure has even more other reasons cause the failure.
Some we have resolved.

Other factors also plays in, say if client using home connection, VPS or VM.
Say for with previous runs, our own client not experiencing much difficult in uploading large files, as it is running on VM

1 Like