From: Jakub Sitnicki <jakub@cloudflare.com>
To: Neal Cardwell <ncardwell@google.com>
Cc: Weiping Zhang <zhangweiping@didiglobal.com>,
edumazet@google.com, davem@davemloft.net,
yoshfuji@linux-ipv6.org, dsahern@kernel.org, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org, zwp10758@gmail.com
Subject: Re: [RFC PATCH] tcp: correct srtt and mdev_us calculation
Date: Tue, 06 Dec 2022 10:11:11 +0100 [thread overview]
Message-ID: <87mt805181.fsf@cloudflare.com> (raw)
In-Reply-To: <CADVnQykvAWHFOec_=DyU9GMLppK6mpeK-GqUVbktJffj1XA5rQ@mail.gmail.com>
On Mon, Dec 05, 2022 at 02:15 PM -05, Neal Cardwell wrote:
> On Mon, Dec 5, 2022 at 1:02 PM Weiping Zhang
> <zhangweiping@didiglobal.com> wrote:
>>
>> From the comments we can see that, rtt = 7/8 rtt + 1/8 new,
>> but there is an mistake,
>>
>> m -= (srtt >> 3);
>> srtt += m;
>>
>> explain:
>> m -= (srtt >> 3); //use t stands for new m
>> t = m - srtt/8;
>>
>> srtt = srtt + t
>> = srtt + m - srtt/8
>> = srtt 7/8 + m
>>
>> Test code:
>>
>> #include<stdio.h>
>>
>> #define u32 unsigned int
>>
>> static void test_old(u32 srtt, long mrtt_us)
>> {
>> long m = mrtt_us;
>> u32 old = srtt;
>>
>> m -= (srtt >> 3);
>> srtt += m;
>>
>> printf("%s old_srtt: %u mrtt_us: %ld new_srtt: %u\n", __func__, old, mrtt_us, srtt);
>> }
>>
>> static void test_new(u32 srtt, long mrtt_us)
>> {
>> long m = mrtt_us;
>> u32 old = srtt;
>>
>> m = ((m - srtt) >> 3);
>> srtt += m;
>>
>> printf("%s old_srtt: %u mrtt_us: %ld new_srtt: %u\n", __func__, old, mrtt_us, srtt);
>> }
>>
>> int main(int argc, char **argv)
>> {
>> u32 srtt = 100;
>> long mrtt_us = 90;
>>
>> test_old(srtt, mrtt_us);
>> test_new(srtt, mrtt_us);
>>
>> return 0;
>> }
>>
>> ./a.out
>> test_old old_srtt: 100 mrtt_us: 90 new_srtt: 178
>> test_new old_srtt: 100 mrtt_us: 90 new_srtt: 98
>>
>> Signed-off-by: Weiping Zhang <zhangweiping@didiglobal.com>
>
> Please note that this analysis and this test program do not take
> account of the fact that srtt in the Linux kernel is maintained in a
> form where it is shifted left by 3 bits, to maintain a 3-bit
> fractional part. That is why at first glance it would seem there is a
> missing multiplication of the new sample by 1/8. By not shifting the
> new sample when it is added to srtt, the new sample is *implicitly*
> multiplied by 1/8.
Nifty. And it's documented.
struct tcp_sock {
…
u32 srtt_us; /* smoothed round trip time << 3 in usecs */
Thanks for the hint.
>> net/ipv4/tcp_input.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 0640453fce54..0242bb31e1ce 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -848,7 +848,7 @@ static void tcp_rtt_estimator(struct sock *sk, long mrtt_us)
>> * that VJ failed to avoid. 8)
>> */
>> if (srtt != 0) {
>> - m -= (srtt >> 3); /* m is now error in rtt est */
>> + m = (m - srtt >> 3); /* m is now error in rtt est */
>> srtt += m; /* rtt = 7/8 rtt + 1/8 new */
>> if (m < 0) {
>> m = -m; /* m is now abs(error) */
>> @@ -864,7 +864,7 @@ static void tcp_rtt_estimator(struct sock *sk, long mrtt_us)
>> if (m > 0)
>> m >>= 3;
>> } else {
>> - m -= (tp->mdev_us >> 2); /* similar update on mdev */
>> + m = (m - tp->mdev_us >> 2); /* similar update on mdev */
>> }
>> tp->mdev_us += m; /* mdev = 3/4 mdev + 1/4 new */
>> if (tp->mdev_us > tp->mdev_max_us) {
>> --
>> 2.34.1
>
> AFAICT this proposed patch does not change the behavior of the code
> but merely expresses the same operations with slightly different
> syntax. Am I missing something? :-)
I've been wondering about that too. There's a change hiding behind
operator precedence. Would be better expressed with explicitly placed
parenthesis:
m = (m - srtt) >> 3; /* m is now error in rtt est */
next prev parent reply other threads:[~2022-12-06 9:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-05 17:59 [RFC PATCH] tcp: correct srtt and mdev_us calculation Weiping Zhang
2022-12-05 18:27 ` Eric Dumazet
2022-12-05 19:15 ` Neal Cardwell
2022-12-06 9:11 ` Jakub Sitnicki [this message]
2022-12-10 13:35 ` Weiping Zhang
2022-12-10 17:45 ` Eric Dumazet
2022-12-11 17:04 ` Stephen Hemminger
-- strict thread matches above, loose matches on Subject: below --
2022-12-05 18:07 Weiping Zhang
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=87mt805181.fsf@cloudflare.com \
--to=jakub@cloudflare.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=yoshfuji@linux-ipv6.org \
--cc=zhangweiping@didiglobal.com \
--cc=zwp10758@gmail.com \
/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).