Didier Kryn <[email protected]> writes: > Le 09/11/2015 15:58, Rainer Weikusat a écrit : >> Didier Kryn <[email protected]> writes: >> >> [...] >> >>>>> Maybe you never shutdown, but some, like me, prefer to put their >>>>> laptop back in a well-know state from time to time. >>>> Indeed, I do reboot from time to time. Sometimes it's because I >>>> didn't keep an eye on battery state - it's getting towards the end of >>>> it's life and I can no longer rely on the "low battery warning, >>>> followed a while later by a forced sleep and suspend to disk" that >>>> happens with a healthy battery. More often it's to clear memory - >>>> something seems to have a leak, and I'm not that convinced OS X >>>> memory management is all that good. But normally, I just use sleep >>>> mode. >>> When I was testing a static build of vdev, I used to reboot my >>> laptop several times per hour, alternatively to Debian Wheezy and to a >>> minimalistic OS on a USB stick, containing essentially vdev and >>> busybox. Reboot time is around 30s, yet it's still irritating. >>> >>> Bios + Grub + kernel startup take by far the biggest part, but I >>> think there's room for progress on these. >> "To a degree": The three things wich take longest when booting my >> workstation are >> >> - boot the kernel >> - get an address via DHCP >> - set the time via NTP >> > - boot the kernel: agreed. > - DHCP: use static config if your DHCP server is slow. This can be > done at home, and often also at work.
In this case, the problem mainly seems to be that dhclient sends its first request before the interface is actually up and that it takes 10s before it retries that. Ultimatively, this looks like a driver problem because frames queued for sending in the time between the interface being 'upped' via syscall and it actually becoming ready to send should be queued and not discarded (This is a somewhat educated guess based on the output during booting. It may be completely wrong). I've changed the inital retransmission interval but more out of curiosity. The issue is not that annoying that I'd want to put serious work into it. > - NTP: if you have a working RTC onboard, you've got hours before > a time drift is detectable. I don't know of any service explicitely > depending on NTP. After booting, the discrepancy between the RTC clock and the actual time is unknown. Hence, the clock has to be set before starting anything which assumes that it is available _as a clock_ (a device use to measure passing time according to some globally agreed upon frame of reference). My computer isn't really running (some part of) a distribution application which would make this necessary but I'd like it to be able to (because I'm dealing with other computers who do). Things would presumably improve in this respect if I'd remove the NTP-server-which-doesnt-exist-anymore from the configuration but again, it's not that important. Thankfully, I found a simple workaround for a program which would otherwise cause absolutely unacceptable startup delays: While starting, udev prints thousands of "this interface is deprecated, use that interface instead" messages to the system console and if that's a framebuffer console, this takes several minutes. Booting in text mode neatly avoids this problem. I mainly wrote this to provide an example that things aren't that simple: Avoidable delays during startup can happen for lots of reasons but usually because of something some application does, not because the boot system isn't optimized enough. At best, an attempt to improve "boot times" by extensively changing that is a fool's errand, at worst, it's a red herring intentionally employed to sell something totally unrelated to (relatively) "non-technical people". _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
