| Message ID | a79265c3-bb87-b896-eb44-a8d96392d220@grenoble.cnrs.fr |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/1] package/busybox: speed up DHCP lease acquisition | expand |
Il giorno sab 13 ago 2022 alle ore 22:53 Edgar Bonet <bonet@grenoble.cnrs.fr> ha scritto: > > Commit c343e01ac4908f76520cf9a405ed87650e78dc62 made udhcpc send a > single DHCP request (instead of 3) before going to the background, thus > speeding up the boot process if the DHCP lease is not obtained > immediately. Unfortunately, this can also slow down the acquisition of > the lease as, after going to the background, udhcpc waits for 20 seconds > (instead of 3) before retrying. > > Speed up the lease acquisition by setting the retry timeout to 3 > seconds. > > Signed-off-by: Edgar Bonet <bonet@grenoble.cnrs.fr> > --- > Hello! > > While testing 2022.08-rc1 with acmesystems_acqua_a5_512mb_defconfig on a > real Acqua board (and Ubuntu 20.04 host), I noticed that my board became > very slow in getting a DHCP lease, which was a fast process on 2022.05. > Wireshark showed the following DHCP traffic ("<" = received from the > board, ">" = sent to the board): > > time (s) packet > --------------------- > 03.24 < DHCP Discover > 06.24 > DHCP Offer > 26.28 < DHCP Discover > 26.28 > DHCP Offer > 26.28 < DHCP Request > 26.28 > DHCP ACK > > Looking at the log 2022.05..2022.08-rc1, I identified the regression to > be in commit c343e01ac4908f76520cf9a405ed87650e78dc62. This commit adds > the option -t1 to the udhcpc command, which makes it go to the > background after only one try, and has the unfortunate side effect of > introducing a 20-second delay. > > With this patch applied, the lease is acquired much faster: > > 03.26 < DHCP Discover > 06.26 > DHCP Offer > 09.28 < DHCP Discover > 09.29 > DHCP Offer > 09.29 < DHCP Request > 09.29 > DHCP ACK > > Regards, While I'm ok with this patch, I suggest checking why obtaining the lease fails on your board on the first try. The intent of adding -t1 was to speed up the boot process not wasting time waiting foreground: this can be generically applied to any board: the network cable could be unplugged and this shouldn't affect the boot process time. The patch you propose here instead tries to solve a problem you have with your board: the board doesn't obtain the lease timely (first try) and then you want a faster retry. I think this is not generic enough to be acceptable for all the boards, you can solve this problem easily on your local busybox defconfig. Anyway I'm not against changing the default background retry timeout if this is not harming other users. > > Edgar. > > package/busybox/busybox.config | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/package/busybox/busybox.config b/package/busybox/busybox.config > index 2409cbcce1..137e44c870 100644 > --- a/package/busybox/busybox.config > +++ b/package/busybox/busybox.config > @@ -1022,7 +1022,7 @@ CONFIG_UDHCP_DEBUG=0 > CONFIG_UDHCPC_SLACK_FOR_BUGGY_SERVERS=80 > CONFIG_FEATURE_UDHCP_RFC3397=y > CONFIG_FEATURE_UDHCP_8021Q=y > -CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-t1 -b -R -O search" > +CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-t1 -A3 -b -R -O search" > > # > # Print Utilities > -- > 2.25.1 > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
Hi! On 13/08/2022 23:36, Angelo Compagnucci wrote: > I suggest checking why obtaining the lease fails on your board on the > first try What Wireshark shows, is that on the first try the host took three seconds to respond to the DHCP request. Three seconds is just the timeout of udhcpc, so it had just given up waiting for the response. This does not seem to be board-specific to me. I do not know why the hosts does not respond faster. It is a quite vanilla Ubuntu 20.04, with the Ethernet port configured as “Shared to other computers”. Regards, Edgar.
Edgar, All, On 2022-08-13 22:53 +0200, Edgar Bonet spake thusly: > Commit c343e01ac4908f76520cf9a405ed87650e78dc62 made udhcpc send a > single DHCP request (instead of 3) before going to the background, thus > speeding up the boot process if the DHCP lease is not obtained > immediately. Unfortunately, this can also slow down the acquisition of > the lease as, after going to the background, udhcpc waits for 20 seconds > (instead of 3) before retrying. > > Speed up the lease acquisition by setting the retry timeout to 3 > seconds. > > Signed-off-by: Edgar Bonet <bonet@grenoble.cnrs.fr> I was unsure whether to consider this a fix or a new feature, but I think we can really consider it a fix for a regresion, so: applied to master, thanks. And thanks for the detailed example! Regards, Yann E. MORIN. > --- > Hello! > > While testing 2022.08-rc1 with acmesystems_acqua_a5_512mb_defconfig on a > real Acqua board (and Ubuntu 20.04 host), I noticed that my board became > very slow in getting a DHCP lease, which was a fast process on 2022.05. > Wireshark showed the following DHCP traffic ("<" = received from the > board, ">" = sent to the board): > > time (s) packet > --------------------- > 03.24 < DHCP Discover > 06.24 > DHCP Offer > 26.28 < DHCP Discover > 26.28 > DHCP Offer > 26.28 < DHCP Request > 26.28 > DHCP ACK > > Looking at the log 2022.05..2022.08-rc1, I identified the regression to > be in commit c343e01ac4908f76520cf9a405ed87650e78dc62. This commit adds > the option -t1 to the udhcpc command, which makes it go to the > background after only one try, and has the unfortunate side effect of > introducing a 20-second delay. > > With this patch applied, the lease is acquired much faster: > > 03.26 < DHCP Discover > 06.26 > DHCP Offer > 09.28 < DHCP Discover > 09.29 > DHCP Offer > 09.29 < DHCP Request > 09.29 > DHCP ACK > > Regards, > > Edgar. > > package/busybox/busybox.config | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/package/busybox/busybox.config b/package/busybox/busybox.config > index 2409cbcce1..137e44c870 100644 > --- a/package/busybox/busybox.config > +++ b/package/busybox/busybox.config > @@ -1022,7 +1022,7 @@ CONFIG_UDHCP_DEBUG=0 > CONFIG_UDHCPC_SLACK_FOR_BUGGY_SERVERS=80 > CONFIG_FEATURE_UDHCP_RFC3397=y > CONFIG_FEATURE_UDHCP_8021Q=y > -CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-t1 -b -R -O search" > +CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-t1 -A3 -b -R -O search" > > # > # Print Utilities > -- > 2.25.1 > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
Edgar, Angelo, All, On 2022-08-14 00:25 +0200, Edgar Bonet spake thusly: > On 13/08/2022 23:36, Angelo Compagnucci wrote: > > I suggest checking why obtaining the lease fails on your board on the > > first try > > What Wireshark shows, is that on the first try the host took three > seconds to respond to the DHCP request. Three seconds is just the > timeout of udhcpc, so it had just given up waiting for the response. > This does not seem to be board-specific to me. I really pondered this and Angelo's concerns, but in the end I too believe this is not board-specific, and is a welcome fix, so I applied to master. Regards, Yann E. MORIN. > I do not know why the hosts does not respond faster. It is a quite > vanilla Ubuntu 20.04, with the Ethernet port configured as “Shared to > other computers”. > > Regards, > > Edgar. > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
diff --git a/package/busybox/busybox.config b/package/busybox/busybox.config index 2409cbcce1..137e44c870 100644 --- a/package/busybox/busybox.config +++ b/package/busybox/busybox.config @@ -1022,7 +1022,7 @@ CONFIG_UDHCP_DEBUG=0 CONFIG_UDHCPC_SLACK_FOR_BUGGY_SERVERS=80 CONFIG_FEATURE_UDHCP_RFC3397=y CONFIG_FEATURE_UDHCP_8021Q=y -CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-t1 -b -R -O search" +CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-t1 -A3 -b -R -O search" # # Print Utilities
Commit c343e01ac4908f76520cf9a405ed87650e78dc62 made udhcpc send a single DHCP request (instead of 3) before going to the background, thus speeding up the boot process if the DHCP lease is not obtained immediately. Unfortunately, this can also slow down the acquisition of the lease as, after going to the background, udhcpc waits for 20 seconds (instead of 3) before retrying. Speed up the lease acquisition by setting the retry timeout to 3 seconds. Signed-off-by: Edgar Bonet <bonet@grenoble.cnrs.fr> --- Hello! While testing 2022.08-rc1 with acmesystems_acqua_a5_512mb_defconfig on a real Acqua board (and Ubuntu 20.04 host), I noticed that my board became very slow in getting a DHCP lease, which was a fast process on 2022.05. Wireshark showed the following DHCP traffic ("<" = received from the board, ">" = sent to the board): time (s) packet --------------------- 03.24 < DHCP Discover 06.24 > DHCP Offer 26.28 < DHCP Discover 26.28 > DHCP Offer 26.28 < DHCP Request 26.28 > DHCP ACK Looking at the log 2022.05..2022.08-rc1, I identified the regression to be in commit c343e01ac4908f76520cf9a405ed87650e78dc62. This commit adds the option -t1 to the udhcpc command, which makes it go to the background after only one try, and has the unfortunate side effect of introducing a 20-second delay. With this patch applied, the lease is acquired much faster: 03.26 < DHCP Discover 06.26 > DHCP Offer 09.28 < DHCP Discover 09.29 > DHCP Offer 09.29 < DHCP Request 09.29 > DHCP ACK Regards, Edgar. package/busybox/busybox.config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)