Didier Kryn <kryn@???> writes:
> Le 09/11/2015 15:58, Rainer Weikusat a écrit :
>> Didier Kryn <kryn@???> 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".