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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.