You are not logged in.
Just curious, why does your Arch take more than 30 seconds from grub to GDM. Mine is with 1G DDRII667 ram, Pentium E2160 Dual Core.
9 seconds from Grub to Slim.
1 second from Slim to standalone Openbox.
Shutdown is about 5 seconds.
Offline
I have a theory on what slows down the boot process in Arch. One word: udev.
On top of that it seems like if the udev hook is used in building the initrd image, udev is actually called twice. First during the initial boot and running of the udev hook and then once again by rc.sysinit. Seems redundant.
It also could be all the taco crumbs...
FaunOS: Live USB/DVD Linux Distro: http://www.faunos.com
Offline
raymano, there's not much that can be done about the udev being run twice, as far as I know, the alternatives aren't much better. The first one is negligable anyway.
To get a speed up, it'd be better to improve the userspace udev... presently it takes longer than ever. A significant part of that is due to blacklisting load_modules.sh -- though I think I've just had a really good idea to fix that up.
As for the tests in the initial article, it doesnt say much about how they were run. Were they from init 1 or X? Was Arch on the start or end of the hard drive (faster seeking times at the start)? Were the tests run repeatedly and an average gained?
I'll claim the slowest bootup time here, my bios takes forever, my Arch not much better -- I tend to leave the computer and get a coffee/water.
James
Last edited by iphitus (2008-03-17 05:16:54)
Offline
As for the tests in the initial article, it doesnt say much about how they were run. Were they from init 1 or X? Was Arch on the start or end of the hard drive (faster seeking times at the start)?
That is exactly what I was thinking. Also, Arch != Arch. I am pretty sure that most of our systems would run at different speeds, even if we all had the same hardware used the same windowing manager/DE - simply because setting up Arch is - while not being overly hard - not trivial, either. There are way too many variables in there. Why should I trust someone doing random speedtests the use of which is highly questionable in the first place?
Anyway, Arch is faster.
Offline
There's a great wiki article on how to speedup udev, and it works surprisingly well. On my old laptop, udev times went from ~20 seconds to ~7 seconds.
http://wiki.archlinux.org/index.php/Speedup_udev
Offline
There's a great wiki article on how to speedup udev, and it works surprisingly well. On my old laptop, udev times went from ~20 seconds to ~7 seconds.
http://wiki.archlinux.org/index.php/Speedup_udev
Hmmm, did you do option 1 or 2? I don't use either as my udev is already quite fast, but it seems that option 2 isn't up to date anymore. A recent update has moved my "/etc/udev/rules.d/udev.rules" to "/etc/udev/rules.d/udev.rules.pacsave", so I assume there isn't meant to be a udev.rules anymore. Is this meant to happen? I'm gonna take a guess that it defaults to the '50-udev-default.rules' file if the usual file doesn't exist.
Last edited by dyscoria (2008-03-17 12:34:13)
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
There's a great wiki article on how to speedup udev, and it works surprisingly well. On my old laptop, udev times went from ~20 seconds to ~7 seconds.
http://wiki.archlinux.org/index.php/Speedup_udev
the article assumption is that one is running default kernel or that there is plenty of unused modules modules that slow down boot process. These modules blacklisted or not slowdown boot process. This is caused by udev not being able to cope with whatever udev is unable to cope.
However, if you have custom kernel only with modules that your system is going to use, still you can see slowdown of boot process between .21 to .24 kernels
In such cases, the article is not helping really. Not to mention that 7s for udev is actually looong time.
The only thing I see is that kernel is getting fatter but problems do not go away (Arch devs are not at fault, though I wish they could be able do find a cure).
Offline
Personally, I have found that Arch functions much better on my laptop than debian did.
Also, while we are talking about this...does anyone have any tips or tricks they have used to make arch even faster?
Offline
Bah! I am comparative to an infant when it comes to reading Spanish, but between comparative bouts of crapping my pants and eating taco mush, I didn't see any details on each distro installation. For example, CentOS can be a beast for standard install with SELinux installed by default.
Offline
~11sec here from grub to kdm if i dont count the time needed to enter my luks passphrase
I have no module autoloading, all i need is in the modules() array.
After recompiling kde stuff from kdemod with LDFLAGS like --as-needed ;P it started up much faster.
Offline
I installed Arch64 as my second distro (I use PCLinuxOS 32 bit for work).
I like Arch and I'm going to install it as my primary distro (with chroot Arch32 for some applications), but I found something strange.
I ran a scientific program of mine (mostly it does computations, no graphical interface) both on PCLOS and Arch, and with the same parameters it is much slower in Arch: 18 minutes versus 10 minutes. The result for Arch is the same both at 64 bit and on chroot at 32 bit.
How is it possible? PCLOS has kernel 2.6.22.15, while Arch has 2.6.24. PCLOS is in the middle of the hard disk (I have oem windows vista at the beginning, shame on me) and Arch is currently at the end, but I don't think this is a relevant thing because my program mostly computes and does not need much reading and writing from the hard disk.
Any ideas? Maybe I should recompile gcc and gfortran?
Offline