# Speed up boot time.

## apinsard

Hi,

I'm currently trying to speed up my OS boot time. I successfully decreased this time from ~15s to ~8s. I think I can still decrease it to 5s, or even 3s.

Considering dmesg, the next step is to speed up network startup:

```
Jelly ~ # dmesg|tail

[    5.671331] XFS (dm-0): Mounting Filesystem

[    5.765824] XFS (dm-0): Ending clean mount

[    5.794860] XFS (dm-1): Mounting Filesystem

[    5.897440] XFS (dm-1): Ending clean mount

[    5.898202] mount (1689) used greatest stack depth: 4552 bytes left

[    6.723073] 0000:04:00.0: Missing Free firmware

[    6.724311] r8169 0000:04:00.0 eth0: unable to load firmware patch /*(DEBLOBBED)*/ (-22)

[    6.735636] r8169 0000:04:00.0 eth0: link down

[    6.735805] ip (1922) used greatest stack depth: 3576 bytes left

[    8.688318] r8169 0000:04:00.0 eth0: link up
```

It seams that an error occurred, delaying eth0 link up.

```
[    6.723073] 0000:04:00.0: Missing Free firmware

[    6.724311] r8169 0000:04:00.0 eth0: unable to load firmware patch /*(DEBLOBBED)*/ (-22)
```

This probably due to the fact that r8169 is loaded before the rootfs is mounted.

```
Jelly ~ # dmesg|egrep "sda|r8169"

[    0.000000] Command line: BOOT_IMAGE=/vanilla-3.8.1 rootfstype=xfs root=/dev/sda4

[    0.000000] Kernel command line: BOOT_IMAGE=/vanilla-3.8.1 rootfstype=xfs root=/dev/sda4

[    2.096111] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded

[    2.096296] r8169 0000:04:00.0: irq 45 for MSI/MSI-X

[    2.096464] r8169 0000:04:00.0 eth0: RTL8168evl/8111evl at 0xffffc90000056000, bc:5f:f4:67:05:1d, XID 0c900800 IRQ 45

[    2.096473] r8169 0000:04:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]

[    2.433806] sd 4:0:0:0: [sda] 117231408 512-byte logical blocks: (60.0 GB/55.8 GiB)

[    2.434634] sd 4:0:0:0: [sda] Write Protect is off

[    2.434974] sd 4:0:0:0: [sda] Mode Sense: 00 3a 00 00

[    2.435003] sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

[    2.436665]  sda: sda1 sda2 sda3 sda4

[    2.437295] sd 4:0:0:0: [sda] Attached SCSI disk

[    2.825591] XFS (sda4): Mounting Filesystem

[    2.846112] XFS (sda4): Ending clean mount

[    5.393080] Adding 8388604k swap on /dev/sda3.  Priority:-1 extents:1 across:8388604k SS

[    6.724311] r8169 0000:04:00.0 eth0: unable to load firmware patch /*(DEBLOBBED)*/ (-22)

[    6.735636] r8169 0000:04:00.0 eth0: link down

[    8.688318] r8169 0000:04:00.0 eth0: link up
```

Why is it loaded in the wrong order? How can i fix this? Here is my whole dmesg. Any other idea?

Thanks in advance.

Edit. Just to point out:

```
Jelly ~ # zcat /proc/config.gz | grep R8169

CONFIG_R8169=y

Jelly ~ # lspci|grep Ethernet

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 06)
```

----------

## NeddySeagoon

apinsard,

Drivers that need firmware must have both parts in the same place - either both in the kernel binary or both on the root filesystem.

A half and half mix fails.

The kernel for my diskless box, which also uses r1869 contains 

```
 (/sbin/hotplug) path to uevent helper                                                             

  │ │[*] Maintain a devtmpfs filesystem to mount at /dev     

  │ │[*]   Automount devtmpfs at /dev, after the kernel mounted the rootfs  

  │ │[*] Select only drivers that don't need compile-time external firmware  

  │ │[*] Prevent firmware from being built   

  │ │-*- Userspace firmware loading support   

  │ │[ ]   Include in-kernel firmware blobs in kernel binary  

  │ │(rtl_nic/rtl8168e-2.fw radeon/PALM_pfp.bin radeon/PALM_me.bin radeon/SUMO_rlc.bin) External firmware blobs to build into the kernel binary 

  │ │(/lib/firmware/) Firmware blobs root directory
```

