You are not logged in.
I noticed the udev package, after the latest update, prints a 'UDev uevent processing time' and I was wondering why. Although I am a big fan of statistics of any kind
, I hope that this is not gonna be a trend where each startup entry is going to add some custom statistics entry to the bootprocess.
Wouldn't it be a better idea to implement this sort of stats globally in the /etc/rc.d/functions replacing the [DONE] entry with something like [DONE in 4.234 s] when some setting has been passed to the kernel or configured in rc.conf, so that there remains some consistency in the boot process?
Offline
I think this was added because recently devs were trying to cut down the udev processing time -- no idea if this is a permanent feature or not. You should be able to remove it easily by editing /etc/rc.sysinint script if you really don't like it.
Offline
Because that part of the boot process is slow as ass, due to some horrendous scripting.
We just like to remember how slow ass actually is ![]()
The suggestion box only accepts patches.
Offline
Hmm, but on my machines udev isn't the slowest part; and if it would be, I wouldn't need a timer to tell me so? I think it makes the boot process a bit cluttered which is why I would like it to be removed; or replaced by a more generic solution ![]()
Offline
Offline
I added that simply because, in the future, I want people to complain loudly when that number jumps too much. If it takes 3.4 seconds to boot one day, then 7 seconds after an upgrade, I want people to go "oh god someone screwed it up!"
Offline
now it got 9500 in compare to the 7000 i had lately btw
Last edited by dolby (2008-03-24 21:12:12)
There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)
Offline
Sarcastic overlords rule.
1492, I wanna see someone top that. ;-)
To me, the notice isn't that big of a deal, fsck and init jump out as it is already.
Offline
now it got 9500 in compare to the 7000 i had lately btw
See, good numbers to have. I have a feeling this was simply a change between udev 118 and 119.
I am well aware that fsck is a big one, and it will always be as storage size increases (it takes longer to check a bigger disk, duh). But udev should be low, all things considered.
Offline
About 21000 (21 seconds), I don't see many improvements.
Last edited by ekerazha (2008-03-24 22:02:03)
Offline
udev is definitely the limiting reagent on my machine, since I don't have an fsck that runs every time I boot. Speeding up udev has a noticable impact on my total boot time, so I was glad to accept one more line of boot output in return for some metrics that might help us speed this up.
Offline
About 21000 (21 seconds), I don't see many improvements.
There was a thread recently where some people also complained that udev processing time was not improved for them and, as it turned out, the problem was with some custom/old/leftover rules in the /etc/udev/rules.d. Maybe it's worth clearing the directory manually and reinstalling udev package and/or double-checking if any custom rules are not slowing things down.
For reference: my desktop (Athlon X2 4400) takes about 1,5 seconds, my 0.6Ghz Celeron laptop takes 5-6 seconds -- which is a massive improvement over what was the case a while back.
Last edited by fwojciec (2008-03-24 23:57:29)
Offline
I have been seeing the stats for a little while now, but I was amazed to start seeing i guess after an update, that it went down from 8 seconds to just under 2, so keep up the good work!
Offline
I usually get pretty quick udev times...however I get a weird thing. Sometimes (about 60% of the time), it hangs for a while. Takes upwards of 30 seconds on my A64 3800+. However, if I unplug my USB hardware modem it finishes quickly. If my USB modem isn't plugged in from the start, then it never hangs. If it is plugged in then, yeah, about 60% of the time it hangs. As soon as it is plugged in (even during boot sequence, but after udev) it is recognized in about 1 second, always.
Any ideas? It was always this way, even with the 2007.08 Core ISO. I just unplug it for boot and replug it upon SLiM coming up.
Agh, I feel like a threadjacker. Sorry.
Stop looking at my signature. It betrays your nature.
Offline
I saw a huge improvement. I always counted like 20seconds and now it's 9.2 seconds. I am happy.
Offline
for me,it is 4.5 seconds
I think that stat is really useful! ![]()
Offline
around 1.1 most of the time here.
ARCH64 | XMonad | Configs | myAURpkgs | ArchWiki Contribs | Screenies
Offline
I always had a udev processing time between 5 and 6 seconds.
After some updates in testing they went up to 13, so i deleted all udev-rules, downgraded to stable (which means no testing enabled) and reinstalled udev - Back to 5-6 seconds.
Today I installed udev from ABS and compiled it with custom CC-Flags (o3) - and it went down to 3 seconds ![]()
I think it won't get much faster on my sempron 3500 Notebook ![]()
Offline
119 is slower than 118 on my laptop (i686) so I went back to 118
Offline
Only a little faster here, something like 4.2s -> 3.8s.
What does not kill you will hurt a lot.
Offline
I added that simply because, in the future, I want people to complain loudly when that number jumps too much. If it takes 3.4 seconds to boot one day, then 7 seconds after an upgrade, I want people to go "oh god someone screwed it up!"
Sorry, I could not resist...:lol:
Shaika-Dzari
http://www.4nakama.net
Offline
My udev is done in roughly 2322ms
I'm pretty sure that's good ![]()
Offline
Mine varies between approximately 850 and 1050, with a stripped down kernel.
Offline
Yeah, 1050 for me too with a slightly minimalized custom kernel.
flack 2.0.6: menu-driven BASH script to easily tag FLAC files (AUR)
knock-once 1.2: BASH script to easily create/send one-time sequences for knockd (forum/AUR)
Offline
ekerazha wrote:About 21000 (21 seconds), I don't see many improvements.
There was a thread recently where some people also complained that udev processing time was not improved for them and, as it turned out, the problem was with some custom/old/leftover rules in the /etc/udev/rules.d. Maybe it's worth clearing the directory manually and reinstalling udev package and/or double-checking if any custom rules are not slowing things down.
For reference: my desktop (Athlon X2 4400) takes about 1,5 seconds, my 0.6Ghz Celeron laptop takes 5-6 seconds -- which is a massive improvement over what was the case a while back.
I've tried to clear /etc/udev/rules.d and reinstall udev, but they always are about 21-22 seconds (on a Pentium III 933 Mhz, 512 MB of RAM, Seagate 7200rpm).
On a Turion64 MT-32, 2GB of RAM, 4200rpm they are about 7 seconds.
Last edited by ekerazha (2008-03-29 12:34:15)
Offline