Re: [Linux-HA] Antw: Re: Q: dampening explained?
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.. 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
Re: [Linux-HA] Antw: Re: Q: dampening explained?
On 10 Sep 2014, at 6:43 pm, Lars Ellenberg lars.ellenb...@linbit.com 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 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
Re: [Linux-HA] Antw: Re: Q: dampening explained?
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. If the delay is not over, does the next update wait (as I guessed), or is the next update simply ignored? Please explain! As you see, there are too many questions that are still unanswered. (pacemaker-1.1.10-0.15.25 of SLES11 SP3) Regards, Ulrich ___ 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
Re: [Linux-HA] Antw: Re: Q: dampening explained?
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
Re: [Linux-HA] Antw: Re: Q: dampening explained?
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