notice the rtl_nic/...

Without that boot is stalled for 60 sec.

I can't really make the network driver a module ... the box is diskless, so the network is needed to mount root.

I can't ell you what firmware you need.  The filename is normally in dmesg but in your case, its not.

----------

## apinsard

I don't either have a /lib/firmware directory.

I'm also configuring my kernel from papy's seeds and not yet done. Maybe some settings are not currently well set?

```
Jelly ~ # zcat /proc/config.gz |egrep "FIRMWARE|FW"

CONFIG_PREVENT_FIRMWARE_BUILD=y

CONFIG_FW_LOADER=y

# CONFIG_FIRMWARE_IN_KERNEL is not set

CONFIG_EXTRA_FIRMWARE=""

# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set

CONFIG_FIRMWARE_EDID=y

# CONFIG_USB_ISIGHTFW is not set

CONFIG_FIRMWARE_MEMMAP=y

# CONFIG_GOOGLE_FIRMWARE is not set
```

```
 (/sbin/hotplug) path to uevent helper

  │ │[*] Maintain a devtmpfs filesystem to mount at /dev

  │ │[ ]   Automount devtmpfs at /dev, after the kernel mounted the rootfs

  │ │[*] Select only drivers that don't need compile-time external firmware

  │ │[*] Prevent firmware from being built

  │ │-*- Userspace firmware loading support

  │ │[ ]   Include in-kernel firmware blobs in kernel binary

  │ │()    External firmware blobs to build into the kernel binary

  │ │[ ] Driver Core verbose debug messages

  │ │[ ] Managed device resources verbose debug messages
```

Edit. I read through CONFIG_FIRMWARE_IN_KERNEL's help and realized that I shall make firmware_install. I did and rebooted. I now have a /lib/firmware directory but none of these firmware seems related to Realtek. And I still have the error in dmesg.Last edited by apinsard on Sat Mar 02, 2013 4:20 pm; edited 1 time in total

----------

## Hu

Based on that dmesg output, it looks like the kernel is one of the "-libre" forks that has little or no support for firmware designated by the -libre maintainers as non-Free.  If so, and if the maintainers have designated the firmware for your card as non-Free, then you must either accept the lack of firmware or change to a non-libre kernel.

----------

## NeddySeagoon

apinsard,

I would expect the file you need to be in /lib/firmware/rtl_nic  

Pappys seeds have all hardware setting off - you have to set your own.

This includes network card drivers and their firmware.

You may need to 

```
emerge linux-firmware
```

to populate /lib/firmware

----------

## apinsard

I emerged linux-firmware but it didn't do anything :/

Actually, my ethernet connection works and the driver seems OK.

```
Jelly ~ # lspci -vs 04:00.0

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 06)

   Subsystem: ASRock Incorporation Motherboard (one of many)

   Flags: bus master, fast devsel, latency 0, IRQ 45

   I/O ports at e800 [size=256]

   Memory at fbfff000 (64-bit, prefetchable) [size=4K]

   Memory at fbff8000 (64-bit, prefetchable) [size=16K]

   Capabilities: [40] Power Management version 3

   Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+

   Capabilities: [70] Express Endpoint, MSI 01

   Capabilities: [b0] MSI-X: Enable- Count=4 Masked-

   Capabilities: [d0] Vital Product Data

   Capabilities: [100] Advanced Error Reporting

   Capabilities: [140] Virtual Channel

   Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00

   Kernel driver in use: r8169
```

I just have this issue at boot time.

Edit. Maybe I'd be better finish configure properly my kernel before trying to speed up my boot time?

----------

## apinsard

I tried every rtl8168* firmwares in /lib/firmware/rtl_nic/ but none of them worked without r8169.

It seems that r8169 is the only right driver, but why do I have errors though it works? And above all, how can I get rid of them?

----------

## NeddySeagoon

apinsard,

r8169 is a kernel driver for a series of Realtek network interfaces.

The firmware helps it along.

You need both the r8169 and its firmware.  Many instances of r8169 work without the firmware. Yours and mine included.

