Eos: Error 3080006: transaction took too long

[spartucus]

I know it's a closed issue already for many times.
But I think it should be taken seriously.

First time it says took too long.

niubob@niubob-VirtualBox:~/work/contract$ cleos push action eosdacrandom setsize '[2]' -p eosdacrandom
Error 3080006: transaction took too long
Error Details:
deadline exceeded

Second time it took 4213 us.

niubob@niubob-VirtualBox:~/work/contract$ cleos push action eosdacrandom setsize '[2]' -p eosdacrandom
executed transaction: 3de3bc3c223f00d61aa7e6cff0c03a882a6c9101ba42df8b515299cc480537c8  104 bytes  4213 us
#  eosdacrandom <= eosdacrandom::setsize        {"size":2}
>> eosdacrandom construct
warning: transaction executed locally, but may not be confirmed by the network yet

And third time it took 449 us.

niubob@niubob-VirtualBox:~/work/contract$ cleos push action eosdacrandom setsize '[2]' -p eosdacrandom
executed transaction: 224e8c36a239c831f48a96a6e99bc0e57746980ec0febbe4809c22c0b24ba23c  104 bytes  449 us
#  eosdacrandom <= eosdacrandom::setsize        {"size":2}
>> eosdacrandom construct
warning: transaction executed locally, but may not be confirmed by the network yet

Fourth and fifth time, it took nearly 370 us.

niubob@niubob-VirtualBox:~/work/contract$ cleos push action eosdacrandom setsize '[2]' -p eosdacrandom
executed transaction: 96d9ddded5ceb80784424f1e293bd06c91e291fd220d893c593058fa05555896  104 bytes  345 us
#  eosdacrandom <= eosdacrandom::setsize        {"size":2}
>> eosdacrandom construct
warning: transaction executed locally, but may not be confirmed by the network yet
niubob@niubob-VirtualBox:~/work/contract$ cleos push action eosdacrandom setsize '[2]' -p eosdacrandom
executed transaction: 282c8d352b6ed298a94231a66eb9b5cd25fac84ce0adda6b4b194f47e1d9898c  104 bytes  376 us
#  eosdacrandom <= eosdacrandom::setsize        {"size":2}
>> eosdacrandom construct
warning: transaction executed locally, but may not be confirmed by the network yet

So the time it took is: deadline exceeded > 4213 > 449 > 370 > 370 ...
Why it took so long at beginning or even deadline exceeded?
The contract example is here.

Correct me if i'm wrong or there are something i didn't know.

[isha-padalia]

see this, #3150, #2977

[spartucus]

yes, i saw these before, but i don't know why it took so much time on first time, and less later

[taokayan]

We haven't received any update for this. CPU billing is subjective and can vary due to cache miss, cpu frequency throttling, etc. If you still have the problem and wish to discuss further, please post it in https://eosio.stackexchange.com.

[ChenLi0830]

I've seen this Error multiple times and I don't think it's appropriate to close all the issues related to it without a solution. It should be kept open before it's resolved.

[jgiszczak]

@ChenLi0830 There is nothing to resolve. CPU usage is accounted using wall clock time and can vary considerably as outlined by taokayan. If you wish to create actions which execute reliably without cache warmup, use less CPU time. There is no other option.

Note that this is industry standard. If you wish to use an IBM mainframe, you will be billed for wall clock CPU time. If you wish to use Google Cloud Platform, you will be billed for wall clock CPU time. If you wish to use Amazon Web Services, you will be billed for wall clock CPU time.

Unlike the aforementioned services, EOS.IO accounts for CPU time in microsecond increments and doesn't bill you for CPU time at all. You only stake for the CPU time you wish to use, and can recover your entire stake if your CPU usage drops to zero. GCP on the other hand has a 1 minute minimum, and bills in 1 second increments thereafter, and you pay for each and every second thereafter, with no recovery.

[ChenLi0830]

@jgiszczak I've been testing on Jungle Testnet and sometimes even creating an account would trigger this 3080006 error. I realize that this error is essentially related to the actual BP node's performance, but is there a recommended way to handle this?

Assume we have already minimized the CPU uage, in case of this error, should we simply resend the request?

[jgiszczak]

Yes, just retry. Jungle Testnet has producer nodes which can charitably be called 'underprovisioned'. Just resubmit after 6 seconds to try on another node. Once another node has accepted your transaction, the underprovisioned nodes will also accept it, since the subjective limits are suspended.

[zhumingu]

Me too. It was happened too frequent.

[StarryJapanNight]

This is also a problem for my dapp. Very inconvenient and confusing for users.