Re: Antw: Re: Q: dampening explained?

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

> On Tue, Sep 09, 2014 at 05:10:33PM +1000, Andrew Beekhof wrote:
>> 
>> On 9 Sep 2014, at 4:11 pm, Ulrich Windl <[email protected]> wrote:
>> 
>>>>>> Andrew Beekhof <[email protected]> schrieb am 09.09.2014 um 00:25 in Nachricht
>>> <[email protected]>:
>>> 
>>>> On 8 Sep 2014, at 5:19 pm, Ulrich Windl <[email protected]> 
>>>> wrote:
>>>> 
>>>>> Hi!
>>>>> 
>>>>> I remember having asked this before, but I'l still missing a good 
>>>> explanation:
>>>>> 
>>>>> What are the precise semantics of "dampening" (attrd_updater -d)?
>>>>> 
>>>>> The manual page just says:
>>>>>     -d, --delay=value
>>>>>            The time to wait (dampening) in seconds further changes occur
>>>>> 
>>>>> Who is waiting?
>>>> 
>>>> attrd before it updates the cib
>>> 
>>> So the RA sees an extra delay of -d seconds?
>> 
>> No. attrd does the waiting, not attrd_updater
>> 
>>> 
>>>> 
>>>>> What changes?
>>>> 
>>>> other processes or nodes calling attrd_updater
>>> 
>>> So it means that if you call "attr_updater -d X" and then "attr_updater -d Y" the second update will be delayed until at least X seconds since the first update passed?
>> 
>> No.  It means wait X seconds for another update (locally or on another node) before writing the value to the CIB.
>> If another update does arrive, reset the clock and wait another X seconds.  Repeat.
>> 
>> Usually only the -d from the first call to attrd_updater has any affect.
>> Subsequent calls re-use the -d value from the first.
>> 
>>> If a third "attr_updater -d Z" is called, will the system ensure that at least X + Y seconds passed since the first update before appying the third update?
>> 
>> No.
> 
> Some of this has been discussed before:
> http://www.gossamer-threads.com/lists/linuxha/dev/75740?do=post_view_threaded#75740
> 
> 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 :)

> 
> (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?

> 
> 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)