Yea feeling rays of sunshine peaking through the clouds as well 
6 Likes
it looks quite fast (good times), do I understand this correctly?
1 Like
yes speed increased by a factor of 10 when the node whales left the room
10 Likes
I wonder how much time was spent by Autonomi and independent devs due to issues caused by emissions. It’s a question that wasn’t on our list of misgivings until now.
5 Likes
months, but let’s make no mistakes, emissions did expose vulnerabilities that would’ve been there in a less prominent way without emission, but sooner or later would’ve caused performance issues and or other major vulnerabilities.
6 Likes
But also one cannot know how many of those would have been fixed anyhow with further development. Doing things to improve other issues which also had the same root cause and gets fixed. Quite a few.
Also many of the issues were only due to no data on the network. Not a normal state of running. So no not all issues were bugs and some fixes were work around to cater for a special case that will not exist once the quality network which was delayed due to the work around being done.
I am not trying to say it was months or anything lost, but some time would have been.
Lesson learnt and pride of massive network readjusted
10 Likes
The internal ip addresses of the non earning machines changed (I’m guessing one of the kids turned the router power socket on and off) so port forwarding must have failed 
5 Likes
Now if only we can get those payment amounts to go up a little
@anon75844067 you got this, I believe in you.
| Period | Deposits | Total ANT |
|---|---|---|
| Last 24 hours | 1,925 | 0.01738539 |
2 Likes
8 Likes
Our metrics only show us about 70% upgraded as of now.
The morning after release we had shown 37%, so I thought it was going to happen much quicker this time. However, the rate has been slower since then, so I think someone who has a relatively large fleet done a manual upgrade shortly after the release came out. If you are reading this: please just let your nodes upgrade themselves . It’s better for the network for it to be slow and gradual.
Perhaps though it may not have to be quite as slow as we’re going now. There could be room for some tweaks there.
8 Likes
was a quick guesstimate looking at my nodes.
so we are nearly there i have 100 nodes so we are at 87% upgraded by my count
6 Likes
Just FYI, for better or worse, if you use koinly or any crypto tax software, you will end up paying more than 1c per transaction to those services, leading to way more costs than the value of your 1925 ANT deposits at these rates.
For me, I can’t justify 1000s or 10000s off transaction in accounting software costs if value of each is under 1c, which is minimum break even at koinly and thats with significant discounts being applied.
Anyhow, its not always about the cost vs revenue, so if you are dedicated to running nodes, then you are dedicated to running nodes 
.
1 Like
Firstly depends on how you are running them.
If port forwarding then using the port number you can query the node itself.
EG
in the browser go to this link on the machine/container
127.0.0.1:[port-number]/metadata
Replace the [port-number] with actual port number. [EDIT: the metrics port not listening port - brain fart there]
if port forward port mertics port is 50000 then 127.0.0.1:50000/metadata will download a file and look for antnode_version (or similar) [EDIT: the metrics port not listening port - brain fart there]
3 Likes
Downloading 20 GB of data on a daily basis myself at amazing speed: 16 minutes 40 seconds.
I do think there is still room for improvements, because as far as I can see the slowest node is slowing everything down. For example, I’m downloading in 256 chunk batches, but as of right now, it wont start download the next 256 chunks before the last chunk of the first 256 batch has been downloaded. This makes every batch wait on the slowest device. I think we could improve this to have X amount (in this cased 256) of chunks downloaded simultaneously, if 1 chunk is successfully fetched, chunk 257 should start without waiting on the other 255.
This is the same for uploads right now, when 1 chunk fails in an entire batch, it will first retry the failed chunk over and over before proceeding to the next batch. I believe that with uploading, sometimes it will continue with the other chunks while retrying the failed one, but as far as I can tell that’s only the case when there are chunks remaining for the current file, if it’s the last chunk in the file it will retry before continuing with the other chunks for the next file.
It’s really great to see the network perform, knowing that it can be optimized even further.
6 Likes
The download should be parallel, and also requesting the data from the 5 nodes holding a chunk with the fastest giving it to you.
So slowest node is not quite right, and I’d rather suggest that there is retrying occurring rather than one slow node holding things up. For starters to say one slow node is holding things up is to say ALL 5 nodes holding a chunk are the slowest. This is what suggests other reasons with the highest one to look at is retrying due to errors, like your end/ISP/internet typical error rate.
I remember rewards were planned to optimise towards faster nodes. I think we now just have shunning for ‘bad’ nodes instead.
I suspect it would take deeper analysis to pinpoint to exact cause of the slow down, but as a node runner, it is hard to know if you are helping or harming the network sometimes.
For example, I have asynchronous speeds for upload and download. 1gb down never saturates with the number of nodes I run. However, I only have 100mb up, which can saturate more easily (I set bandwidth limits to prevent it impacting network performance for other tasks).
Maybe it is better for the network if I just reduce the node count. However, how slow is a slow response? Or how fast is fast enough, etc? Is it better to contribute slower disk space than none at all?
These aren’t questions I expect you to answer, but rather open questions that the team may need to understand and encourage/discourage behaviours that aren’t ideal. Shunning may be too big a stick in many cases.
3 Likes