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 <[email protected]> > > > > 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 <[email protected]> > > --- > > 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
pgpsyuv4MXS3T.pgp
Description: PGP signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
