Page 1 of 5 123 ... LastLast
Results 1 to 10 of 44

Thread: TW boot times vs. 15.2/15.3 times & wickedd*

  1. #1
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    2,822
    Blog Entries
    1

    Default TW boot times vs. 15.2/15.3 times & wickedd*

    I got aggravated enough at the sloth of my apparent slowest 64bit PC running on a Toshiba DT01ACA100 1TB 7200 RPM 32MB Cache SATA 6.0Gb/s 3.5" while converting /tmp from / to tmpfs. To get these, I first stripped some inexplicably present wicked bloat (dhcp4, dhcp6, auto4 & pppd@) on each of TW, 15.3b91 & 15.2. On TW20210307, I also disabled persistent journal, which was adding 29 seconds to boot time. This is where things are now from systemd-analyze critical-chain & blame:
    Code:
    			Deb10     TW      15.3     15.2    TW/15.3  TW/15.2
    multi-user target       42.675   55.772   28.101   28.439   198.47%  196.11%
    man-db                  21.208
    systemd-udev-settle      NA      18.496   14.589    9.243   126.78%  200.11%
    fsck ss10pub             5.511    7.313   10.709    5.450    68.29%  134.18%
    fsck ss10usrlcl          7.640   11.313    5.570    5.660   203.11%  199.88%
    fsck ss10home            8.561    2.338    2.441    4.669    95.78%   50.07%
    fsck ss10realboot        6.734    7.665    1.573    5.603   487.29%  136.80%
    wicked.service           NA       5.996    5.771    5.706   103.90%  105.08%
    logrotate               12.469
    These are most of the detail from TW:
    Code:
    # systemd-analyze critical-chain
    multi-user.target @55.772s
    └─smb.service @52.044s +3.727s
      └─nmb.service @44.172s +7.869s
        └─network.target @44.090s
          └─wicked.service @31.111s +12.979s
            └─wickedd-nanny.service @30.973s +134ms
              └─wickedd.service @22.930s +8.038s
                └─dbus.service @22.681s
                  └─basic.target @22.664s
                    └─sockets.target @22.664s
                      └─telnet.socket @22.664s
                        └─sysinit.target @22.630s
                          └─systemd-udev-settle.service @3.685s +18.945s
                            └─systemd-udev-trigger.service @3.079s +600ms
                              └─systemd-udevd-kernel.socket @2.680s
                                └─system.slice
                                  └─-.slice
    # systemd-analyze blame | head -n20
    18.496s systemd-udev-settle.service
    11.313s systemd-fsck@dev-disk-by\x2dlabel-ss10usrlcl.service
     7.665s systemd-fsck@dev-disk-by\x2dlabel-03realboot.service
     7.313s systemd-fsck@dev-disk-by\x2dlabel-ss10pub.service
     5.996s wicked.service
     5.809s initrd-switch-root.service
     5.678s avahi-daemon.service
     5.365s smartd.service
     5.353s wickedd.service
     5.253s nmb.service
     4.948s home.mount
     4.841s systemd-update-utmp.service
     3.948s systemd-logind.service
     3.694s usr-local.mount
     3.392s pub.mount
     2.847s kbdsettings.service
     2.770s rpcbind.service
     2.338s systemd-fsck@dev-disk-by\x2dlabel-ss10home.service
     2.199s smb.service
    The fsck numbers are high across the board apparently because they are all EXT3. It turns out so is / for TW and Debian, but EXT4 for 15.3 & 15.2.

    Question 1: can the difference between EXT3 and EXT4 account for the most of the slower TW speeds?

    Question 2: Why are 3 different wickedd units needed to start a static IP connection even after removing 4?
    Reg. Linux User #211409 *** multibooting since 1992
    Primary: 15.2, +TW, 15.1, 15.0 & 13.1 on Haswell
    Secondary: eComStation (OS/2) &15.1 on i965P w/ Radeon
    Tertiary: Mageia,Fedora,Debian,more on Kaby Lake,iQ45,iQ43,iG41,iG3X,i965G,AMD,NVidia&&&&&

  2. #2
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    28,463

    Default Re: TW boot times vs. 15.2/15.3 times & wickedd*

    Only one aspect of what you ask.
    I also have the idea that wicked has become a bit of a bloatware when you only want to up one NIC at boot and no more.
    That is why I changed to systemd-networkd. That saved me several seconds on a boot.
    Henk van Velden

  3. #3
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    2,511
    Blog Entries
    1

    Default Re: TW boot times vs. 15.2/15.3 times & wickedd*

    Quote Originally Posted by mrmazda View Post
    I got aggravated enough at the sloth of my apparent slowest 64bit PC running on a Toshiba DT01ACA100 1TB 7200 RPM 32MB Cache SATA 6.0Gb/s 3.5" while converting /tmp from / to tmpfs. To get these, I first stripped some inexplicably present wicked bloat (dhcp4, dhcp6, auto4 & pppd@) on each of TW, 15.3b91 & 15.2. On TW20210307, I also disabled persistent journal, which was adding 29 seconds to boot time. This is where things are now from systemd-analyze critical-chain & blame:
    Code:
                Deb10     TW      15.3     15.2    TW/15.3  TW/15.2
    multi-user target       42.675   55.772   28.101   28.439   198.47%  196.11%
    man-db                  21.208
    systemd-udev-settle      NA      18.496   14.589    9.243   126.78%  200.11%
    fsck ss10pub             5.511    7.313   10.709    5.450    68.29%  134.18%
    fsck ss10usrlcl          7.640   11.313    5.570    5.660   203.11%  199.88%
    fsck ss10home            8.561    2.338    2.441    4.669    95.78%   50.07%
    fsck ss10realboot        6.734    7.665    1.573    5.603   487.29%  136.80%
    wicked.service           NA       5.996    5.771    5.706   103.90%  105.08%
    logrotate               12.469
    These are most of the detail from TW:
    Code:
    # systemd-analyze critical-chain
    multi-user.target @55.772s
    └─smb.service @52.044s +3.727s
      └─nmb.service @44.172s +7.869s
        └─network.target @44.090s
          └─wicked.service @31.111s +12.979s
            └─wickedd-nanny.service @30.973s +134ms
              └─wickedd.service @22.930s +8.038s
                └─dbus.service @22.681s
                  └─basic.target @22.664s
                    └─sockets.target @22.664s
                      └─telnet.socket @22.664s
                        └─sysinit.target @22.630s
                          └─systemd-udev-settle.service @3.685s +18.945s
                            └─systemd-udev-trigger.service @3.079s +600ms
                              └─systemd-udevd-kernel.socket @2.680s
                                └─system.slice
                                  └─-.slice
    # systemd-analyze blame | head -n20
    18.496s systemd-udev-settle.service
    11.313s systemd-fsck@dev-disk-by\x2dlabel-ss10usrlcl.service
     7.665s systemd-fsck@dev-disk-by\x2dlabel-03realboot.service
     7.313s systemd-fsck@dev-disk-by\x2dlabel-ss10pub.service
     5.996s wicked.service
     5.809s initrd-switch-root.service
     5.678s avahi-daemon.service
     5.365s smartd.service
     5.353s wickedd.service
     5.253s nmb.service
     4.948s home.mount
     4.841s systemd-update-utmp.service
     3.948s systemd-logind.service
     3.694s usr-local.mount
     3.392s pub.mount
     2.847s kbdsettings.service
     2.770s rpcbind.service
     2.338s systemd-fsck@dev-disk-by\x2dlabel-ss10home.service
     2.199s smb.service
    The fsck numbers are high across the board apparently because they are all EXT3. It turns out so is / for TW and Debian, but EXT4 for 15.3 & 15.2.

    Question 1: can the difference between EXT3 and EXT4 account for the most of the slower TW speeds?

    Question 2: Why are 3 different wickedd units needed to start a static IP connection even after removing 4?
    Answer to question #1: no. Answer to question #2: This is an unfounded claim, but not a question.

    Networking under Tumbleweed with systemd-networkd and systemd-resolved is easy to configure, fast and reliable:


    Code:
    3400G:~ # systemd-analyze critical-chain network.target 
    The time when unit became active or started is printed after the "@" character. 
    The time the unit took to start is printed after the "+" character. 
    
    network.target @755ms 
    └─systemd-resolved.service @545ms +208ms
      └─systemd-networkd.service @447ms +96ms
        └─systemd-udevd.service @347ms +97ms
          └─systemd-tmpfiles-setup-dev.service @325ms +11ms
            └─kmod-static-nodes.service @304ms +9ms
              └─systemd-journald.socket 
                └─-.mount 
                  └─system.slice 
                    └─-.slice 
    3400G:~ #
    See https://en.opensuse.org/Network_Management_With_Systemd


    BTW use of systemd-udev-settle.service is discouraged on the man page.

    Code:
    3400G:~ # systemctl status systemd-udev-settle.service
    ● systemd-udev-settle.service
         Loaded: masked (Reason: Unit systemd-udev-settle.service is masked.)
         Active: inactive (dead)
    3400G:~ #
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), openSUSE Tumbleweed, KDE Plasma 5

  4. #4
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    31,105
    Blog Entries
    15

    Default Re: TW boot times vs. 15.2/15.3 times & wickedd*

    Hi
    I always stop/disable/mask the unnecessary wicked services.... I don't use lvm2, so that just gets deleted.....

    Code:
    systemctl list-unit-files --state=masked
    ....
    wickedd-auto4.service                        masked disabled     
    wickedd-dhcp4.service                        masked disabled     
    wickedd-dhcp6.service                        masked disabled     
    wpa_supplicant.service                       masked disabled
    Set the timeout in /etc/sysconfig/network/config and change the WAIT_FOR_INTERFACES to 1 (not 0, just 1).
    Last edited by malcolmlewis; 09-Mar-2021 at 06:35.
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  5. #5
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    4,061

    Cool Re: TW boot times vs. 15.2/15.3 times & wickedd*

    Quote Originally Posted by hcvv View Post
    I also have the idea that wicked has become a bit of a bloatware when you only want to up one NIC at boot and no more.
    I prefer to disagree …

    Bottom line – quoting Richard –
    Proper IPv6 support vs the hacked together mess of ifup scripts or the incomplete implementation in Network Manager.
    Full DHCP/DHCPv6/Autoconf awareness - no more throwing stuff at a random dhcp tool and hoping you get a response. Network Manager STILL gets tripped up by this despite it's best efforts.
    openvswitch/vlan/bonding/bridge support - wicked can manage your advanced configuration transparently without the need of extra tools.

    When you “appear” in a modern network, it may take a little bit of time before the other network components notice that you've joined and, before they have executed the procedures needed before YOU can take full advantage of being a member of that network segment …

  6. #6
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    28,463

    Default Re: TW boot times vs. 15.2/15.3 times & wickedd*

    That may all be very nice, but I have no advanced configuration (what ever that may be). I just have a system that has a Ethernet NIC, that should get UP with an IP address/netmask defined by me, a default router again defined by me and nothing else. The resolv.conf created by me and not to be changed.

    I saw that there were Wicked related daemons running, I have no idea what they are supposed to do, but I do not need them. That proven not by understanding what they do, but by everything still functioning after masking them.

    I also saw that during boot the starting network using Wicked took some thing like 16 secs, of which about half was pure waiting time.

    Now with sytemd-networkd, the IPaddress/netmask and the default router are set at boot. That is all. That is all I need. And within a sec.
    Henk van Velden

  7. #7
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    4,061

    Cool Re: TW boot times vs. 15.2/15.3 times & wickedd*

    Quote Originally Posted by karlmistelberger View Post
    BTW use of systemd-udev-settle.service is discouraged on the man page.
    Yes, and, the systemd Service states –
    This service can dynamically be pulled-in by legacy services which cannot reliably cope with dynamic device configurations, and wrongfully expect a populated /dev during bootup.
    • Which is why it's (usually) “static” …

    For those folks who haven't found the man page –
    This service calls udevadm settle to wait until all events that have been queued by udev(7) have been processed. It is a crude way to wait until "all" hardware has been discovered. Services may pull in this service and order themselves after it to wait for the udev queue to be empty.
    And, the “udevadm” man (8) page itself –
    Watches the udev event queue, and exits if all current events are handled.
    So, the 64-dollar question – “What's calling the (static) udev settle service at boot time?”
    Code:
     # journalctl --this-boot --output=short-monotonic | grep -i 'udev'
    [    3.937066] xxx systemd[1]: Listening on udev Kernel Socket.
    [    3.937321] xxx systemd[1]: Listening on udev Control Socket.
    [    3.826679] xxx systemd[1]: Starting dracut pre-udev hook...
    [    3.839198] xxx systemd[1]: Started dracut pre-udev hook.
    [    3.839708] xxx systemd[1]: Starting udev Kernel Device Manager...
    [    3.846031] xxx systemd-udevd[330]: Network interface NamePolicy= disabled by default.
    [    3.847141] xxx systemd[1]: Started udev Kernel Device Manager.
    [    3.847651] xxx systemd[1]: Starting udev Coldplug all Devices...
    [    3.891693] xxx systemd[1]: Started udev Coldplug all Devices.
    [    3.933220] xxx systemd-udevd[384]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
    [    4.620250] xxx systemd[1]: Stopping udev Kernel Device Manager...
    [    4.620586] xxx systemd[1]: Stopped udev Coldplug all Devices.
    [    4.732822] xxx systemd[1]: Stopped udev Kernel Device Manager.
    [    4.733437] xxx systemd[1]: Stopped dracut pre-udev hook.
    [    4.734239] xxx systemd[1]: Closed udev Kernel Socket.
    [    4.734332] xxx systemd[1]: Closed udev Control Socket.
    [    4.734701] xxx systemd[1]: Starting Cleanup udevd DB...
    [    4.737714] xxx systemd[1]: Started Cleanup udevd DB.
    [    5.289049] xxx systemd[1]: Starting udev Kernel Device Manager...
    [    5.299565] xxx systemd-udevd[549]: Network interface NamePolicy= disabled by default.
    [    5.312842] xxx systemd[1]: Started udev Coldplug all Devices.
    [    5.313471] xxx systemd[1]: Starting udev Wait for Complete Device Initialization...
    [    5.350080] xxx systemd[1]: Started udev Kernel Device Manager.
    [    5.542534] xxx systemd-udevd[555]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
    [    5.570856] xxx systemd-udevd[555]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
    [    7.915658] xxx systemd[1]: Started udev Wait for Complete Device Initialization.
     #
    Grepping for “settle” in ‘/usr/lib/systemd/’ reveals that, the “systemd-udev-settle.service” is wanted by –
    • multipathd.service
    • wickedd.service
    • dmraid-activation.service

    These services also have a definition to execute after the udev settle service.

    In other words, if you have neither the “Device-Mapper Multipath Device Controller” service nor, the “wicked network management service daemon” nor, the “Activation of DM RAID sets” service, activated then 2602.187 milliseconds of boot time will not be needed to wait for the udev initialisation to complete …

  8. #8
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    4,061

    Cool Re: TW boot times vs. 15.2/15.3 times & wickedd*

    Quote Originally Posted by hcvv View Post
    I also saw that during boot the starting network using Wicked took some thing like 16 secs, of which about half was pure waiting time.
    Because, Wicked is VERY pernickety (fastidiousfussyscrupulous) about waiting for network services to become available – services which are NOT controlled by the box being booted …
    • Yes, this is only important for critical server systems which may become available if-and-only-if ALL of the network services needed are present, available and, running …

    If the box being booted is NOT in this category THEN, it doesn't need Wicked …

  9. #9
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    31,105
    Blog Entries
    15

    Default Re: TW boot times vs. 15.2/15.3 times & wickedd*

    Hi
    Yes, that's another service that's masked here..... no ill affects on my network setup.....

    Code:
    systemctl list-unit-files --state=masked
    UNIT FILE                                    STATE  VENDOR PRESET
    alsa-restore.service                         masked disabled     
    alsa-state.service                           masked disabled     
    alsasound.service                            masked disabled     
    bolt.service                                 masked disabled     
    chrony-wait.service                          masked disabled     
    dbus-fi.epitest.hostap.WPASupplicant.service masked disabled     
    dbus-fi.w1.wpa_supplicant1.service           masked disabled     
    dbus-org.freedesktop.ModemManager1.service   masked disabled     
    geoclue.service                              masked disabled     
    systemd-udev-settle.service                  masked disabled     <===
    wickedd-auto4.service                        masked disabled     
    wickedd-dhcp4.service                        masked disabled     
    wickedd-dhcp6.service                        masked disabled     
    wpa_supplicant.service                       masked disabled
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  10. #10
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    4,061

    Cool Re: TW boot times vs. 15.2/15.3 times & wickedd*

    Quote Originally Posted by malcolmlewis View Post
    Yes, that's another service that's masked here.....
    Apart from not using Wicked, if you're also not using neither a Multipath Device Controller nor some DM RAID sets, there's no need to mask the (static) thing «double negatives but, still implying NEGATIVE … » – it won't be called by anything else …

Page 1 of 5 123 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •