On 08/15/2014 06:49 AM, Thierry Reding wrote:
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 <swar...@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 <swar...@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?
That will still introduce extremely large delays into the boot process,
which is exactly what this patch was trying to avoid. 500..1000ms are
the same order of magnitude as the initial delay without this patch applied.
Re-transmitting a DHCP request shouldn't prevent a response to the
previous request from being processed - AFAIK each request is
idempotent. Can you debug what is causing the 8s delay? Are earlier
responses received and rejected for some reason, or is your DHCP server
getting confused by the multiple requests and not responding, or ...?
(and as an aside, how on earth is your DHCP server taking >500ms to
respond, yet still actually responding?)
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
