You are not logged in.
Sanity Check, please.
I've been given an old computer, with no guarantee that it will work.
I have tested the memory (24-hr Memtest) and installed new solid-state drives. I've also run all the manufacturer's diagnostic tests. Everything passes.
However, boot times seem unusually long and the entire system 'feels' sluggish.
I am reading about ways to improve performance, but I'm looking for some sort of sanity check.
Is my system already performing as expected and I'm facing the limitations of old hardware? Or is there something seriously wrong with my install?
So far, I have only 1 user (root) with no WM, DM, or graphical environment. I am using (2) 500 GB SSDs mirrored as RAID1 with mdadm.
Cheers,
Metrics
Boot time: 45-50 sec# time mkinitcpio -P linux [for both linux, linux-lts]
real 1m28.558sSystem
users: root
wm: none
dm: none
de: none
chassis: Dell, Precision T7820
Manufacturer: Dell
Product: Precision 7820 Tower
bios: version: 2.6.3
Release Date: 05/04/2020
cpu: Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz
cores: 12
threads: 24
ram: 32 GB
Manufacturer: Hynix
Form Factor: DIMM
Type: DDR4
Speed: 2666 MT/s
Size: 8 GB
SSD: 500 GB
Manufacturer: Crucial
Model: CT500MX500SSD1
RAID1: mirrored, using mdadm# pacman -Qe
base 3-2
base-devel 1-1
dhcpcd 10.0.6-1
dmidecode 3.5-1
efibootmgr 18-2
intel-ucode 20231114-2
linux 6.7.3.arch1-1
linux-firmware 20240115.9b6d0b08-2
man-db 2.12.0-1
man-pages 6.05.01-2
mdadm 4.2-2
ncdu 2.3-1
sudo 1.9.15.p5-1
terminus-font 4.49.1-6
tmux 3.3_a-7
usbutils 017-1
vim 9.1.0000-1# systemd-analyze
Startup finished in 18.245s (firmware) + 4.005s (loader) + 15.466s (kernel) + 6.332s (userspace) = 44.050s
graphical.target reached after 6.330s in userspace.# systemd-analyze critical-chain
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.
graphical.target @6.330s
└─multi-user.target @6.328s
└─getty.target @6.326s
└─getty@tty1.service @6.317s
└─systemd-user-sessions.service @6.277s +29ms
└─network.target @6.205s
└─dhcpcd@enp0s31f6.service @2.400s +3.802s
└─basic.target @2.393s
└─dbus-broker.service @2.357s +28ms
└─dbus.socket @2.318s
└─sysinit.target @2.300s
└─systemd-update-utmp.service @2.257s +40ms
└─systemd-tmpfiles-setup.service @2.037s +183ms
└─local-fs.target @1.953s
└─home.mount @1.847s +89ms
└─systemd-fsck@dev-disk-by\x2duuid-31678818\x2d37d7\x2d4937\x2da278\x2dca8f6cf65c7b.service @1.653s +107ms
└─dev-disk-by\x2duuid-31678818\x2d37d7\x2d4937\x2da278\x2dca8f6cf65c7b.device @1.544s# lsblk --fs
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
md125 vfat FAT32 array0 2451-07E9 841.9M 18% /boot
├─sda1 linux_raid_member 1.0 daphne:array0 ed63ec4d-5e29-dc88-22c7-e5742f897bab
│ └─sda
└─sdb1 linux_raid_member 1.0 daphne:array0 ed63ec4d-5e29-dc88-22c7-e5742f897bab
└─sdb
md126 ext4 1.0 array1 347ea245-d99d-4830-8340-3767c17cee78 26.9G 8% /
├─sda2 linux_raid_member 1.2 daphne:array1 dae7f3a4-ba29-f32f-316d-2cb240747832
│ └─sda
└─sdb2 linux_raid_member 1.2 daphne:array1 dae7f3a4-ba29-f32f-316d-2cb240747832
└─sdb
md127 ext4 1.0 array2 31678818-37d7-4937-a278-ca8f6cf65c7b 415G 0% /home
├─sda3 linux_raid_member 1.2 daphne:array2 cec229c0-aa62-6f04-b27e-18f1be7838e5
│ └─sda
└─sdb3 linux_raid_member 1.2 daphne:array2 cec229c0-aa62-6f04-b27e-18f1be7838e5
└─sdb # lspci -v | grep "VGA" -A 19
b3:00.0 VGA compatible controller: NVIDIA Corporation GP106GL [Quadro P2200] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Dell GP106GL [Quadro P2200]
Flags: bus master, fast devsel, latency 0, IRQ 31, NUMA node 0
Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
Memory at f0000000 (64-bit, prefetchable) [size=32M]
I/O ports at f000 [size=128]
Expansion ROM at fb000000 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Legacy Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [250] Latency Tolerance Reporting
Capabilities: [128] Power Budgeting <?>
Capabilities: [420] Advanced Error Reporting
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
Capabilities: [900] Secondary PCI Express
Kernel driver in use: nouveau
Kernel modules: nouveauLast edited by dakota (2024-02-06 20:31:33)
"Before Enlightenment chop wood, carry water. After Enlightenment chop wood, carry water." -- Zen proverb
Offline
The systemd-analyze shows the culprit with dhcpcd and this is also documented in the wiki https://wiki.archlinux.org/title/Dhcpcd … ow_startup
Offline
18.245s (firmware)
04.005s (loader)
15.466s (kernel)
06.332s (userspace)
------------------
44.050s (total)
dhcpcd takes most of the userspace startup, but it's "only" 4s , ie. ~9% of the total time
Firmware might be self-test (enable fast-boot?)
About the kernel time: is the system encrypted? Does setting up the raid take so much time?
Journal?
Benchmark IO and CPU in isolation.
For a simplistic CPU (single core) check you can just abuse bc
time echo "scale=5000; a(1)*4" | bc -land compare that to a "good" system.
wrt "sluggish" and since you've just a bare-bone console system: less sluggish when booting "nomodeset" or using the nvidia blob?
Offline
Thanks V1del.
I thought I had done that. Whatever source I used, suggested putting "background" into the dhcpcd.conf file. This reduced startup by 2 seconds, but the method you suggest is clearly the correct one as it drops another 4 seconds.
Seth,
I don't see any option for "fast boot" in the motherboard firmware settings.
I can *extend* the BIOS POST time, but not reduce it. (To view BIOS messages, but there aren't any.)
I've checked the boot time against a very similar machine, a Dell T-5820. The BIOS settings are almost identical, they both use 500 GB SSD drives in a RAID-1 config, and they both use systemd-boot. The T-5820 has a slightly faster processor.
The overall boot times are almost identical.
T-7820 T-5820
------ ------
firmware 20.118 35.124
loader 4.976 3.424
kernel 15.772 2.179
userspace 2.574 2.752
-------- ------ ------
total 43.441 43.481But the distribution is weird. They have different BIOS versions. Is it possible that the newer Dell firmware (T-7820) pushes some hardware management off to the kernel, Reducing the firmware time and increasing the kernel time? The T-7820 journal has about 10 sec of "PCI host bridge to bus" messages (2-3 seconds for each of the 4 buses).
I've done some preliminary benchmarking for the CPU using "7z b" and compared the results online. The CPU is slow, but smack in the middle of the expected range.
As far as other 'sluggishness', I think most of that is coming from the usb bus. "usb: port power management may be unreliable"
Anyway, you all have helped me answer my question: nothing stands out as being terribly wrong and the boot/CPU times are what's expected for this system.
journal, T-7820, new machine
journal, T-5820, compare machine
Cheers,
Edit -- spelling
Last edited by dakota (2024-02-06 20:33:16)
"Before Enlightenment chop wood, carry water. After Enlightenment chop wood, carry water." -- Zen proverb
Offline
Does it really last 45s until you can login?
7820
Feb 06 11:28:18 daphne kernel: Linux version 6.7.4-arch1-1 (linux@archlinux) (gcc (GCC) 13.2.1 20230801, GNU ld (GNU Binutils) 2.42.0) #1 SMP PREEMPT_DYNAMIC Mon, 05 Feb 2024 22:07:49 +0000
Feb 06 11:28:19 daphne systemd[1]: Mounting /home...
Feb 06 11:28:20 daphne dhcpcd[613]: dhcpcd-10.0.6 starting
Feb 06 11:28:20 daphne systemd[1]: Startup finished in 19.565s (firmware) + 4.959s (loader) + 15.767s (kernel) + 2.587s (userspace) = 42.879s.
Feb 06 11:28:23 daphne dhcpcd[617]: enp0s31f6: carrier acquired
Feb 06 11:28:25 daphne dhcpcd[617]: enp0s31f6: adding default route via 10.10.32.1
Feb 06 11:30:55 daphne login[653]: pam_unix(login:session): session opened for user <username>(uid=1000) by <username>(uid=0)This is 7s from start to "you've got network" and then you login 150s later
5820
Feb 06 11:05:24 maria kernel: Linux version 6.7.4-arch1-1 (linux@archlinux) (gcc (GCC) 13.2.1 20230801, GNU ld (GNU Binutils) 2.42.0) #1 SMP PREEMPT_DYNAMIC Mon, 05 Feb 2024 22:07:49 +0000
Feb 06 11:05:26 maria systemd[1]: Startup finished in 34.620s (firmware) + 3.583s (loader) + 2.207s (kernel) + 2.750s (userspace) = 43.162s.
Feb 06 11:05:29 maria dhcpcd[517]: eno1: adding default route via 10.10.32.1
Feb 06 11:08:11 maria systemd-logind[514]: New session 1 of user <username>.takes 5s until you have network and then you login 162s later
'sluggishness', I think most of that is coming from the usb bus
Can you describe the symptoms of "sluggishness" a bit more detailed?
Offline
Seth,
With both the 7820 and the 5820, the time between: pressing the power button ==> getting a login prompt = 45 sec.
The time between: login prompt ==> logging in = me wandering aronud wondering where I left my coffee mug. ![]()
As far as sluggishness (and general weirdness)... no.
I really need to sit down and translate my 'feelings' into something specific. I experienced so many problems* with this install that I was starting to suspect RAM or other hardware issues... or maybe demonic possession.
The purpose of this thread was to determine if I should continue or toss in the towel.
I've decided to continue.
Now I need to regroup and figure out what, if any, problems still exist. If I still need help, I'll follow up with additional, specific, threads.
Cheers,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Turns out, most of the problems (and my failure to recognize them) were due to rushing the install when I was very tired and needing to "fix one more thing before I go to sleep".
Examples:
USB-3 thumb drive transferring data at 15 MB/s (expecting aronud 85 MB/s) -- [fraudulent advertising]
USB-C nvme/EVO drive transferring data at 15 MB/s (expecting around 300 MB/s) -- [cheap cable]
Boot entries vanishing from bootloader menu -- [typo when I fixing something else]
Bootloader booting into firmware even though boot entries appear in menu -- [deleted the wrong files]
Segfault during boot (weird gibberish when boot menu should appear) -- [data corruption]
mkinitcpio reporting the 512 MB /boot partition was full -- [because of a previously-corrupted file]
mkinitcpio failing to build -- [data corruption, 'fixed' by reinstalling]
FAT32 corruption errors listed in journal for the /boot partition -- [fixed via fsck]
Console font suddenly appearing really large (24 px?) -- [after installing nvidia to fix the segfault]
Network not available from .iso install environment -- [locked out by router for too many assignments]
Operating system not recognizing new partition tables -- [failure to reboot]
SSH not recognizing my certificate -- [wrong permissions on files/folders copied from another install]
Operating system not recognizing my new password -- [changed password for root instead of my user]
Long time to build mkinitcpio -- [no, not a long time, just seemed like it]
vim colors different when running inside tmux -- [needed to set background to black]
The only unresolved issues are related to the wireless mouse/keyboard.
Wireless mouse: cursor motion momentarily freezes (5-10 sec)
Wireless keyboard: delay before response
I won't have time to work on this for about a week.
In the meantime, I think I'll run Memtest again and when I come back I'll drag out a wired keyboard and mouse to see if it's a wireless problem or a usb problem (probably wireless, because moving the keyboard and mouse closer to the dongle seems to help.
Cheers,
"Before Enlightenment chop wood, carry water. After Enlightenment chop wood, carry water." -- Zen proverb
Offline
The only unresolved issues are related to the wireless mouse/keyboard.
· Wireless mouse: cursor motion momentarily freezes (5-10 sec)
· Wireless keyboard: delay before response
https://wiki.archlinux.org/title/Logite … g_Receiver
https://wiki.archlinux.org/title/Power_ … utosuspend
https://bbs.archlinux.org/viewtopic.php?id=281969
Offline
The only unresolved issues are related to the wireless mouse/keyboard.
· Wireless mouse: cursor motion momentarily freezes (5-10 sec)
· Wireless keyboard: delay before response
This problem can also manifest if there is electrical noise from USB3 sockets on the motherboard, and it is located close to or in one. Moving the receiver to a USB hub or the end of an extension cable may fix this.
Installing an extension cable to move the dongle away from the port fixed this problem. ![]()
"Before Enlightenment chop wood, carry water. After Enlightenment chop wood, carry water." -- Zen proverb
Offline