Eos: ADD stress testing make our transactions all failed ?！！

[guaiguaihw]

ADD's first stress testing start at 2018-07-10，when they started push transactions，our account's unused cpu is down to 0. we select the data by command: cleos get account vrjjosgkosnb
After the test ended, cpu recovered.

Our query node error, when we tried to send transactions. The error is below. It is impossible that our cpu were used up.

2873899ms thread-0   net_plugin.cpp:2547           operator()           ] accept txn threw  3080004 tx_cpu_usage_exceeded: transaction exceeded the current CPU usage limit imposed on the transaction
billed CPU time (5874 us) is greater than the maximum billable CPU time for the transaction (5422 us)
    {"billed":5874,"billable":5422}
    thread-0  transaction_context.cpp:350 validate_cpu_usage_to_bill
2873911ms thread-0   net_plugin.cpp:2547           operator()           ] accept txn threw  3080004 tx_cpu_usage_exceeded: transaction exceeded the current CPU usage limit imposed on the transaction
billed CPU time (5577 us) is greater than the maximum billable CPU time for the transaction (5422 us)
    {"billed":5577,"billable":5422}
    thread-0  transaction_context.cpp:350 validate_cpu_usage_to_bill

When the last gap happend, we searched the explorer, found that all transactions at that time were packed by eos canada: https://explorer.eoseco.com/blocks/5169389

[guaiguaihw]

Today, when ADD started their stress testing again, same error occured. our account's cpu is down to 0.

And our query node error again:

I think there may be something wrong with BP's config.in, or unknown chain bug.
@bytemaster

[guaiguaihw]

@spartucus why close my issue? Do you have a right way to solve this problem? ? ?

[spartucus]

Nope, I just close mine, still waiting for b1's answer here.

[wanderingbort]

We will look into this further, but the curves look very much like our congestion controls taking affect.

When the chain is mostly idle, accounts can use up to 1000x more than what their stake would indicate. As the usage of the chain peaks, we reduce this multiplier down to a strict 1:1 ratio of stake to bytes or microseconds. It is possible that the ADD airdrop had enough transactions to push the chain into this 1:1 congested state and the required stake to operate was temporarily larger than it had been. Once the congestion abated, your resources were restored to the levels expected correct?

[guaiguaihw]

@wanderingbort
They just stake over 1w EOS to CPU, that makes all of our accounts can‘t send transactions any more.
I doubt it's reasonable for this result. As I know, many people are affected by it, but they don't know the reason. I think it should be improved by block.one.

[spartucus]

Hi @wanderingbort , does this mean big whale can make network down by making chain peaks? I agree with guaiguaihw, i don't think it is reasonable either.