You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What would be a good add is to instead of testing the uptime - which in my opinion is bad because it puts negative pressure to have high performant peering and instead go for amount of peers, and also to create choking points...
Would be to test the CPU of the peering network. Meaning connect 2 processes, push a transaction through #1 and see if it appears in the queue on #2
The transaction to push can start with the eos mechanics test, and then have other tests on the same contract which consume higher and higher CPU. This way the peering network can be tested. And instead of relying on always having open peers - it would actually provide value.
Both of them can be connected all the time, will only consume 2 peers, meaning there should be ample opportunity to test if given a couple of days for each node.
CPU speed on API nodes really matters.
some test results with delegatebw
2.7GHz AWS (r4.x2large) node - ~3100us
4.4GHz bare metal node - ~1900us
The text was updated successfully, but these errors were encountered: