From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Mon, 18 Aug 2014 10:20:14 -0600 Subject: [U-Boot] [PATCH] net: More BOOTP retry timeout improvements In-Reply-To: <1408344305-28828-1-git-send-email-thierry.reding@gmail.com> References: <1408344305-28828-1-git-send-email-thierry.reding@gmail.com> Message-ID: <53F227BE.6000704@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/18/2014 12: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. Tested-by: Stephen Warren So long as it's considered safe to accept DHCP responses to older requests, this approach seems fine. Having seen this patch now (I hadn't when I responded to the other thread), I guess I don't have a strong an opinion re: reverting my original patch vs. taking this; net maintainers, feel free to decide:-)