What does 

```
emerge gentoo-sources -pv
```

show on your system?

----------

## apinsard

```
# emerge -pv gentoo-sources

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N     ] sys-kernel/gentoo-sources-3.8.1:3.8.1  USE="-build -deblob -symlink" 79 kB

Total: 1 package (1 new), Size of downloads: 79 kB
```

But I'm using vanilla-sources. So you might be more interested in the following I believe:

```
# emerge -pv vanilla-sources

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] sys-kernel/vanilla-sources-3.8.1:3.8.1  USE="deblob symlink -build" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB
```

I get a few more information in dmesg by enabling DEBUG_DRIVERS and DEBUG_DEVRES:

```
# dmesg|tail

[    4.744554] 0000:04:00.0: Missing Free firmware

[    4.744557] __allocate_fw_buf: fw-/*(DEBLOBBED)*/ buf=ffff880132420900

[    4.745040] device: '!*(DEBLOBBED)*!': device_add

[    4.745053] firmware !*(DEBLOBBED)*!: firmware: requesting /*(DEBLOBBED)*/

[    4.746276] fw_set_page_data: fw-/*(DEBLOBBED)*/ buf=ffff880132420900 data=          (null) size=0

[    4.746303] __fw_free_buf: fw-/*(DEBLOBBED)*/ buf=ffff880132420900 data=          (null) size=0

[    4.746307] r8169 0000:04:00.0 eth0: unable to load firmware patch /*(DEBLOBBED)*/ (-22)

[    4.759640] r8169 0000:04:00.0 eth0: link down

[    4.759832] ip (1902) used greatest stack depth: 2696 bytes left

[    6.545832] r8169 0000:04:00.0 eth0: link up
```

----------

## NeddySeagoon

apinsard,

Unless you really really want deblob, set USE=-deblob.

That will leave some firmware in the kernel.

Remerge your kernel, so you get the embedded firmware then rebuild your kernel starting with 

```
make clean
```

----------

## Jean-Paul

@apinsard, 

it seems we have the same NIC and maybe the same mainboard. Mine is an AsRock Z77 Pro4.

 *Quote:*   

> lspci -vs 04:00.0
> 
> 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 06)
> 
> 	Subsystem: ASRock Incorporation Motherboard (one of many)
> ...

 

and dmesg

 *Quote:*   

> dmesg|egrep r8169
> 
> [    1.653576] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> 
> [    1.653802] r8169 0000:04:00.0: irq 44 for MSI/MSI-X
> ...

 

Does your config really looks like this ?

 *Quote:*   

> (rtl_nic/rtl8168d-1.fw) External firmware blobs to build into the kernel binary
> 
> (/lib/firmware/) Firmware blobs root directory

 I mine, exactly like this?

If so, it should work.

Alternativly you can install r8168. 

 *Quote:*   

>  emerge net-misc/r8168

 

You have to switch off 

 *Quote:*   

> < >     Realtek 8169 gigabit ethernet support

 

This expected  *Quote:*   

> emerge @module-rebuild

  with each new kernel.

Jean-Paul

----------

## apinsard

Indeed, it solved the issue. But does this mean that I have non-free pieces now? I don't like having non-free software, matter of principle...

Just another question: What means this kind of lines in dmesg?

```
[    2.361778] kbd_mode (1162) used greatest stack depth: 5864 bytes left

[    2.373653] loadkeys (1163) used greatest stack depth: 5240 bytes left

[    2.374603] init-early.sh (1161) used greatest stack depth: 5016 bytes left

[    2.729523] blkid (1414) used greatest stack depth: 4904 bytes left

[    4.312236] runscript.sh (1629) used greatest stack depth: 4712 bytes left

[    4.805515] mount (1666) used greatest stack depth: 4552 bytes left

[    5.528345] ip (1899) used greatest stack depth: 2808 bytes left
```

Can I fix these warnings? Would it take me any benefit?

----------

## Jean-Paul

Yes, this means you have non-free software installed - just like nvidia   :Very Happy: 

 *apinsard wrote:*   

> What means this kind of lines in dmesg?

 

You've enabled debugging output in your kernel (CONFIG_DEBUG_STACK_USAGE)

Jean-Paul

----------

