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. (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". 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
