David Miller wrote: > From: Tim Bird <tim.bird@xxxxxxxxxxx> > 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@xxxxxxxxxxxxxxx, 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 ============================= -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
