Our usecase is to add link utilization in any interface related items. Since most interface snmp implementations only have bits sent and link capacity data, we have to use calculated item to calculate its utilization with 100*last(speed)/last(capacity) formula.

But as mentioned in the issue, this will become a problem when the proxy has some connectivity issues.

If you have a master item with JSON data about the interface and dependent items that extract specific data from that JSON (one for speed, one for capacity), then you could have another dependent item for utilization and use JavaScript preprocessing to extract speed, capacity and perform the calculation.

That, of course, wouldn't solve the issue with calculated items, but could help you with your usecase.

Calculated items cannot be executed by a proxy because, generally speaking, the calculation may include items from hosts which are not monitored by that proxy.

If you have a master item with JSON data about the interface and dependent items that extract specific data from that JSON (one for speed, one for capacity)

Unfortunately I don't. My items are only snmp agent items. But maybe I can..? I'll try using snmp discovery, but extract the values. Not sure if it's feasible or not.

Calculated items cannot be executed by a proxy because, generally speaking, the calculation may include items from hosts which are not monitored by that proxy.

Yes, I also realized this. What I'm asking is if and only if the calculated item only refers items from the same host or monitored by the same proxy, then calculation should happen in proxy. Since the values are available, there's no reason not to do it in proxy.

If the calculated item is using items monitored by different proxy, it should fallback to the usual behaviour, calculate on zabbix server.

But maybe I can..? I'll try using snmp discovery, but extract the values. Not sure if it's feasible or not.

I don't think we can do this. A bulk snmp requests is possible with "walk[]" oid, and put both capacity and bit sent OID. But unfortunately, the "change per second" preprocessing is only available for a single value. And javascript preprocessing cannot access the previous value, only the current one. So the logic of 100*change_per_second(bit sent)/speed still cannot be done.

The current behavior is understandable from a technical standpoint, but its a real eyesore as other items get populated so seamlessly after downtime. 

Instead of solving this by enhancing the proxies much, the same result could achieved by having calculated items being processed retroactively after downtime. This route is probably also a can of worms, but it's a different can of worms Also, having the math for calculated items being possible retroactively would probably be a popular feature.