## apinsard

 *Jean-Paul wrote:*   

> Yes, this means you have non-free software installed - just like nvidia   

 

Nope, I use the "nouveau" driver.

 *Jean-Paul wrote:*   

> 
> 
>  *apinsard wrote:*   What means this kind of lines in dmesg? 
> 
> You've enabled debugging output in your kernel (CONFIG_DEBUG_STACK_USAGE)
> ...

 

Yep I just saw that. I think it is also due to CONFIG_FRAME_WARN = 2048

----------

## 666threesixes666

i hope you used JFS for your /boot, ext is painfully slow.  give systemd a whirl.  id say its about 8 times faster than openrc, and about 4/5ths as functional.  so long as your not running apache your good.

----------

## apinsard

 *666threesixes666 wrote:*   

> i hope you used JFS for your /boot, ext is painfully slow.  give systemd a whirl.  id say its about 8 times faster than openrc, and about 4/5ths as functional.  so long as your not running apache your good.

 

Nope, I use ext2.  Thanks, I will check JFS out.

----------

## Hu

 *666threesixes666 wrote:*   

> i hope you used JFS for your /boot, ext is painfully slow.  give systemd a whirl.  id say its about 8 times faster than openrc, and about 4/5ths as functional.  so long as your not running apache your good.

 Given how little /boot is used by most people, it seems highly unlikely that the choice of filesystem will matter much.  Citations on both the speed claim and the Apache reference would be welcome.

----------

## 666threesixes666

hu... http://en.gentoo-wiki.com/wiki/Systemd

notice no apache start script....  (if you dont need apache, systemd is extremely fast)

and as for JFS vs EXT

http://forums.anandtech.com/showthread.php?t=1144811

ext2 with out journal is faster, for large file writes, but not for fscking.  to fsck a journaled JFS tb drive takes around a minute, to fsck a ext(2,3,4) takes around an hour, and the file system starts to freak out once its excessively used.  XFS you can not use for a /boot drive, i use XFS as a /, but its being reverted back to JFS because of XFS's poor error handling.  needless to say EXT is not an option i refuse to use it.  i might go back to ext2 for more testing if they fix the fsck times.

----------

## dmpogo

 *666threesixes666 wrote:*   

> hu... http://en.gentoo-wiki.com/wiki/Systemd
> 
> notice no apache start script....  (if you dont need apache, systemd is extremely fast)
> 
> and as for JFS vs EXT
> ...

 

How are you even managing to corrupt /boot to need fsck on it ?  And I hope it is not a terabyte partition  :Smile: 

----------

## depontius

 *666threesixes666 wrote:*   

>   needless to say EXT is not an option i refuse to use it.

 

I don't think it's "needless to say".  Extraordinary claims require extraordinary evidence.  I've had satisfactory experience with EXT for over almost 2 decades, ext2, ext3, and now ext4.  In normal use my problems have been sufficiently small to not rise to notice, now.  I have had problems with "abnormal use", but I don't believe that counts.  Also based on sound advice, I'm using XFS for my MythTV partition, simply because of its different characteristics, and have been happy with that, as well.

Right now ext4 is the "default" filesystem, and to make such an accusation is pretty stern stuff.

----------

## mir3x

 *Quote:*   

>  give systemd a whirl. id say its about 8 times faster than openrc, and about 4/5ths as functional. so long as your not running apache your good.

 

is that joke?

I've just read that systemd is even slower ( http://solpeth.wordpress.com/2012/12/19/systemd-vs-openrc-on-gentoo-a-completely-non-technical-users-perspective/ )

So where's the truth? I really doubt if systemd can get any good significant boost boot time.

and whats a crappy test

 *Quote:*   

> 
> 
> and as for JFS vs EXT 
> 
> http://forums.anandtech.com/showthread.php?t=1144811
> ...

 

better search phoronix.com for proper test like this one http://www.phoronix.com/scan.php?page=article&item=ubuntu_1204_fs&num=1

----------

## py-ro

Systemd boots my notebook in 3s from grub, openrc needs 10s.

Booth to KDE-Desktop.

----------

## 666threesixes666

http://freedesktop.org/wiki/Software/systemd/Optimizations

