[U-Boot] [PATCH] net: BOOTP retry timeout improvements

[Thierry Reding <thierry.reding@gmail.com>]

On Fri, Aug 15, 2014 at 02:39:45PM +0200, Thierry Reding wrote:
> On Fri, Jul 25, 2014 at 05:30:48PM -0600, Stephen Warren wrote:
> > From: Stephen Warren <swarren@nvidia.com>
> > 
> > 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.
> > 
> > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > ---
> >  net/bootp.c | 38 +++++++++++++++++++++++++++++++-------
> >  net/bootp.h |  3 +--
> >  net/net.c   |  4 ++--
> >  3 files changed, 34 insertions(+), 11 deletions(-)
> 
> Sorry for jumping in a little late, but I only encountered this after
> rebasing on latest origin/master today.
> 
> With this patch applied, it takes about 8 seconds until U-Boot manages
> to get a DHCP address (it needs to broadcast 14 times) whereas with the
> patch reverted I get a reply almost instantly (with only a single
> broadcast).
> 
> I'm testing this on a Jetson TK1 (with local patches for PCIe and
> ethernet support).

Further tests show that if I increase the initial bootp_timeout to
anywhere beyond 750 ms things don't regress for me. If I go down to 500
ms it will send out a second broadcast (presumably because the DHCP
server in my network hasn't replied yet) but still get a reasonably
quick reply (~ 1 second).

So it would seem that this parameter depends to a large degree on the
network infrastructure and needs to be carefully tweaked to work well in
most circumstances.

Could you try if 500, 750 and 1000 ms as initial bootp_timeout value
give you acceptable results?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140815/f1931ab2/attachment.pgp>