Systemd-analyze cmd bytes, discuss.

[Deb-fan]

Ok here's the deal, I'm fairly anal, if I'm going to bother checking on how long it took a system to boot I actually want meaningful metrics and stats. To me a completed boot is when a user reaches a working desktop. Meaning they can actually do something or anything ... use the thing. You check output of systemd-analyze, it gives you these arbitrary stats. Kernel = 7secs, userspace 14.222secs, total = added together. This is hogwash in real life, cause if someone measures time to actual working desktop, those systemd stats are pure garbage, it'll say you've gained this or added this much more time after tuning but when the boot process is timed to actual working desktop, nothing has changed in reality. So I've been dorking around with possible methods of measuring this in any worthwhile way, like adding a termininal to a given windows managers autostart/startup file and then figuring out how to see exactly when that process fired off or catching what it reports as uptime and echo'ing the thing to a file ? However I am lazy, not inclined to reinvent the wheel and perhaps a good solution may pop into someone here's head right off or any refinements, other factors to consider. So figured I'd ask.

Also perhaps someday hoping to see the systemd dev-team actually incorporate something that actually gives any stats of value, vs this present day nonsense the thing provides. Booooooo, systemd-analyze !!! BooOOOOO ! I mean a process that fires off when reaching an actually useable graphical interface and reports it accurately surely can't be beyond such uber-geeks abilities. On the plus side, systemd-analyze tells me I'm booting up twice as fast as I really am ... great. Tells me I'm making or losing gains while tweaking, providing me plenty of stats which don't actually matter. Whoooo hooo and yippie ! BoooooOOOOO, boooooOOoooo !

Questions, comments ... concerns and esp any workable methods/info for this dorkness all welcome. Thanks in advance.

[Deb-fan]

Pointless - dorkish update:

A couple pokes got xterm popping open/closes(which tells me yep, reached working desktop) and sending uptime's output to a file in home andddddd ? Lol ... it says uptime 0 minutes o course. However does include exact time w secs the uptime cmd was run. So with some more poking around should surely be able to figure out the stats I'm going for, power on to working desktop. What's the use of this junk ... really? Just go with what good general rule of thumb, whatever it reports x two, +/- a couple of seconds? Errrr. Also to me this draws into question the value of associated commands used with it, if even significant changes in kernel + userspace/total don't translate into any real effect on time to working desktop (can actually use the Os) then clearly these tools are coming up short.

PS, a cunning promotional ploy? Windows users see these awesome boot-times and can't resist giving gnu/Linux a try?

Xyz nixer says yeah my OS boots super fast, output of systemd-analyze, 14.4secs. Of course that nixer can't actually do anything for 28-29secs but wow that's fast.

[Deb-fan]

Dork-report #2:

