muss es network-manager sein?

Bei mir läuft netctl. netctl-auto auf's WLAN hält den Boot überhaupt nicht auf, weil netctl-auto nicht zwingend vor'm Login fertig sein will. Dafür hast du dann halt in der ersten Sekunde vielleicht kein WLAN, bis netctl mit dem Router fertig gesprochen hat, aber bis du anfängst, Programme zu starten, die Netzwerk brauchen, dürfte das auch gegessen sein (so ist's bei mir).

@Ovion

theoretisch nicht unbedingt, sollte halt schon vernünftig mit der gnome-shell zusammen arbeiten, sprich über die gnome-shell steuerbar sein, geht das denn mit nem anderen tool?

Gruß,
Marcel

Keine Ahnung, nutze keine Gnome-Shell.

hobbypunk schrieb@Ovion

theoretisch nicht unbedingt, sollte halt schon vernünftig mit der gnome-shell zusammen arbeiten, sprich über die gnome-shell steuerbar sein, geht das denn mit nem anderen tool?

Gruß,
Marcel

Eher schlecht. Zumindest nicht schoen integriert, wie es der networkmanager tut.

0.03 Sekunden fällt definitiv unter Messungenauigkeit. 😃

Cresh all schrieb0.03 Sekunden fällt definitiv unter Messungenauigkeit. 😃

tja, ein paar clockticks mehr oder weniger...^^

brikler schrieb ob noch ein größerer zeitgewinn drin wäre, wenn ich die hooks in der mkinitcpio.conf reduzieren würde?
im moment schauts nämlich so aus

HOOKS="base udev keymap autodetect modconf block keyboard resume filesystems fsck"

jugend forscht, so schauts bei mir aus:

hooks="base udev resume filesystem" keine module                

COMPRESSOR="cat"                         
Startup finished in 1.356s (kernel) + 418ms (userspace) = 1.774s

COMPRESSOR="gzip"
Startup finished in 1.328s (kernel) + 374ms (userspace) = 1.702s

COMPRESSOR="lz4"                 
Startup finished in 1.364s (kernel) + 377ms (userspace) = 1.741s

Also doch nur eher im psychologischen Bereich 🙂

brikler schriebsystemd kommt aus dem tritt wenn man keinen swap in der fstab hat.

Dann lass swap doch einfach ganz normal über die fstab aktiviert, tut ja nicht weh.

Dirk schrieb

brikler schriebsystemd kommt aus dem tritt wenn man keinen swap in der fstab hat.

Dann lass swap doch einfach ganz normal über die fstab aktiviert, tut ja nicht weh.

tat ich schon...wahrscheinlich probier ichs mit upower^^

ein neuer versuch, dieses mal mit dem super tollen bfq scheduler...

Startup finished in 1.268s (kernel) + 1.688s (userspace) = 2.956s

Zwar schon ein etwas ältere Thread, aber was solls......

systemd-analyze

Startup finished in 886ms (kernel) + 374ms (userspace) = 1.260s

systemd-analyze blame

           130ms dev-sda2.device
           100ms NetworkManager.service
            98ms alsa-restore.service
            74ms systemd-logind.service
            65ms systemd-user-sessions.service
            35ms systemd-vconsole-setup.service
            32ms udisks2.service
            25ms polkit.service
            24ms systemd-timesyncd.service
            21ms systemd-fsck@dev-sdb1.service
            19ms colord.service
            19ms systemd-journald.service
            17ms systemd-udev-trigger.service
            17ms systemd-fsck@dev-sda3.service
            16ms user@1000.service
            13ms wpa_supplicant.service
            12ms systemd-udevd.service
            12ms home.mount
            11ms systemd-sysctl.service
            10ms kmod-static-nodes.service
            10ms daten.mount
             9ms dev-hugepages.mount
             9ms dev-mqueue.mount
             9ms dev-sdb2.swap
             7ms sys-kernel-config.mount
             7ms systemd-tmpfiles-setup-dev.service
             5ms systemd-tmpfiles-clean.service
             5ms systemd-journal-flush.service
             4ms sys-kernel-debug.mount
             4ms systemd-remount-fs.service
             4ms systemd-tmpfiles-setup.service
             3ms systemd-update-utmp.service
             3ms sys-fs-fuse-connections.mount
             3ms systemd-random-seed.service
             1ms systemd-rfkill@rfkill0.service
             1ms tmp.mount

Slim + Openbox + i5 CPU + Samsung 850Pro SSD

 Startup finished in 4.325s (firmware) + 1.231s (loader) + 1.508s (kernel) + 497ms (userspace) = 6.562s

    graphical.target @497ms
└─upower.service @411ms +85ms
  └─basic.target @360ms
    └─sockets.target @360ms
      └─dbus.socket @360ms
        └─sysinit.target @360ms
          └─systemd-timesyncd.service @320ms +39ms
            └─systemd-tmpfiles-setup.service @310ms +5ms
              └─local-fs.target @310ms
                └─boot.mount @294ms +14ms

upower.service hält den ganzen betrieb auf....kann man da was machen?

@LessWire

console-getty.service                       disabled 
container-getty@.service                    static   
getty@.service                              disabled 
serial-getty@.service                       disabled 
getty.target 

ich komm ganz gut ohne getty@.service aus 🙂

@brikler:
Klar, disable, was man nicht braucht.

Wahrscheinlich sind mittlerweile unsere systemd configs so unterschiedlich, daß man kaum noch pauschale Tipps geben kann.

Ich nutze "graphical target" nicht und starte lieber über tty1 direkt in w3-wm - die Oberfläche steht dann mit einigen Programmen bereits zum Arbeiten bereit, obwohl Wlan und einige andere Dienste im Hintergrund noch hochgefahren werden. Gerade WLAN (wpa_supplicant) ist eine ziemliche Bremse. Sofort das Netz benötigende Services müssen dann natürlich auch etwas angepasst werden - aber mir gefällt's so gut. Wie gesagt, sehr individuell das Ganze und nicht jedermanns Sache - aber freaks, wie wir halt mal sind... ... 🙂

LessWire schrieb@brikler:
Klar, disable, was man nicht braucht.

Wahrscheinlich sind mittlerweile unsere systemd configs so unterschiedlich, daß man kaum noch pauschale Tipps geben kann.

pauschaler tipp: ausschalten was geht...das spart zeit, aber nicht ausführungszeit...

Improve a couple of algorithms in the unit dependency graph calculation logic, as well as unit file loading. For example, right now when loading units we match them up with a subset of the other loaded units in order to add automatic dependencies between them where appropriate. Usually the set of units matched up is small, but the complexity is currently O(n^2), and this could be optimized. Since unit file loading and calculations in the dependency graphs is the only major, synchronous, computation-intensive bit of PID 1, and is executed before any services are started this should bring relevant improvements, especially on systems with big dependency graphs.

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

im übrigen kostet mich der getty@service kaum zeit, ich hab die NAutoVTs=2 .... aber mal sehen, vielleicht findet sich noch was 😃