Re: [compute-pressure] Add hysteresis to notify pressure observers algorithm (#176)

As I understood it from this Dev Trial feedback, too frequent flip-flopping (e.g. once a second) between pressure states was the issue and the preference would be to have the native implementation smooth this out i.e. provide _less frequent_ change notifications. These changes might now trigger a user-visible UI change once a second unless web developers do filtering in JS which would feel wrong and I agree would be less performant. It should be said this is an edge case where the system is pushed to its limits.

Wouldn't it be better for (most?) mainstream use cases to remove the high-frequency spikes by default (similar to impulse noise in audio signal) by applying a [median filter]( or some such on the input before it is fed to the notify pressure observers algorithm? I mean, insert `cpu = med(unfiltered_cpu)` as the first thing in the pseudocode where `med()` is a median filter of an appropriate window size. Should work, right?

Maybe I misunderstood what you meant by fine grained frequency, but let me ask:

Are we aware of important use cases that'd ask for high frequency notification updates? Maybe use cases where e.g. a single dropped frame means a fatal failure? If there are such use cases, maybe a high-frequency mode should be a configuration option? [Rate-limiting change notifications]( mitigation would not apply in such cases I believe, so we'd need to think about the privacy impact.

How the system behaved over say the last 10 minutes sounds like an interesting additional input to be fed to the algorithm.

GitHub Notification of comment by anssiko
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Monday, 30 January 2023 18:12:53 UTC