Created attachment 6554
Attempt at implementing "avglag"

Patch attached as per IRC ;)

attachment avglag.patch ignored as obsolete

Created attachment 6555
Improvement on last patch, as per roans comments on irc, and other minor tweaks noticed

A side point; i haven't added it to the maintenance patches where maxlag is used..

IMHO it shouldn't be needed there?

Attached:

+Patch as per Roan being seemingly suprised at it wasn't commited

Committed patch in r58646.

I'm not keen on this. The idea of maxlag is to perform writes as fast as the slowest slave will allow. If you keep doing writes until half the slaves are overloaded, the slowest slaves will be past 30s lag and completely depooled. That doesn't seem like an appropriate place to stop writing.

(In reply to comment #0)

Background:
AWB has been (or is still, nearing finishing) reimplemented to use the api for
editing. We've decided its wise to follow maxlag, more so for bot editing.

So we are using the recommended value of 5ms for bot editing, but this became a
pain for users doing semi-automated editing, as they would quite often fall
prey to maxlag restrictions preventing editing. We therefore changed this to
20ms for users. Although, this solves some problems for users, it doesn't solve
them completely.. And in some cases, editing can be done (and following
guidelines) using a multi tabbed browser and some fast clicking..

Do you mean 5 s? 5 ms is probably more than the latency between the master and some slaves on a bad day.

Yeah, i do. 5ms wouldn't be worth bothering about ;)

I guess it kinda depends on how this is used, and the nature of the client. Bots performing maintenance tasks can afford to wait for maxlag to drop, but tools like AWB that aim to provide relatively fast user interaction don't want to wait all day. In a scenario where one slave is badly lagged but the rest is not, avglag could help for these slightly higher priority edits. Of course it would need to be set to a low value like 2.

(In reply to comment #8)

I guess it kinda depends on how this is used, and the nature of the client.
Bots performing maintenance tasks can afford to wait for maxlag to drop, but
tools like AWB that aim to provide relatively fast user interaction don't want
to wait all day. In a scenario where one slave is badly lagged but the rest is
not, avglag could help for these slightly higher priority edits. Of course it
would need to be set to a low value like 2.

Well, if your approach is "keep writing regardless of whether you lag a slave out until it's depooled", then you might as well not bother checking for slave lag at all.

(In reply to comment #8)

I guess it kinda depends on how this is used, and the nature of the client.
Bots performing maintenance tasks can afford to wait for maxlag to drop, but
tools like AWB that aim to provide relatively fast user interaction don't want
to wait all day. In a scenario where one slave is badly lagged but the rest is
not, avglag could help for these slightly higher priority edits. Of course it
would need to be set to a low value like 2.

If they can't afford to wait, they should not specify a maxlag value. Then they'll get the same lag policy as ordinary editors.

Reverted.