DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Stephen Hemminger" <stephen@networkplumber.org>
Cc: <dev@dpdk.org>, "Tyler Retzlaff" <roretzla@linux.microsoft.com>,
	"Reshma Pattan" <reshma.pattan@intel.com>
Subject: RE: [PATCH v4 3/6] latencystats: do not use floating point
Date: Sat, 20 Apr 2024 09:31:10 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F3CF@smartserver.smartshare.dk> (raw)
In-Reply-To: <20240419154516.6c934212@hermes.local>

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Saturday, 20 April 2024 00.45
> 
> On Fri, 19 Apr 2024 20:49:56 +0200
> Morten Brørup <mb@smartsharesystems.com> wrote:
> 
> > > -		/*
> > > -		 * The average latency is measured using exponential moving
> > > -		 * average, i.e. using EWMA
> > > -		 * https://en.wikipedia.org/wiki/Moving_average
> > > -		 */
> > > -		glob_stats->avg_latency +=
> > > -			alpha * (latency - glob_stats->avg_latency);
> > > +			glob_stats->avg_latency = latency;
> > > +			glob_stats->jitter = latency / 2;
> >
> > Setting jitter at first sample as latency / 2 is wrong.
> > Jitter should remain zero at first sample.
> 
> Chose that because it is what the TCP RFC does.

I suppose it depends on what the measured jitter is being used for.

<rant>
1/2 is very far from the predominant Jitter/RTT relationship I usually see on internet connections.
Jitter is mostly in the ~2 ms order of magnitude, while RTT may be anything between 10 and 600 ms.
Although some links may experience much higher jitter under load, the RTT usually also increases to 100's of milliseconds under these conditions.
Some people are on a crusade to combat this "latency under load" bufferbloat phenomenon. The path towards achieving this begins with measuring and educating.
</rant>

Your RFC reference is a very strong argument.
If the measured jitter is used as a measure of uncertainty in the measured RTT, it makes sense starting high.
I'll accept it.

Acked-by: Morten Brørup <mb@smartsharesystems.com>

> RFC 6298
> 
>    (2.2) When the first RTT measurement R is made, the host MUST set
> 
>             SRTT <- R
>             RTTVAR <- R/2
>             RTO <- SRTT + max (G, K*RTTVAR)
> 
> The problem is that the smoothing constant in this code is quite small.
> Also, the TCP RFC has, not sure if matters.
> 
>    (2.3) When a subsequent RTT measurement R' is made, a host MUST set
> 
>             RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'|
>             SRTT <- (1 - alpha) * SRTT + alpha * R'
> 
>          The value of SRTT used in the update to RTTVAR is its value
>          before updating SRTT itself using the second assignment.  That
>          is, updating RTTVAR and SRTT MUST be computed in the above
>          order.
> 
>          The above SHOULD be computed using alpha=1/8 and beta=1/4 (as
>          suggested in [JK88]).
> 
>          After the computation, a host MUST update
>          RTO <- SRTT + max (G, K*RTTVAR)

  reply	other threads:[~2024-04-20  7:31 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-08 19:50 [RFC] latencystats: performance overhaul Stephen Hemminger
2024-04-08 21:26 ` [PATCH v2] " Stephen Hemminger
2024-04-19 17:28 ` [PATCH v4 0/6] latencystats: cleanup Stephen Hemminger
2024-04-19 17:28   ` [PATCH v4 1/6] latencystats: replace use of VLA Stephen Hemminger
2024-04-19 17:28   ` [PATCH v4 2/6] latencystats: handle fractional cycles per ns Stephen Hemminger
2024-04-19 17:28   ` [PATCH v4 3/6] latencystats: do not use floating point Stephen Hemminger
2024-04-19 18:49     ` Morten Brørup
2024-04-19 22:45       ` Stephen Hemminger
2024-04-20  7:31         ` Morten Brørup [this message]
2024-04-19 17:28   ` [PATCH v4 4/6] latencystats: fix log messages Stephen Hemminger
2024-04-19 17:28   ` [PATCH v4 5/6] latencystats: update include files Stephen Hemminger
2024-04-19 17:28   ` [PATCH v4 6/6] latencystats: fix for pedantic warnings Stephen Hemminger
2024-04-22 15:21 ` [PATCH v5 0/9] latencystats: improve algorithms and tests Stephen Hemminger
2024-04-22 15:21   ` [PATCH v5 1/9] latencystats: replace use of VLA Stephen Hemminger
2024-04-22 15:21   ` [PATCH v5 2/9] latencystats: handle fractional cycles per ns Stephen Hemminger
2024-04-22 15:21   ` [PATCH v5 3/9] latencystats: do not use floating point Stephen Hemminger
2024-04-22 15:21   ` [PATCH v5 4/9] latencystats: fix log messages Stephen Hemminger
2024-04-22 15:21   ` [PATCH v5 5/9] latencystats: update include files Stephen Hemminger
2024-04-22 15:21   ` [PATCH v5 6/9] latencystats: enforce that unused callback function is NULL Stephen Hemminger
2024-04-22 15:21   ` [PATCH v5 7/9] latencystats: add metric for number of samples Stephen Hemminger
2024-04-22 15:21   ` [PATCH v5 8/9] test: use initialization in latencystats test Stephen Hemminger
2024-04-22 15:21   ` [PATCH v5 9/9] test: add more latencystats tests Stephen Hemminger
2024-05-29 22:54 ` [PATCH v6 0/8] latencystats: improvements to algorithm and test Stephen Hemminger
2024-05-29 22:54   ` [PATCH v6 1/8] latencystats: replace use of VLA Stephen Hemminger
2024-05-29 22:54   ` [PATCH v6 2/8] latencystats: handle fractional cycles per ns Stephen Hemminger
2024-05-29 22:54   ` [PATCH v6 3/8] latencystats: do not use floating point Stephen Hemminger
2024-05-29 22:54   ` [PATCH v6 4/8] latencystats: fix log messages Stephen Hemminger
2024-05-29 22:54   ` [PATCH v6 5/8] latencystats: update include files Stephen Hemminger
2024-05-29 22:54   ` [PATCH v6 6/8] latencystats: enforce that unused callback function is NULL Stephen Hemminger
2024-05-29 22:54   ` [PATCH v6 7/8] latencystats: add metric for number of samples Stephen Hemminger
2024-05-29 22:54   ` [PATCH v6 8/8] test: update to latencystats tests Stephen Hemminger
2024-07-04 15:21   ` [PATCH v6 0/8] latencystats: improvements to algorithm and test David Marchand

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=98CBD80474FA8B44BF855DF32C47DC35E9F3CF@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=dev@dpdk.org \
    --cc=reshma.pattan@intel.com \
    --cc=roretzla@linux.microsoft.com \
    --cc=stephen@networkplumber.org \
    /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;
as well as URLs for NNTP newsgroup(s).