From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 19 Aug 2014 09:59:00 -0600 Subject: [U-Boot] [PATCH] net: More BOOTP retry timeout improvements In-Reply-To: <20140819074330.GF12859@ulmo> References: <1408344305-28828-1-git-send-email-thierry.reding@gmail.com> <20140819074330.GF12859@ulmo> Message-ID: <53F37444.5060101@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 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 >> wrote: >>> >>> From: Thierry Reding >>> >>> 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.