You are not logged in.
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
Use static IP address?
Last edited by lucke (2015-06-01 19:53:30)
Offline
In my experience dhcpcd.service is very fast indeed.
Post the output of:
systemd-analyze critical-chain
Jin, Jîyan, Azadî
Offline
$ 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
Try systemd-networkd.
Offline
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
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
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
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
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
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