From: Tim Bird <tim.bird@am.sony.com>
To: David Miller <davem@davemloft.net>
Cc: r.schwebel@pengutronix.de, vda.linux@googlemail.com,
linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
arjan@linux.intel.com, kernel@pengutronix.de,
netdev@vger.kernel.org
Subject: Re: new ipdelay= option for faster netboot
Date: Mon, 17 Aug 2009 18:24:26 -0700 [thread overview]
Message-ID: <4A8A02CA.7040305@am.sony.com> (raw)
In-Reply-To: <20090817.180323.253692704.davem@davemloft.net>
David Miller wrote:
> From: Tim Bird <tim.bird@am.sony.com>
> Date: Mon, 17 Aug 2009 15:35:01 -0700
>
>> Tim Bird wrote:
>>> See the definitions of CONF_PRE_OPEN and CON_POST_OPEN
>>> in net/ipv4/ipconfig.c
>>>
>>> They are set to ridiculously long values. In my experience,
>>> you can cut them down considerably with no dangerous side
>>> effects (but I haven't asked the network guys about the
>>> possible downsides).
>> It turns out that others have seen this delay. Simon
>> Arlott recently posted a patch to make the delay avoidable
>> at boot time from the kernel command line.
>>
>> See http://patchwork.kernel.org/patch/31678/
>
> "Rediculiously long" is a relative term.
No offense intended. I could have phrased this
better. The delays were a few orders of
magnitude longer than apparently needed, on my
embedded test systems with ethernet. I didn't
try eliminating them completely, as in the Arlott patch.
1.5 seconds is a long time for me. My bootup time budget for
the kernel ranges from 0.5 to 3.0 seconds, depending on the
product.
> I have card/switch combinations that take up to 10 seconds to
> negotiate a proper link.
What types of delays are these timeouts supposed to
cover? Networking delays or hardware bring-up delays?
(Or both)? If for networking delays, is this for all
types of networks, or just some (e.g. ones that create
virtual circuits)?
I'm trying to get a sense for whether the card/switch
combinations that would take this long would be encountered
in the types of embedded devices I code for. (TVs, camcorders,
etc.)
>
> So what's there now is actually a quite agressive setting.
>
> And BTW, discussions about stuff like this belong on
> netdev@vger.kernel.org, which has been added to the CC:
I was going to wait to see if this solved Robert's
problem, before widening the discussion. But I'm happy
to find out more about these delays now.
Thanks,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
next prev parent reply other threads:[~2009-08-18 1:24 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-14 17:02 New fast(?)-boot results on ARM Robert Schwebel
2009-08-14 18:19 ` Zan Lynx
2009-08-14 18:46 ` Jamie Lokier
2009-08-14 18:58 ` Robert Schwebel
2009-08-14 18:57 ` Robert Schwebel
2009-08-14 21:01 ` Linus Walleij
2009-08-14 21:15 ` Robert Schwebel
2009-08-14 21:35 ` Zan Lynx
2009-08-15 6:21 ` Artem Bityutskiy
2009-08-14 20:04 ` Denys Vlasenko
2009-08-14 20:43 ` Robert Schwebel
2009-08-15 5:59 ` Dirk Behme
2009-08-15 10:35 ` Johannes Stezenbach
2009-08-18 10:06 ` Marco Stornelli
2009-08-18 10:21 ` Robert Schwebel
2009-08-18 10:34 ` Alex Riesen
2009-08-18 10:44 ` Robert Schwebel
2009-08-18 10:48 ` Alex Riesen
2009-08-18 10:53 ` Robert Schwebel
2009-09-04 16:16 ` Wolfram Sang
2009-09-09 14:33 ` Johannes Stezenbach
2009-09-10 0:03 ` Denys Vlasenko
2009-08-17 19:15 ` Tim Bird
2009-08-17 22:35 ` new ipdelay= option for faster netboot (was Re: New fast(?)-boot results on ARM) Tim Bird
2009-08-18 1:03 ` new ipdelay= option for faster netboot David Miller
2009-08-18 1:24 ` Tim Bird [this message]
2009-08-18 1:27 ` David Miller
2009-08-18 1:40 ` Tim Bird
2009-08-18 1:56 ` David Miller
2009-08-19 11:57 ` Jamie Lokier
2009-08-18 4:56 ` Denys Vlasenko
2009-08-18 5:00 ` David Miller
2009-08-18 1:31 ` Rick Jones
2009-08-18 2:45 ` david
2009-08-18 4:56 ` Willy Tarreau
2009-08-15 6:14 ` New fast(?)-boot results on ARM Artem Bityutskiy
2009-08-18 14:06 ` Sascha Hauer
2009-08-18 15:31 ` Dirk Behme
2009-08-18 16:34 ` Marco Stornelli
2009-08-18 18:23 ` Tim Bird
2009-08-19 7:21 ` Sascha Hauer
2009-08-19 16:20 ` Dirk Behme
2009-08-20 8:57 ` Sascha Hauer
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=4A8A02CA.7040305@am.sony.com \
--to=tim.bird@am.sony.com \
--cc=arjan@linux.intel.com \
--cc=davem@davemloft.net \
--cc=kernel@pengutronix.de \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=r.schwebel@pengutronix.de \
--cc=vda.linux@googlemail.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).