i learned of systemd from personally knowing the HA clustering people @ linbit.com / drbd.org  i had taught linux from scratch to one of them approximately 4 years ago.  systemd is not industrial grade yet for gentoo, but you can still preview it.  arch full on requires systemd.  freedesktop does not lie like tinfoil hat wordpressers do.

"xfs boot time"

XFS: 12.40 seconds

xfs cannot be used as /boot, your website is invalid.  i say JFS from experience, not numbers....  BTRFS is untested from me yet, the HA clustering people will fill me in on it in a bit though.  as for the JFS though, ive punished it absurdly with power outages tons of media hoarding formats so on so forth and its definitely the absolute best linux file system ive found so far.  ive also not tested ZFS, tough that seems more of a raid storage type fs rather than a /boot & / fs

similar experience with systemd, 2 seconds instead of 20, but i serve apache periodically so im stuck to openrc for the moment.Last edited by 666threesixes666 on Wed Mar 13, 2013 6:59 pm; edited 1 time in total

----------

## The Doctor

Hmm... systemd literally killed my arch laptop install, so I would be extremely wary of it. After installing systemd on gentoo my boot time at least doubled.  Openrc takes about 2-3 seconds on my system once the process is handed off to init from my initramfs.

----------

## 666threesixes666

systemd is new and touchy.  i can get it to boot very well with a few exceptions, the 1 that is keeping me from going systemd only is apache.  i have to use GDM for gnome or else i lose menus.

----------

## mir3x

666threesixes666, with test I was only pointing out that test is probably inaccurate, cause tested disk had just 46MB/s  - so its some ancient disk, ( new magnetic disk have speed about 200 MB/s in hdparm ), and that test on phoronix is just one from many, deeper searching might indicate something more useful.

----------

## ryao

 *666threesixes666 wrote:*   

> http://freedesktop.org/wiki/Software/systemd/Optimizations
> 
> i learned of systemd from personally knowing the HA clustering people @ linbit.com / drbd.org  i had taught linux from scratch to one of them approximately 4 years ago.  systemd is not industrial grade yet for gentoo, but you can still preview it.  arch full on requires systemd.  freedesktop does not lie like tinfoil hat wordpressers do.
> 
> "xfs boot time"
> ...

 

ZFS is meant to replace all other forms of storage on your system. It will be fine for /. Currently, the only in-tree bootloader that supports /boot on ZFS is GRUB2. It is currently limited to supporting /boot on single disk and mirrored pools.

----------

## TomWij

Startup finished in 1099ms (kernel) + 1493ms (userspace) = 2592ms

