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

[Stephen Warren]

On 08/19/2014 02:06 AM, Thierry Reding wrote:
> On Mon, Aug 18, 2014 at 01:01:17PM -0500, Joe Hershberger wrote:
>> Hi Thierry,
>>
>> On Mon, Aug 18, 2014 at 1:45 AM, Thierry Reding <thierry.reding at gmail.com>
>> wrote:
>>>
>>> From: Thierry Reding <treding at nvidia.com>
>>>
>>> It's not unusual for DHCP servers to take a couple hundred milliseconds
>>> to respond to DHCP discover messages. One possible reason for the delay
>>> can be that the server checks (typically using an ARP request) that the
>>> IP it's about to hand out isn't in use yet. To make matters worse, some
>>> servers may also queue up requests and process them sequentially, which
>>> can cause excessively long delays if clients retry too fast.
>>>
>>> Commit f59be6e850b3 ("net: BOOTP retry timeout improvements") shortened
>>> the retry timeouts significantly, but the BOOTP/DHCP implementation in
>>> U-Boot doesn't handle that well because it will ignore incoming replies
>>> to earlier requests. In one particular setup this increases the time it
>>> takes to obtain a DHCP lease from 630 ms to 8313 ms.
>>>
>>> This commit attempts to fix this in two ways. First it increases the
>>> initial retry timeout from 10 ms to 250 ms to give DHCP servers some
>>> more time to respond. At the same time a cache of outstanding DHCP
>>> request IDs is kept so that the implementation will know to continue
>>> transactions even after a retransmission of the DISCOVER message. The
>>> maximum retry timeout is also increased from 1 second to 2 seconds. An
>>> ID cache of size 4 will keep DHCP requests around for 8 seconds (once
>>> the maximum retry timeout has been reached) before dropping them. This
>>> should give servers plenty of time to respond. If it ever turns out
>>> that this isn't enough, the size of the cache can easily be increased.
>>>
>>> With this commit the DHCP lease on the above-mentioned setup still takes
>>> longer (1230 ms) than originally, but that's an acceptable compromise to
>>> improve DHCP lease acquisition time for a broader range of setups.
>>>
>>> To make it easier to benchmark DHCP in the future, this commit also adds
>>> the time it took to obtain a lease to the final "DHCP client bound to
>>> address x.x.x.x" message.

>>>   void BootpReset(void)
>>>   {
>>> +       bootp_num_ids = 0;
>>>          BootpTry = 0;
>>>          bootp_start = get_timer(0);
>>> -       bootp_timeout = 10;
>>> +       bootp_timeout = 250;
>>
>> What is the impact on the time it takes for you to get an address assigned
>> in your environment with the rest of this patch, but without this change of
>> the initial timeout?  It seems like it shouldn't impact you negatively but
>> will still help Stephen's original case.
>
> Leaving the initial timeout at 10 ms increases the time to get a lease
> from 1230 ms to 5350 ms. I suspect the reason for that is that the DHCP
> server will queue an ARP ping for each request and process them
> sequentially. Each of those takes about 600 ms and I see U-Boot sending
> out a total of 9 broadcasts. So that's 5400 ms delay only due to the
> requests that haven't been answered. The 8th broadcast is probably the
> one that U-Boot receives a response for, hence explaining the 5350 ms.
>
> Even the 250 ms timeout will make things a lot better for Stephen's use
> case. Given the earlier discussion it seems like the DHCP server in his
> network doesn't check for existing users of an IP address using ARP
> pings and replies fairly quickly, so I suspect the whole process to take
> around 300 ms for him. That's still a lot better than the 1230 ms that
> it takes on my setup (which used to be somewhere around 630 ms before
> Stephen's original patch).

I'm pretty sure I have seen ARP pings, although I guess the timeout on 
my DHCP server must be much more reasonable, since the whole DHCP 
process completes for me on the first request U-Boot sends.