Am 25.09.25 um 11:28 AM schrieb Fiona Ebner: > Am 25.09.25 um 10:52 AM schrieb Thomas Lamprecht: >> Am 25.09.25 um 10:27 schrieb Fiona Ebner: >>> Am 22.09.25 um 7:26 PM schrieb Thomas Lamprecht: >>>> Am 22.09.25 um 12:18 schrieb Fiona Ebner: >>>> Or maybe we could make this caching opt-in through some module flag >>>> that only pvestatd sets? But not really thought that through, so >>>> please take this with a grain of salt. >>>> >>>> btw. what about QMP being "stuck" for a prolonged time, should we >>>> stop using the previous value after a few times (or duration)? >>> >>> What other value could we use? Since the graph looks at the differences >>> of reported values, the only reasonable value we can use if we cannot >>> get a new one is the previous one. No matter how long it takes to get a >>> new one, or there will be that completely wrong spike again. Or is there >>> a N/A kind of value that we could use, where RRD/graph would be smart >>> enough to know "I cannot calculate a difference now, will have to wait >>> for multiple good values"? Then I'd go for that instead of the current >>> approach. >> >> That should never be the problem of the metric collecting entity, but of >> the one interpreting or displaying the data, as else this is creating a >> false impression of reality. >> >> So the more I think of this, the more I'm sure that we won't do anybody >> a favor in the mid/long term here with "faking it" in the backend. > > Very good point! I'll look into what happens when reporting an undef > value, because right now the interpreting entity cannot distinguish > between "0 because of no data" and "0 yes I really mean this is the > actual value".
Returning undef already works as intended :) Superseded by: https://lore.proxmox.com/pve-devel/[email protected]/T/ _______________________________________________ pve-devel mailing list [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
