Restricting runtime of a loop (Transaction took too long)

Question

I want to manage a worker that loops over events and should finish as many tasks as possible in one transaction. Nodes have a config for max-transaction-time = 30.

1. Is 30ms used on mainnet for all BP nodes?
2. Can I obtain the max time I have remaining according to my staked CPU in my contract?
3. The avg. runtime per iteration depends on the BP hardware. I can, however. provide safe estimates from local measurements. Is there a better way to live measure runtime? I assume there is none due to the deterministic nature of the TXs.

In the end I want to stop after n iterations with n = 0.9 x available CPU time / avg iteration time (0.9 is some safety margin).

Answer 1

1. By default, Nodes have a config for max-transaction-time = 30 but it doesn't necessary for all Bp to have exact same config for max transaction time so they can change at any time.

2. ::get_resource_limits() is privileged API, so it cannot be used by normal account (only privileged account can call it like eosio)
   You can get the limit of cpu, net or ram by the next: void get_resource_limits( capi_name account, int64_t* ram_bytes, int64_t* net_weight, int64_t* cpu_weight );
   But I don't think that you can get the info about the used amount in contract.

   Source :- Getting account CPU usage in smart contract is EOSIO's algorithm for estimating the CPU Max Limit.

3. Here is EOSIO's algorithm for estimating the CPU Max Limit.

   CPU의 Max Limit = (virtual_cpu_capacity_in_window x user_weight) / all_user_weight = virtual_cpu_limit x 2x24x60x60 x user_weight / all_user_weight = virtual_cpu_limit x 172800 x (rato of "how much I staked for CPU" / "how much every user staked for CPU")

   Source :- https://support.dexeos.io/hc/en-us/articles/360009054093-EOSIO-Why-CPU-bandwidth-varies-

Answer 2

There is no way to calculate this from within the action. The available CPU time is too complicated and depends on too many external variables. The actions are suposed to be determinsitic and repetable exactly as they ran in the first time so no external info which is dynamic is allowed in the dapp action code.

You should optimize and test and design your code to handle cases where the transaction fails and you need to retry it with a lower limit for the loop.