Aarin:
Well it depends on the current value of max_block_cpu_usage (I believe the default value is 200 ms). Then it depends on whether the elastic multiplier is in play or not. If we assume the multiplier is at 1, then estimating an individual account's daily capacity is a matter of multiplying max_block_cpu_usage with the number of blocks in a day and then multiplying that with the fraction: their token's effectively staked for CPU divided by the total token's effectively staked for CPU.
If rentbw was adopted fully (meaning transitioned to having 99% of the influence over CPU), and elastic multiplier was set to 1 indefinitely (for example by dropping target_block_cpu_usage_pct to a very low value to guarantee that regardless of network activity, then the calculations become simpler. It would just be the max_block_cpu_usage multiplied by number of blocks in a day multiplied by the fraction of CPU the user is currently renting from rentbw.
If the block producers adjust their node configuration such that their (short-term average) processing time capacity per block (which you could only see when trx activity is high) is much less than the consensus max block time, then I think the queuing model for CPU throttling breaks down.
Right. The resource regeneration period is still 24 hours and that is baked into the EOSIO protocol and can only be change by a consensus upgrade (which this proposed system contract upgrade introducing rentbw is not). But the rentbw system does allow the 30 day period of the rentals to be adjusted (at 1 day granularity) down to 1 day if desired. That ratio of “double spend” goes down of course as rent_days gets larger. For example with 30 days, they only get to spend approximately 1/30 more resources than they pay for assuming the expiration is processed very quickly after the expiration time. This “double spend” issue is the reason why a minimum of 1 day delay is needed on undelegatebw.
I could be very wrong about this, but I think what this amounts to is a need for over-provisioning of total CPU (similar for NET) resources beyond the capacity that is determined by the max_block_cpu_usage parameter. The over-provisioning ratio r becomes a function of rent_days : r = 1 + 1/(rent_days) (assuming timely processing of expired loans). So with a rent_days of 30, the ratio r equals approximately 1.033, or a 3.3% overhead. But if rent_days drops to 1, then r is 2 which is a 100% overhead.
So what happens when that over-provisioning is not provided? I think this relates back to the question @michaelyeates asked in this channel. The system would be over-subscribed and I believe the fair queueing model that tries to provide low latencies for transactions (so they don't have to wait in a long queue) breaks down. Depending on how producer nodes are configured, that could already be the case. But it should in theory be possible to adjust the producer nodes and max_block_cpu_usage in combination with the chosen rent_days to account for the over-provisioning needs to ensure the system still operates smoothly.
The fraction overhead comes from the way this system interacts with the native EOSIO resource system. The way the native system works means that when an account uses all of its quota then waits 24 hours, it can then use all of its quota again (less black and white versions of that are also true, e.g. waiting 12 hours and using half of its quota all at once). That means twice its quota can be used in a period of 24 hours, even if that quota is pulled away from the user immediately after that 24 hour period. If that quota is then immediately re-lent to another user that can start the process of another 24 hour cycle (with potentially twice the quota use within that 24 hour cycle) all over again. So on average within a 24 hour window that quota is being utilized at a ratio of 2.
If you stretch out the period of this cycle from 24 hours to, for example, 72 hours, then the same process occurs except the user can use 4 times the quota over the 72 hour cycle. That means within a 24 hour window the average utilization of that quota is actually at a ratio of 4/3. So notice that if the regeneration period is t_regen and the cycle period is t_cycle = k * t_regen, then the ratio is r = (k + 1)/k = 1 + 1/k. Certainly more thought (and of course experimentation) is needed along this front.