From: Aaron Wood <woody77@gmail.com>
To: Christoph Paasch <cpaasch@apple.com>
Cc: Dave Taht <dave.taht@gmail.com>, Rpm <rpm@lists.bufferbloat.net>
Subject: Re: [Rpm] apm metric - annoyance per minute
Date: Tue, 11 Jan 2022 09:50:59 -0800 [thread overview]
Message-ID: <CALQXh-OzB7wzD2imA=_gXOKmOXRfrTEopVfbNaUwa441DZDAJw@mail.gmail.com> (raw)
In-Reply-To: <BBC12E1D-0661-4112-9F67-9E60BBF587C2@apple.com>
[-- Attachment #1: Type: text/plain, Size: 2569 bytes --]
I read it as the number of events per minute (not say the number of frames
longer than 20ms, but the number of events that took at least 20ms longer
than the base RTT, which I think is what Dave meant by "latency excursion").
E.g. if you're doing DNS queries, and they usually return in 50ms, and 3 of
them take 83, 94, and 106 ms respectively, in a given minute, than that
would be an APM of 3? ( or maybe an APM rate of 30% if you were doing
10/minute)
I've found the tricky thing for metrics is sorting out the event-count vs.
events-rate differences. A lot of tests that are isochronous give a
constant event-rate to base on (e.g. ping's default of once per second),
but other tests, like the UDP and ICMP pings in flent (at least in the
past), have a rate that's based on the RTT, so as RTT goes up, the rate of
events goes down, which means that it oversamples the "fast" events, and
undersamples "slow" events.
Further, retries for failed events muddy the waters, as the events aren't
independent measurements. If a momentary drop in connectivity causes
retries to happen, and each failed retry is counted, is that N failures?
Or just 1 failure? I've split those out as separate metrics in some
systems I've built, so that I can tease them apart. I've also done things
like the distribution (histogram) of "attempts before success" or "attempts
before operation failed". Usually those are dominated by "1 attempt before
success", and "N attempts before operation failed" where N is the number of
total attempts before just giving up.
On Tue, Jan 11, 2022 at 9:34 AM Christoph Paasch via Rpm <
rpm@lists.bufferbloat.net> wrote:
> Hi Dave!
>
> > On Jan 9, 2022, at 6:57 PM, Dave Taht via Rpm <rpm@lists.bufferbloat.net>
> wrote:
> >
> > or gpm - glitch per minute
> >
> > defined as a latency excursion of more than 20ms.
>
> I kinda find that interesting :) Can you give an example? Would it count
> the number of times we miss a "20ms-deadline"? So, if the RTT is 100ms, GPM
> would be 5 ?
>
>
> Christoph
>
> >
> > ?
> >
> >
> > --
> > I tried to build a better future, a few times:
> > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> >
> > Dave Täht CEO, TekLibre, LLC
> > _______________________________________________
> > Rpm mailing list
> > Rpm@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
>
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm
>
[-- Attachment #2: Type: text/html, Size: 3660 bytes --]
next prev parent reply other threads:[~2022-01-11 17:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 2:57 Dave Taht
2022-01-11 17:34 ` Christoph Paasch
2022-01-11 17:50 ` Aaron Wood [this message]
2022-01-11 19:44 ` Dave Taht
2022-01-11 22:03 ` Dave Taht
2022-01-11 21:22 ` Simon Leinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/rpm.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALQXh-OzB7wzD2imA=_gXOKmOXRfrTEopVfbNaUwa441DZDAJw@mail.gmail.com' \
--to=woody77@gmail.com \
--cc=cpaasch@apple.com \
--cc=dave.taht@gmail.com \
--cc=rpm@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox