You are not logged in.

#1 2015-06-01 19:39:11

davidjosepha
Member
Registered: 2013-02-21
Posts: 54

[solved] dhcpcd seriously slowing boot time, how to fix?

As the title says, dhcpcd is really the limiting factor in my boot process. Of the 4.125 seconds spent doing userland boot stuff, 2.95 are spent waiting for dhcpcd to finish loading so the network.target is reached and the last few things can continue loading. It might seem petty to complain about an 8 second boot, but I'm just trying to get it as quick as possible. What can I do to make it go faster? I've read through the wiki on improving boot times, dhcpcd, etc. and haven't found anything that has helped significantly. This is on a permanent ethernet connection, by the way.

Last edited by davidjosepha (2015-06-01 21:02:29)

Offline

#2 2015-06-01 19:52:43

lucke
Member
From: Poland
Registered: 2004-11-30
Posts: 4,018

Re: [solved] dhcpcd seriously slowing boot time, how to fix?

Use static IP address?

Last edited by lucke (2015-06-01 19:53:30)

Offline

#3 2015-06-01 20:00:18

Head_on_a_Stick
Member
From: London
Registered: 2014-02-20
Posts: 7,752
Website

Re: [solved] dhcpcd seriously slowing boot time, how to fix?

In my experience dhcpcd.service is very fast indeed.

Post the output of:

systemd-analyze critical-chain

Offline

#4 2015-06-01 20:08:22

davidjosepha
Member
Registered: 2013-02-21
Posts: 54

Re: [solved] dhcpcd seriously slowing boot time, how to fix?

$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @5.108s
└─multi-user.target @5.108s
  └─httpd.service @4.848s +259ms
    └─remote-fs.target @4.845s
      └─media-video.mount @4.771s +73ms
        └─network-online.target @4.765s
          └─network.target @4.759s
            └─dhcpcd@enp5s0.service @1.370s +3.388s
              └─basic.target @1.309s
                └─sockets.target @1.309s
                  └─dbus.socket @1.309s
                    └─sysinit.target @1.308s
                      └─sys-fs-fuse-connections.mount @4.844s +4ms
                        └─system.slice @178ms

So, it was even slower this boot than it was the last time I tested it.

Use static IP address?

My router is using some sort of dhcp configuration that I don't want to mess with, because last time I did that, I had to bypass my router to get my internet working for a week while I tried to figure out what the fuck I had done. I am using dhcp reservations for most of my devices though, so they always have the same ip. Can I set up a static connection like this, or am I going to run into problems since it's still dhcp?

Offline

#5 2015-06-01 20:14:59

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: [solved] dhcpcd seriously slowing boot time, how to fix?

Try systemd-networkd.

Offline

#6 2015-06-01 20:28:34

davidjosepha
Member
Registered: 2013-02-21
Posts: 54

Re: [solved] dhcpcd seriously slowing boot time, how to fix?

karol wrote:

Try systemd-networkd.

Thank you so much. You're my hero.

$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1.239s
└─multi-user.target @1.239s
  └─httpd.service @931ms +307ms
    └─remote-fs.target @928ms
      └─media-video.mount @865ms +62ms
        └─network-online.target @857ms
          └─network.target @857ms
            └─systemd-networkd.service @817ms +40ms
              └─dbus.service @729ms
                └─basic.target @723ms
                  └─sockets.target @722ms
                    └─dbus.socket @722ms
                      └─sysinit.target @722ms
                        └─sys-fs-fuse-connections.mount @927ms +4ms
                          └─systemd-journald.socket @192ms
                            └─-.slice @191ms

Offline

#7 2015-06-01 20:31:40

lucke
Member
From: Poland
Registered: 2004-11-30
Posts: 4,018

Re: [solved] dhcpcd seriously slowing boot time, how to fix?

At home, I have a DHCP server running, with IP addresses bound to MAC addresses, and a static IP address set up on my desktop anyway.

Offline

#8 2015-06-03 04:01:21

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [solved] dhcpcd seriously slowing boot time, how to fix?

karol wrote:

Try systemd-networkd.

Or you could pass the -A option to dhcpcd for the same speed.

-A means Do NOT check for duplicate addresses via ARP.

dhcpcd by default ensures you don't get a duplicate address - every other solutions doesn't.

Offline

#9 2015-06-03 04:04:11

davidjosepha
Member
Registered: 2013-02-21
Posts: 54

Re: [solved] dhcpcd seriously slowing boot time, how to fix?

I already had the 'noarp' setting set in my dhcpcd.conf when the times given earlier were recorded, which should do the same thing, no? And even with that, systemd-netword was way, way faster.

Offline

#10 2015-06-03 13:01:24

rsmarples
Member
Registered: 2009-05-12
Posts: 287

Re: [solved] dhcpcd seriously slowing boot time, how to fix?

roy@uberpc ~ $ sudo dhcpcd -k
sending signal ARLM to pid 3015
waiting for pid 3015 to exit
roy@uberpc ~ $ time sudo dhcpcd         
dev: loaded udev
enp3s0: adding address fe80::8d30:2b85:75ba:2d40
wlp4s0: adding address fe80::893f:45de:2864:e33f
DUID 00:01:00:01:1b:79:14:0c:e8:94:f6:3f:9b:95
wlp4s0: IAID f6:3f:9b:95
enp3s0: waiting for carrier
wlp4s0: soliciting a DHCP lease
wlp4s0: offered 10.73.2.30 from 10.73.1.1 `uberserver.marples.name'
wlp4s0: soliciting an IPv6 router
wlp4s0: leased 10.73.2.30 for 3600 seconds
wlp4s0: router 10.73.1.1 requires a host route
wlp4s0: adding route to 10.73.2.0/24
wlp4s0: adding host route to 10.73.1.1
wlp4s0: adding default route via 10.73.1.1
ntpd               | * Stopping ntpd ... [ ok ]
ntpd               | * Starting ntpd ... [ ok ]
forked to background, child pid 3276

real    0m5.083s
user    0m0.031s
sys     0m0.009s

So, with ARP checking it's just over 5 seconds, which is about right.

roy@uberpc ~ $ sudo dhcpcd -k
sending signal ARLM to pid 3276
waiting for pid 3276 to exit
roy@uberpc ~ $ time sudo dhcpcd -A
dev: loaded udev
enp3s0: adding address fe80::8d30:2b85:75ba:2d40
wlp4s0: adding address fe80::893f:45de:2864:e33f
DUID 00:01:00:01:1b:79:14:0c:e8:94:f6:3f:9b:95
wlp4s0: IAID f6:3f:9b:95
enp3s0: waiting for carrier
wlp4s0: soliciting a DHCP lease
wlp4s0: offered 10.73.2.30 from 10.73.1.1 `uberserver.marples.name'
wlp4s0: leased 10.73.2.30 for 3600 seconds
wlp4s0: router 10.73.1.1 requires a host route
wlp4s0: adding route to 10.73.2.0/24
wlp4s0: adding host route to 10.73.1.1
wlp4s0: adding default route via 10.73.1.1
ntpd               | * Stopping ntpd ... [ ok ]
ntpd               | * Starting ntpd ... [ ok ]
forked to background, child pid 3537

real    0m0.170s
user    0m0.030s
sys     0m0.010s
roy@uberpc ~ $ 

Without ARP, it's under 200 milliseconds. This was a lucky run due to RFC mandated randomised startup delays (this is noted when you add --debug, I omitted this otherwise this post would be quite huge with other debug info)
But wait, we can go faster yet by ignoring these RFC mandated delays.

roy@uberpc ~/src/dhcpcd $ sudo dhcpcd -k
sending signal ARLM to pid 5994
waiting for pid 5994 to exit
roy@uberpc ~/src/dhcpcd $ time sudo dhcpcd -A --nodelay
dev: loaded udev
DUID 00:01:00:01:1b:79:14:0c:e8:94:f6:3f:9b:95
wlp4s0: IAID f6:3f:9b:95
wlp4s0: soliciting an IPv6 router
wlp4s0: soliciting a DHCP lease
enp3s0: waiting for carrier
wlp4s0: offered 10.73.2.30 from 10.73.1.1 `uberserver.marples.name'
wlp4s0: leased 10.73.2.30 for 3600 seconds
wlp4s0: router 10.73.1.1 requires a host route
wlp4s0: adding route to 10.73.2.0/24
wlp4s0: adding host route to 10.73.1.1
wlp4s0: adding default route via 10.73.1.1
ntpd               | * Stopping ntpd ... [ ok ]
ntpd               | * Starting ntpd ... [ ok ]
forked to background, child pid 6272

real    0m0.126s
user    0m0.028s
sys     0m0.013s
roy@uberpc ~/src/dhcpcd $

I'm sure we can get under 100ms here!
Let's strip the NTP options to avoid restarting that.

roy@uberpc ~/src/dhcpcd $ sudo dhcpcd -k
sending signal ARLM to pid 6653
waiting for pid 6653 to exit
roy@uberpc ~/src/dhcpcd $ time sudo dhcpcd -A --nodelay -O ntp_servers
dev: loaded udev
DUID 00:01:00:01:1b:79:14:0c:e8:94:f6:3f:9b:95
wlp4s0: IAID f6:3f:9b:95
wlp4s0: soliciting an IPv6 router
wlp4s0: soliciting a DHCP lease
enp3s0: waiting for carrier
wlp4s0: offered 10.73.2.30 from 10.73.1.1 `uberserver.marples.name'
wlp4s0: leased 10.73.2.30 for 3600 seconds
wlp4s0: router 10.73.1.1 requires a host route
wlp4s0: adding route to 10.73.2.0/24
wlp4s0: adding host route to 10.73.1.1
wlp4s0: adding default route via 10.73.1.1
forked to background, child pid 6815

real    0m0.068s
user    0m0.019s
sys     0m0.007s
roy@uberpc ~/src/dhcpcd $

Lets go nuts and not bother running any scripts.
After all, DNS from DHCP is optional - a good local resolver will try DNS ROOT servers by default.
But screw fast DNS lookups, we want a fast boot!

roy@uberpc ~/src/dhcpcd $ sudo dhcpcd -k
sending signal ARLM to pid 7025
waiting for pid 7025 to exit
roy@uberpc ~/src/dhcpcd $ time sudo dhcpcd -A --nodelay -O ntp_servers -c /dev/null
dev: loaded udev
DUID 00:01:00:01:1b:79:14:0c:e8:94:f6:3f:9b:95
wlp4s0: IAID f6:3f:9b:95
wlp4s0: soliciting an IPv6 router
wlp4s0: soliciting a DHCP lease
enp3s0: waiting for carrier
wlp4s0: offered 10.73.2.30 from 10.73.1.1 `uberserver.marples.name'
wlp4s0: leased 10.73.2.30 for 3600 seconds
wlp4s0: router 10.73.1.1 requires a host route
wlp4s0: adding route to 10.73.2.0/24
wlp4s0: adding host route to 10.73.1.1
wlp4s0: adding default route via 10.73.1.1
forked to background, child pid 7030

real    0m0.024s
user    0m0.001s
sys     0m0.002s
roy@uberpc ~/src/dhcpcd $

palm, meet face! I was stupidly releasing the lease between runs. lets just clear the IP from the network stack to instead.
After all, we are rebinding to the same network each boot.

oy@uberpc ~/src/dhcpcd $ sudo dhcpcd -x
sending signal TERM to pid 7900
waiting for pid 7900 to exit
roy@uberpc ~/src/dhcpcd $ sudo ip a d 10.73.2.30/24 dev wlp4s0
roy@uberpc ~/src/dhcpcd $ time sudo dhcpcd -4A --nodelay -O ntp_servers -c /dev/null --nodev
DUID 00:01:00:01:1b:79:14:0c:e8:94:f6:3f:9b:95
wlp4s0: IAID f6:3f:9b:95
wlp4s0: rebinding lease of 10.73.2.30
enp3s0: waiting for carrier
wlp4s0: leased 10.73.2.30 for 3600 seconds
wlp4s0: router 10.73.1.1 requires a host route
wlp4s0: adding route to 10.73.2.0/24
wlp4s0: adding host route to 10.73.1.1
wlp4s0: adding default route via 10.73.1.1
forked to background, child pid 7992

real    0m0.015s
user    0m0.002s
sys     0m0.000s
roy@uberpc ~/src/dhcpcd $

There are other ways of making dhcpcd go faster, but that involves hacking the code NOT to query the kernel for any existing IP addresses or routes so we don't break networking needlessly even for a every small window and other such things.
So at 15ms I think dhcpcd is pretty fast, and this is just profilng via the time shell command.

Of course, dhcpcd by default provides the most RFC compliant way of autoconfiguring your network address.

But of course, I leave the best trick until last. A well configured system with well written programs shouldn't need to forceably wait for the initial DHCP run to finish.

roy@uberpc ~/src/dhcpcd $ sudo dhcpcd -k
sending signal ARLM to pid 7992
waiting for pid 7992 to exit
roy@uberpc ~/src/dhcpcd $ time sudo dhcpcd -b
dev: loaded udev
forked to background, child pid 8217

real    0m0.004s
user    0m0.001s
sys     0m0.002s

If you still believe dhcpcd to be slow, add the debug option and post some logs, ideally with timestamps and then we'll talk about making it go faster to meet your needs.

Offline

#11 2015-06-04 04:08:54

branch
Member
Registered: 2014-03-16
Posts: 209

Re: [solved] dhcpcd seriously slowing boot time, how to fix?

If we are going to compare we should level the playing field. By default, dhcpcd waits for the interface to be configured before forking whereas systemd-networkd does not. Setting "background" in dhcpcd.conf will make dhcpcd behave like systemd-networkd. Alternately, enabling "systemd-networkd-wait-online.service" will cause network-online.target to wait until the interfaces are configured, emulating the behaviour of dhcpcd.

@davidjosepha If using systemd-networkd without systemd-networkd-wait-online works reliably then your services probably do not depend on the interface being configured to start successfully which implies it would be safe to use dhcpcd with "background" set.

Offline

Board footer

Powered by FluxBB