Jump to content

Are all these airdrops clogging up the XRPL?


Seoulite
 Share

Recommended Posts

What is scary is that we are VERY FAR from the 1500 TPS advertised, on which public test data were never released.
There were at maximum 5M transactions in a day which is an average of 60 TPS. Maybe with some peaks, but still far from the 1500 TPS. It's time to have real-life tests on the network capabilities and have some public reports.

The chickens come home to roost.

 

Link to comment
Share on other sites

5 minutes ago, tulo said:

What is scary is that we are VERY FAR from the 1500 TPS advertised, on which public test data were never released.
There were at maximum 5M transactions in a day which is an average of 60 TPS. Maybe with some peaks, but still far from the 1500 TPS. It's time to have real-life tests on the network capabilities and have some public reports.

The chickens come home to roost.

 

To be fair in the thread they address that this is not a problem with transactions but a problem with too many users using too few nodes at the same time. I think Wietse said it is an area that wasn't stress-tested, but is now being improved. One issue was too many projects were just using the two Ripple public nodes. Overreliance. Point of failure. Centralisation. etc. 

Link to comment
Share on other sites

3 minutes ago, Seoulite said:

To be fair in the thread they address that this is not a problem with transactions but a problem with too many users using too few nodes at the same time. I think Wietse said it is an area that wasn't stress-tested, but is now being improved. One issue was too many projects were just using the two Ripple public nodes. Overreliance. Point of failure. Centralisation. etc. 

I don't think it depends on the nodes to access the network. The effect is on all the XRPL. Higher fees, higher closing time, ...
Creating trust lines is a transaction.

If a single node cannot handle all the 1500 TPS then how can the network handle it? All the transactions are relayed to peers, so also if transactions are sent via different entry nodes, most of the validators will receive anyway all the transactions.

Link to comment
Share on other sites

11 minutes ago, tulo said:

I'm also curious to see the memory requirement of rippled now with all those new accounts and trustlines.

This is absolutely not related to TPS or the XRPL being unable to deal with trustlines. It's about the API servers. I'll explain two unrelated issues that happened on consecutive dates - 

Issue #1 - API servers. Yesterday.

The TPS continues to be barely at 1% of 1500. However, the free non-production S1 and S2 full history nodes that Ripple operates were being used by Trustline issuers and several apps that then track those trustlines. These API servers were not tuned for these API usage patterns. Again, to be clear, these full history nodes DO NOT perform validations. And these are non-production servers. See https://xrpl.org/public-servers.html

This happened yesterday. XRPL can deal with spam. The non-production API servers run by Ripple were not hardened to the usage patterns that caused the issue, and XRPL Labs basically figured out that these usage patterns came because of the extraordinary number of trustline-related activities. 

The actual transactions never reached the ledger. They were stuck at the API layer.

Issue #2 - XRPL. Today.

This happened today. An existing bug in the fee escalation loop was exposed. Essentially the ledger expected higher fees to be charged per transaction even though it was not under any kind of serious load. This caused genuine transactions with the usual 12 drops fee to be backed up and once the back up queue was full, they were rejected. Even if the ledger had plenty of capacity.

To solve this, validators came together and modified a configuration to increase the threshold at which the ledger thinks it should be charging fees. You can find the medium to long term planned fixes and additional explanation here - https://status.xrpl-labs.com

Issue #2 is the more serious one of the two because this needs to be patched very quickly. Issue #1 is only an inconvenience.

 

@Seoulite, hope this helps.

Edited by Ripley
Link to comment
Share on other sites

11 minutes ago, Ripley said:

Issue #2 - XRPL. Today.

This happened today. An existing bug in the fee escalation loop was exposed.

It's years we fight with this fee escalation. It was already fixed twice. And all of the sudden, when TPS increases a little there are problems, so yeah it's related to TPS. It's related to rippled core code. 
Because 1500 TPS were never tested in real environment (many validators in different geographical areas, delay in communications, lots of peers, increasing resources usage for trust lines and new accounts, ...) IMO.

Edited by tulo
Link to comment
Share on other sites

3 minutes ago, tulo said:

It's years we fight with this fee escalation. It was already fixed twice. And all of the sudden, when TPS increases a little there are problems, so yeah it's related to TPS. It's related to rippled code code. 
Because 1500 TPS were never tested in real environment (many validators in different geographical areas, delay in communications, lots of peers, increasing resources usage for trust lines and new accounts, ...) IMO.

You could be right about issue #2, of course. I would love to see the root cause analysis on this. It's just growing pains. Nothing concerning so far.

Link to comment
Share on other sites

Just now, RipMcGillicuddy said:

Folks...I think this is what ethereum groups must sound like...so I think we're on a path towards growth. 

disclaimer: this kinda stuff better get fixed

these are typical tech debt issues. product managers hate fixing tech debt. they're always on about new features. now that there's a production issue, I think they're going to prioritize it.

Link to comment
Share on other sites

7 minutes ago, Ripley said:

these are typical tech debt issues. product managers hate fixing tech debt. they're always on about new features. now that there's a production issue, I think they're going to prioritize it.

And this is why there will never be a magic "flip the switch" event that massively onlines multiple enterprises blasting XRPL traffic. Scaling up live systems is always performed in stages, with assessments, discoveries, and remediation. 

Having growing pains is a good thing.
I'd be worried if there was no such signs of continued usage and adoption :) 

Link to comment
Share on other sites

 

1 minute ago, JASCoder said:

Scaling up live systems is always performed in stages, with assessments, discoveries, and remediation. 

This is not done in stages. It wasn't done at all. It happened because the network requested it. It would have been much better if someone with lots of XRP (:rolleyes:) tested this in a controlled environment, not waiting for everything to fail badly and look bad in front of the world.

Link to comment
Share on other sites

6 minutes ago, tulo said:

 

This is not done in stages. It wasn't done at all. It happened because the network requested it. It would have been much better if someone with lots of XRP (:rolleyes:) tested this in a controlled environment, not waiting for everything to fail badly and look bad in front of the world.

isn't this just part of the decentralization of it all though...the XRPL was born and needs to find its legs without Ripple coddling it the whole way?

Link to comment
Share on other sites

9 minutes ago, tulo said:

 

This is not done in stages. It wasn't done at all. It happened because the network requested it. It would have been much better if someone with lots of XRP (:rolleyes:) tested this in a controlled environment, not waiting for everything to fail badly and look bad in front of the world.

it's not possible to replicate real world challenges in a test environment. if it was, we wouldn't have AWS, Google, Facebook, etc. go down. It's hard enough with centralized platforms. It's much much harder in public ledgers where you cannot control hardware and network quality that someone else runs their nodes on.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share



×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.