On 9 Sep 2014, at 11:12 pm, Lars Ellenberg <lars.ellenb...@linbit.com> wrote:
> On Tue, Sep 09, 2014 at 05:10:33PM +1000, Andrew Beekhof wrote: >> >> On 9 Sep 2014, at 4:11 pm, Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> >> wrote: >> >>>>>> Andrew Beekhof <and...@beekhof.net> schrieb am 09.09.2014 um 00:25 in >>>>>> Nachricht >>> <c19365b9-b626-471e-a92a-001950d01...@beekhof.net>: >>> >>>> On 8 Sep 2014, at 5:19 pm, Ulrich Windl >>>> <ulrich.wi...@rz.uni-regensburg.de> >>>> 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 > Linux-HA@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
