From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 06 Aug 2014 09:58:12 -0600 Subject: [U-Boot] [PATCH] net: BOOTP retry timeout improvements In-Reply-To: <1406331048-27700-1-git-send-email-swarren@wwwdotorg.org> References: <1406331048-27700-1-git-send-email-swarren@wwwdotorg.org> Message-ID: <53E25094.4010008@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 07/25/2014 05:30 PM, Stephen Warren wrote: > From: Stephen Warren > > Currently, the BOOTP code sends out its initial request as soon as the > Ethernet driver indicates "link up". If this packet is lost or not > replied to for some reason, the code waits for a 1s timeout before > retrying. For some reason, such early packets are often lost on my > system, so this causes an annoying delay. > > To optimize this, modify the BOOTP code to have very short timeouts for > the first packet transmitted, but gradually increase the timeout each > time a timeout occurs. This way, if the first packet is lost, the second > packet is transmitted quite quickly and hence the overall delay is low. > However, if there's still no response, we don't keep spewing out packets > at an insane speed. > > It's arguably more correct to try and find out why the first packet is > lost. However, it seems to disappear inside my Ethenet chip; the TX chip > indicates no error during TX (not that it has much in the way of > reporting...), yet wireshark on the RX side doesn't see any packet. > FWIW, I'm using an ASIX USB Ethernet adapter. Perhaps "link up" is > reported too early or based on the wrong condition in HW, and we should > add some fixed extra delay into the driver. However, this would slow down > every link up event even if it ends up not being needed in some cases. > Having BOOTP retry quickly applies the fix/WAR to every possible > Ethernet device, and is quite simple to implement, so seems a better > solution. Joe, Tom, Does this patch look OK?