LMAO but making progress here I think. Current state of affairs, set xterm to popup, run uptime and send to file in the current working directory (users home.) Adding such to openbox or fluxbox's autostart/startup file(s) xterm -e bash -c "uptime > realdeal" & It pops open terminal, gives me uptime including secs, in the realdeal file. Then checked the time when system clock was set as reported in dmesg, "sudo dmesg | grep UTC" giving me that in UTC, lol. Now converting UTC to localtime where I am (CST) is + 6hrs and finally used what systemd-analyze reports for time the kernel took, ending out with between 36-37secs mucho closer to actual useable OS, than what was being reported. Really close and about right for reaching working desktop. Actually it's like 39secs(because the uptime/dmesg stats don't include fractions of a sec) *Whew ... wipes sweat offa brow.

Edit: Yep ... kinda dumb though some people want to check such and systemd-analyze telling me this is 20-21secs isn't helpful. Can think of other ways which are better just amending that xterm thingy with ;;(or &&) systemd-analyze >> realdeal to go ahead and send output to the realdeal file for it too, a systemd unit that runs asap etc. Also clearly don't need this every boot, so just comment it out in whichever startup file between dorking. Finally yes, silly and this is already effectively covered in the great bk of gnu/nix dorkage, aka: The nix tuner, tweaker and compulsive optimizers handbook. Thou shall disable all unused services/daemons on thine systems and periodically rinse and repeateth. RAmennnnnn!

[Deb-fan]

Important face + palm afterthoughts.

When comes to UTC to localtime, the hour field doesn't matter anyway, just mins and seconds reported in dmesg output. Ie: You boot your system at 9:28am. Output of uptime on file says 9:28:22, obviously saying 22secs there, grep UTC from dmesg says 15:27:53 or some other madness, only the 27:53 (mins/secs) part matters here. Now ... if we take into account solar flares and the changes of gravitational effects the current moon phase has upon the earth, then we/you must ... Just kidding about this part.

Could clear it in a file I keep in sudoers.d so the dmesg cmd can be run by user w/o need to enter passwd, chain all this stuff together, figure out how to get the mighty bashness to add all the relevant stats together and just give nixer's a solid figure on power on to working desktop (from there worst case is like + 1.8secs, I tend to just round up regardless) but am lazy and my bashly skills kinda byte too. Ah oh well better satisfied with this vs what I was getting stats-wise.

Edit: I would also like to take this opportunity to brag on my stats, feel have earned such w this dorkness. Cold boot to WORKING desktop on a 10yr old dual-core with a rust drive, 39secs is none too shabby.

[trinidad]

I would also like to take this opportunity to brag on my stats, feel have earned such w this dorkness. Cold boot to WORKING desktop on a 10yr old dual-core with a rust drive, 39secs is none too shabby

Not sure of your CPU here, maybe you mean core2duo 64bit. Anyway my 9 year old Asus Vision AMDAthlon2 boots Debian 10 gnome full DE 64bit on wayland and a 1T drive in about 28 seconds including auto-connecting wifi, and you can take out for me entering my password in GDM so even a little less though I am a fast typer. I am running some unique firmware and no graphical plymouth. Kernel is 4.19. By comparison Linux Lite (XFCE) on the same box takes about 40 seconds.

TC

[Deb-fan]

^ Stats, or it didn't happen Sir!? Messing around that's good time. It's a t3400 proc @2.17ghz. May get around to fiddling up a shell script for this thing. Really shouldn't take long even w my crappy grasp of bash-etc. Though atm I'm burnt out on messing with it.

PS, clarification ... Power on in this doesn't mean time someone presses the on button on their pc, means when something is selected in grub's menu to working gnu/nix os desktop.

[CwF]

It takes mine a minute to get the first beep. A cold boot doesn't happen often.

[NFT5]

These threads of yours are interesting, Deb-fan. Partly because you seem to choose topics that I'm interested in and partly because of your mildly amusing inane prattle. I really do hope that this one doesn't get locked because of the use of non-Debian examples to demonstrate an on-topic point.

Anyway....haven't run systemd-analyze for a while so did so.

Code: Select all

chris@BOSSDESK:~$ systemd-analyze
Startup finished in 17.625s (firmware) + 12.968s (loader) + 4.289s (kernel) + 5.133s (userspace) = 40.016s 
graphical.target reached after 5.113s in userspace

Wow! Hadn't realised it was quite that slow. Restarted the machine and, this time, used the stop watch on my phone. Curious. In real time it only took just on 20 seconds, including typing name and password. Ran systemd-analyze again and got almost the same result as the first time.

Delved into some old stuff and found this:

Code: Select all

chris@BOSSDESK:~$ systemd-analyze
Startup finished in 1.898s (kernel) + 2.211s (userspace) = 4.110s

That was in July 2017, running Jessie on the same desktop, except that I've since changed the CPU from an FX6300 to an FX8350. Faster CPU should make it quicker, right? But obviously no. Now running Buster, almost exactly the same software mix and MATE desktop in both cases.

So why the big difference and why does the desktop actually come up some 20 seconds before systemd-analyze says it was complete?

Answer to the second part of the question is that, in Buster at least, it's still loading stuff after the desktop is up, just like Windows does.

Still leaves a significant difference, though. So then the question is, for the point of your exercise, what is actually being measured and has systemd-analyze changed from Jessie to Buster? Are we comparing apples with apples?

[Deb-fan]

^Thanks and that's fairly wild. Part of why this nonsense is posted. Been wondering and couldn't test it. That being real life how this works on different hardware, with different desktops. Am almost certain I've got systemd upgraded to whatever is in unstable on both Stretch and Buster ( systemd 244.x) Jebuz the workings of the thing are beyond comprehension. It tells me system's twice as fast, telling you twice as slow? Any way it goes wasn't telling me what I wanted to know, time from selecting something in boot menu till getting to a desktop I can actually do anything on.

I went with the much more scientific method to accurately measure this, one 1000, two 1000, 3 1000 ... Press keybind to launch terminal, it pops up, ended up consistently around 40secs. So that prompted this which seems fairly accurate and consistent for what I was trying to find out. From what you're describing crap, starting to think systemd-analyze just gives random numbers, arghhhhh. Clearly capable of getting down to fractions of seconds too. More arghhh, might really be a kind of ploy as mentioned? Could actually work and for folks like @CwF with real/legit IT applications this kind of thing doesn't matter much anyway. For dorks like me if hardware is reasonably capable of xyz-performance I want it in that range and want to have ways to a accurately measure it regardless.

Edit: Well clearly if xyz- hardware is reasonably capable I want it top-end of whatever range and even using outmoded tech, wanting it creeping into other performance ranges, means whatever tweak/tuning dorkness is obviously working.

[CwF]

X9SRA Stretch

Code: Select all

$  systemd-analyze
Startup finished in 17.569s (kernel) + 1.502s (userspace) = 19.071s
$ uptime
 05:51:28 up 129 days, 14:55,  3 users,  load average: 2.05, 1.17, 0.95

X9DAi Buster

Code: Select all

$  systemd-analyze
Startup finished in 10.708s (kernel) + 2.060s (userspace) = 12.769s 
graphical.target reached after 1.696s in userspace
$  uptime
 05:54:33 up 21 days,  9:34,  1 user,  load average: 0.85, 0.73, 0.69

Ok I guess? Still, these types of boards don't initialize quickly. Really does take a minute or so to post, both have multiple video cards, that slows post. I have a C7Q67 modded with an E3-12xx xeon that post in a split second and the trucks X9SVC-Q also post quickly, but plays a song of many many usb device beeps. It is a step backwards to wait so long for the radio to play...

[trinidad]

Restarted the machine and, this time, used the stop watch on my phone. Curious. In real time it only took just on 20 seconds, including typing name and password.

Time readings are not without overlaps; that is some initializations are simultaneous and dependent and report wait time overlapping other processes. Can be quite skewed with some bigger multi-core multi-threading CPUs and boards.

in Buster at least, it's still loading stuff after the desktop is up

Depends on the specific DE and networking settings.

these types of boards don't initialize quickly. Really does take a minute or so to post

My Debian 9 LAMP server with SSH server takes about a minute and a half to boot if I pass through to the DE,

Anyway it is a useful tool for many things.

https://www.freedesktop.org/software/sy ... alyze.html

TC

[pendrachken]

Uptime has a built in feature to help with this BTW, you don't have to look in dmesg yourself.

Code: Select all

uptime -s

is "uptime since" and should give you down to the second when the boot was initiated. So you could do something like launch the xterm and have it do

Code: Select all

 
uptime -s > testresults && uptime >> testresults 

Then just subtract the minutes and seconds from the times. Pretty sure you could do it automagically too if you wanted to do a little AWKery and inline BC.

[Deb-fan]

^ Thanks ... Of course started this out playing around with uptime, including uptime -s but the approach you advise, didn't occur to me, would be better/cleaner and more elegant. Using awk to do the math is likely just a matter of googling on it and some poking around trying things, like 10-30mins tops. Of course if you ask the systemd-analyze command it'll tell you you've completed such a project in 5.6mins. However long it actually took figuring this out.

Plenty of easy ways to do this independent of desktop used. Was wondering about this as related to more complex DE's, plenty of things running to get them set up. To me a system isn't up until it's useable.

@CwF: Am sure those are beasts of systems and stats look good to me but for real system admins(like yourself) am sure this isn't an area that receives much time or focus. Even many desktop nixers could be shaking heads and do feel a tad tarded sitting there timing this but not like do so every boot or day. Want an accurate idea of it nonetheless.

[Deb-fan]

Dorkish update + refinements:

Ended up going with ...

Code: Select all

xterm -e bash -c "uptime -s >> .realdeal && uptime >> .realdeal && systemd-analyze >> .realdeal" &

Yep better, uptime -s, same info no sudo involved. Set the realdeal file to be a .(dot) file so it's hidden just to avoid clutter. Still ending up with stats from uptime w/o fractions of secs +1.8 secs there but oh well. Set things to not overwrite other entries in the file, since bothered to mess with this may as well keep a record of the stats involved. Still just commenting the line out between use and don't want to bother with awk etc, it's basic math and even dorks can handle that. Plus like seeing the cpu load avgs uptime provides. Whenever do run the thing, just pop open a terminal "cat .realdeal" and there's my stats.