From: Damian Lukowski <damian@tvk.rwth-aachen.de>
To: David Miller <davem@davemloft.net>
Cc: yuri@itinteg.net, akpm@linux-foundation.org,
netdev@vger.kernel.org, bugzilla-daemon@bugzilla.kernel.org,
bugme-daemon@bugzilla.kernel.org
Subject: Re: [Bugme-new] [Bug 18952] New: The mount of SYN retries is not equal to /proc/sys/net/ipv4/tcp_syn_retries
Date: Mon, 27 Sep 2010 22:00:08 +0200 [thread overview]
Message-ID: <1285617608.9983.30.camel@nexus> (raw)
In-Reply-To: <20100927.011046.45906887.davem@davemloft.net>
Ok, I see.
When I read your mail this morning, I was afraid, that this is another
bug in the calculation routine. However, the routine seems ok to me.
The problem is the high discrepancy between the RTO_MIN-based
calculation and TCP_TIMEOUT_INIT-based actual backoff in the SYN-case.
Yuris example did not reveal a conceptually new bug, as the same
behaviour can be observed on pre 2.6.32 kernels at higher values.
I tested wget on a 2.6.26 kernel with timeout values of 300 and above.
All runs did time out after 189 seconds, with the sysctl-value as their
hard limit.
My suggestion for solving this issue:
Introducing a third boolean parameter for retransmits_timed_out()
indicating whether the socket is in SYN state or not. In the SYN case,
TCP_TIMEOUT_INIT will be used for the calculation instead of
TCP_RTO_MIN.
Is that ok?
Regards
Damian
Am Montag, den 27.09.2010, 01:10 -0700 schrieb David Miller:
> From: Yuri Chislov <yuri@itinteg.net>
> Date: Mon, 27 Sep 2010 10:07:06 +0200
>
> > It looks like the behavior changed in 2.6.32. 2.6.32 and up, uses some
> > calculation instead of a direct definition of the retries number, that makes it
> > harder to achieve the necessary system behavior.
> >
> > The default behavior of the system changed completely
> > (the old default connect timeout was ~ 180 seconds, while the new one is ~21
> > sec).
> >
> > The new behavior invalidates the kernel documentation and tcp man page.
> >
> > It's not possible to set a connect timeout > 25 sec in the applications while
> > using the default values in /proc.
> >
> > From my view point is regression.
>
> Agreed, Damian you have to fix this.
>
> Otherwise I'm reverting all of your Revert Backoff commits.
next prev parent reply other threads:[~2010-09-27 20:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-18952-10286@https.bugzilla.kernel.org/>
2010-09-22 9:02 ` [Bugme-new] [Bug 18952] New: The mount of SYN retries is not equal to /proc/sys/net/ipv4/tcp_syn_retries Andrew Morton
2010-09-25 3:05 ` David Miller
2010-09-27 8:07 ` Yuri Chislov
2010-09-27 8:10 ` David Miller
2010-09-27 8:35 ` Damian Lukowski
2010-09-27 20:00 ` Damian Lukowski [this message]
2010-09-28 4:52 ` David Miller
2010-09-28 7:40 ` Yuri Chislov
2010-09-28 9:47 ` Ilpo Järvinen
2010-09-28 12:08 ` Yuri Chislov
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=1285617608.9983.30.camel@nexus \
--to=damian@tvk.rwth-aachen.de \
--cc=akpm@linux-foundation.org \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=yuri@itinteg.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;
as well as URLs for NNTP newsgroup(s).