Hello there, my laptop is close to the one second per phase goal (http://lwn.net/Articles/299483/) and can possible even be improved further; this has been optimized from a boot that used to take half a minute up to a minute, after I got to the low times systemd helped to cut the time in half.

First things first, you will want to start with optimizing the kernel; you can obtain the longest delays with `dmesg -d | sort -nk4` (see the bottom). It helps to put things as modules which will not make their initialization part of the actual kernel init, or in layman's term "they won't stall the kernel from handing over to userspace" (which we will want to happen in under a second). 

Next, you will want systemd (because it's faster by design due to the sockets and the primary focus on starting services in parallel, contrary to the subjective statements you will hear; if it takes too long you'll want to analyze it because there are some obvious services that hiccup, try `systemd-analyze blame` for at least a flat view of the longest delays. Also look into http://www.dedoimedo.com/computers/systemd-blame.html) and bootchart2 (to have a more detailed look into your boot, for further details enable the kernel parameter initcall_debug such that you will know how lang certain init calls take).

Please share us your output such that we can share a look as well, feel free to ask any questions; good luck.

PS: There's too much stuff you can do to leave in a single forum post or thread, maybe I should start a wiki article on it in the near future...

      I also don't want to advocate that systemd is better or worse than openrc, it just makes it easier to cut in time; with openrc you'd end up patching it to work like systemd does if you want to improve its time or parallel booting further (which is or has been off by default).

----------

## depontius

Now for a slightly different perspective on startup...

I run /home out of nfs, here at home.  They've done some windows-like stuff with gdm, to make it appear that the GUI is ready sooner, before the rest of the system.  In my case, that means that gdm makes it look like the system is ready for login.  However, flipping back to screen1 shows that things are really stalled at ntp-client, setting the time.  The nfs mounting happens after the time is set, so if you were to login right away, strange things happen.  I do have a local /home, for situations when nfs isn't up.  But if nfs comes up after login, it mounts over top of the local /home, so in particular you lose your xauth cookie and you can't do spit on your desktop, for instance.

----------

## Yamakuzure

<troll mode on>My laptop starts in under a second with openrc. Into KDE. I just open it. Wake up from hibernation rulez!</troll mode off>

Now seriously, why do people invest such a high amount of energy into something this unimportant like whether a computer starts up in 3, 5 or 10 seconds? Turn it on, go fetch a cup of coffee (or tea or whatever) and it's up when you are back. Does it matter whether your computer was idle for 5 or 10 seconds when you have your steaming mug on your desk?  :Wink: 

----------

## TomWij

 *Yamakuzure wrote:*   

> Now seriously, why do people invest such a high amount of energy into something this unimportant like whether a computer starts up in 3, 5 or 10 seconds? Turn it on, go fetch a cup of coffee (or tea or whatever) and it's up when you are back. Does it matter whether your computer was idle for 5 or 10 seconds when you have your steaming mug on your desk? 

 

Minimizing server downtime, being quickly up again in case of a power spike / unfortunate hardware or software event, mobile laptop users, there are a various amount of reasons...

Also, it's not a difference between 3 and 10 seconds; this thread is about bringing it down from nearly a minute or more.

But if you really want to go for a mug, then do so; but I don't have to go for that unnecessary mug, it's booted by the time I stand up! ^^Last edited by TomWij on Fri Mar 21, 2014 5:23 pm; edited 1 time in total

----------

## khayyam

 *TomWij wrote:*   

> Minimizing server downtime

 

TomWij ... I seem to remember this very same reason provided on the systemd mailing list ... and its complete nonsense. Firstly, if you care about availablity then your focus is entirely on predictable, dependency based, boot procedures that can be heuristicly tested. Secondly, a 3, 15, or 30, second saving in boot time is not worth sacrificing that predictablity for, as severs only need to reboot on few occasions (ie, kernel updates) and these occur during maintanance windows. So, shaving seconds off bootime is not something that is of any great consideration for systems admins, booting with some degree of certainty is.

I can't tell you the amount of times in the past year in which it has been said to me by managers that they are in process of migrating their farm from Linux to *BSD ... their reasons are many, but it basically boils down to dependability and future proofing. These people are not knee jerking, it cost them to do this, but from their perspective that cost is unavoidable, as, in the words of one particular services manager, "linux is becoming a joke".

Anyhow, thats probably the last I have to say about systemd, I'm just about through making any comment on the matter.

best ... khay

----------

## TomWij

 *khayyam wrote:*   

> ... then your focus is entirely on predictable, ...

 

Predictable in which way? That's just a word used out of context, it is unclear why this is mentioned here.

 *khayyam wrote:*   

> ..., dependency based, ...

 

Both are dependency based, not sure why you mention this.

 *Quote:*   

> ..., boot procedures that can be heuristicly tested.

 

If you can reboot much faster, you can test it at a higher rate; be more certain, ...

 *Quote:*   

> Secondly, a 3, 15, or 30, second saving in boot time is not worth sacrificing that predictablity for, ...

 

Which predictability?

 *Quote:*   

> ..., as severs only need to reboot on few occasions (ie, kernel updates) and these occur during maintanance windows.

 

You better do maintenance often than to delay it... That's also assuming everything goes perfect, which is not always the case; that doesn't take into account any unexpected events.

 *Quote:*   

> So, shaving seconds off bootime is not something that is of any great consideration for systems admins, booting with some degree of certainty is.

 

What exactly makes one approach of booting less certain than another? This argumentation is moot.

 *Quote:*   

> I can't tell you the amount of times in the past year in which it has been said to me by managers that they are in process of migrating their farm from Linux to *BSD ... their reasons are many, but it basically boils down to dependability and future proofing. These people are not knee jerking, it cost them to do this, but from their perspective that cost is unavoidable, as, in the words of one particular services manager, "linux is becoming a joke".

 

That's just their thoughts, in the end they may just be wasting a lot of money for no real benefit; these marketing words are becoming a joke.

 *Quote:*   

> Anyhow, thats probably the last I have to say about systemd, I'm just about through making any comment on the matter.

 

Oh, you were talking about systemd? It rather appears you were doing a marketing talk on boot times. None of what you said applies to systemd in specific, anyhow....

 *Quote:*   

> best ... khay

 

Ah, "best", a subjective adjective!

----------

## khayyam

 *TomWij wrote:*   

>  *khayyam wrote:*   ... then your focus is entirely on predictable, ... 
> 
> Predictable in which way? That's just a word used out of context, it is unclear why this is mentioned here.

 

TomWij ... A => B => C ... counter posed to "aggressive parallelization" which is causally unpredictable.

 *TomWij wrote:*   

>  *khayyam wrote:*   ..., dependency based, ... 
> 
> Both are dependency based, not sure why you mention this.

 

A,B,C => D is not a causal chain ... even if you fix this after the fact with a little fairy dust. 

 *TomWij wrote:*   

>  *khayyam wrote:*   ..., boot procedures that can be heuristically tested. 
> 
> If you can reboot much faster, you can test it at a higher rate; be more certain, ...

 

That is complete nonsense ... 

 *TomWij wrote:*   

>  *khayyam wrote:*   Secondly, a 3, 15, or 30, second saving in boot time is not worth sacrificing that predictability for, ... 
> 
> Which predictability?

 

Causal predictability, which is sequential and not parallel ... which, again, can "with some degree of certainty" be heuristically tested.

 *TomWij wrote:*   

>  *khayyam wrote:*   ..., as severs only need to reboot on few occasions (ie, kernel updates) and these occur during maintenance windows. 
> 
> You better do maintenance often than to delay it... That's also assuming everything goes perfect, which is not always the case; that doesn't take into account any unexpected events.

 

Good advice ... but nothing to do with my points above. There may be earthquakes, invasions from mars, and other unseen factors ... but like shaving seconds of boot times they are not something that are factored in re availability. The main consideration would be dependability, which can, to some degree, be factored.  

 *TomWij wrote:*   

>  *khayyam wrote:*   So, shaving seconds off bootime is not something that is of any great consideration for systems admins, booting with some degree of certainty is. 
> 
> What exactly makes one approach of booting less certain than another? This argumentation is moot.

 

See above ... if each causal step must be successful to reach the final outcome then there is some guarantee that that having happened it can be reproduced, if you parallelise this process then there are no guarantees ... even with a liberal sprinkling of magic fairy dust. 

 *TomWij wrote:*   

>  *Quote:*   I can't tell you the amount of times in the past year in which it has been said to me by managers that they are in process of migrating their farm from Linux to *BSD ... their reasons are many, but it basically boils down to dependability and future proofing. These people are not knee jerking, it cost them to do this, but from their perspective that cost is unavoidable, as, in the words of one particular services manager, "linux is becoming a joke". 
> 
> That's just their thoughts, in the end they may just be wasting a lot of money for no real benefit; these marketing words are becoming a joke.

 

It has nothing to do with marketing ...  

 *TomWij wrote:*   

>  *khayyam wrote:*   Anyhow, that's probably the last I have to say about systemd, I'm just about through making any comment on the matter. 
> 
> Oh, you were talking about systemd? It rather appears you were doing a marketing talk on boot times. None of what you said applies to systemd in specific, anyhow....

 

Who'd have thunk it ... considering the subject line of the thread ... and the fact that systemd is mentioned in the very first line of my post. None the less don't let that get in the way of your being condescending.

 *TomWij wrote:*   

>  *khayyam wrote:*   best ... khay 
> 
> Ah, "best", a subjective adjective!

 

pffff ... khay

----------

## TomWij

 *khayyam wrote:*   

> TomWij ... A => B => C ... counter posed to "aggressive parallelization" which is causally unpredictable.

 

Unpredictable with regard to which context?

 *khayyam wrote:*   

> A,B,C => D is not a causal chain ... even if you fix this after the fact with a little fairy dust.

 

Causal chains also sound like fairy dust theory to me, without context this is unclear.

 *khayyam wrote:*   

> That is complete nonsense ...

 

Why is that so?

 *khayyam wrote:*   

> Causal predictability, which is sequential and not parallel ... which, again, can "with some degree of certainty" be heuristically tested.

 

This says little about the parallel approach, and "some degree" is vague on its own.

 *khayyam wrote:*   

> Good advice ... but nothing to do with my points above. There may be earthquakes, invasions from mars, and other unseen factors ...

 

Yet you choose to focus on the extreme cases and not on the common ones, that's denying their existence.

 *khayyam wrote:*   

> but like shaving seconds of boot times they are not something that are factored in re availability. The main consideration would be dependability, which can, to some degree, be factored.

 

Dependability is an useless factor if no workstation in your company is available. Oh man, gotta drink another coffee because those computers take so long to boot (true story, I see this happen regularly at school and companies), let me remind you that the topic is about bringing it down from longer times. If you optimize this for a whole company you spare out a lot of lost time, coffee, ...

 *khayyam wrote:*   

> See above ... if each causal step must be successful to reach the final outcome then there is some guarantee that that having happened it can be reproduced, if you parallelise this process then there are no guarantees ... even with a liberal sprinkling of magic fairy dust.

 

You may want to explain this weird belief into some more detail instead of referring to fairy dust.

 *khayyam wrote:*   

> It has nothing to do with marketing ...

 

"Future proof your servers now with dependability and magic fairy dust!!!111oneoneeleventyone..."

http://www.freebsd.org/marketing/ is all about marketing whereas http://www.gnu.org/philosophy/ is all about philosophy, it's just a matter of choosing the right words to explain the matter...

 *khayyam wrote:*   

> Who'd have thunk it ... considering the subject line of the thread ... and the fact that systemd is mentioned in the very first line of my post. None the less don't let that get in the way of your being condescending.

 

Words are pulled out of their context and statements aren't backed up with that context, there are also mentions of magic fairy dust which are vague and thus lack detail. Because you don't get your point across you start to call me condescending, and try to bring systemd into this support discussion whereas we're not even talking about it; reconsider what you're telling me and base it on facts, avoid inserting these kind of things in a thread where users are looking for actual practical help.Last edited by TomWij on Fri Mar 21, 2014 5:30 pm; edited 2 times in total

----------

## Yamakuzure

 *TomWij wrote:*   

> Minimizing server downtime

 This is a very evil joke, that one.

What kind of servers? IBM? Dell? HP? Any of those that use SCSI RAID controllers that in themselves easily need thrice the time to fire up their raids than a normal user desktop needs for a cold boot? Some providing NTP, or attaching iSCSI NAS shares - those do need even longer.

And then there are insane uptimes anyway. Reboot is such a seldom need in the serverworld. (See http://www.uptimeprj.com/ for example)

This argument is invalid. But before you rip my head off, "Bringing it down from a minute or more" for user systems is, of course, a damn good reason! I never thought of that, as I never had such long boot times on my current machines...

----------

## TomWij

 *Yamakuzure wrote:*   

> What kind of servers? IBM? Dell? HP? Any of those that use SCSI RAID controllers that in themselves easily need thrice the time to fire up their raids than a normal user desktop needs for a cold boot? Some providing NTP, or attaching iSCSI NAS shares - those do need even longer.

 

Some servers indeed have longer boot times than users, which makes it harder to minimize downtime; therefore you need harder approaches to get it down (eg. parallel).

 *Yamakuzure wrote:*   

> And then there are insane uptimes anyway. Reboot is such a seldom need in the serverworld. (See http://www.uptimeprj.com/ for example)

 

That site seems to focus on the maximum and ignores the rest, it doesn't show a distribution of uptimes either; so this resource is not relevant when the topic is about minimal downtimes.

Edit: The site seems to have ... changed ... where did they go?

 *Yamakuzure wrote:*   

> This argument is invalid.

 

Because you state so?  :Very Happy: Last edited by TomWij on Fri Mar 21, 2014 5:26 pm; edited 1 time in total

----------

## Thistled

Oh what a surprise!

Khayyam is ripping posts again.   :Rolling Eyes: 

C'mon, give it a break man. You need a holiday.

You are too aggressive on these forums.

 :Exclamation: 

----------

