Re: Antw: Re: Q: dampening explained?

Andrew Beekhof <[email protected]> Wed, 10 Sep 2014 19:12:16 +1000
Newsgroups	gmane.linux.highavailability.user
Message-ID	<[email protected]>
On 10 Sep 2014, at 6:43 pm, Lars Ellenberg <[email protected]> wrote:

> On Wed, Sep 10, 2014 at 03:00:15PM +1000, Andrew Beekhof wrote:
>>>>>>> What are the precise semantics of "dampening" (attrd_updater -d)?
> 
>>> Basic idea of "attr_updater -d delay" is in fact
>>> "wait for the dust to settle",
>>> especially for attribute based constraints,
>>> as used with the ping RA.
>>> 
>>> Current behaviour (afai understand it):
>>> 
>>> If a new update comes in while a previous update is still "pending",
>>> the timer of the new update is *ignored*,
>>> the new value is queued instead, and
>>> the original timer is restarted.
>> 
>> I think thats what I wrote but longer :)
> 
> Absolutely :)
> 
>>> (UNLESS the "new" value is the same as the currently pending value.
>>> Otherwise values would never reach the cib if the update interval
>>> is shorter than the dampening interval.)
>>> 
>>> Value is put into the cib only if the original timer actually expires,
>>> or attrd "flushes out" all current values for some other reason.
>>> 
>>> -----
>>> 
>>> Problem:
>>> for "flapping" or otherwise continually changing values,
>>> new values won't make it into the cib for "a long time".
>> 
>> Do we have many attributes like that?
> 
> I've seen it once for ping attributes with a dieing switch.
> I guess that qualifies as "Not around here.".

That would surely converge on 0 though right?

> 
>>> Workaround:
>>> use a dampening interval shorter than the update interval.
>>> 
>>> Problem with that workaround: you may still hit the same undesired
>>> situations you could reach with immediately updating the values, you
>>> did not wait for "the dust to settle".
>>> 
>>> 
>>> Proposal:
>>> 
>>> add a "update deadline" along with the dampening, which would normally
>>> be sufficiently larger, and count from the original update (this timer
>>> would not be restarted).
>>> 
>>> Optionally feed all updates into an aggregate function.
>>> Default aggregate function may be "latest value".
>>> 
>>> Once the "update deadline" is reached,
>>> (submitted values still changing; flapping? ...)
>>> write out the current "aggregate" value anyways.
> 
> 
> -- 
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
> 
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
> _______________________________________________
> Linux-HA mailing list
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
signature.asc (application/pgp-signature, 841 B)