Thread: Boot times

so, when you say 30 sec boot time, is this from "power on" to fully loaded, usable state? Or is it 30 seconds from "power on" to login?

I have a 1 & 1/2 min boot time from "power on" to application in Debian Linux. The majority of time comes from USB bus detection in the kernel. This is with a non-customized base distro (Debian Sarge 2.6) configured kernel on a VIA MII-10000 w/ 512M RAM and an inefficient USB detection setup. I could probably shave 20 seconds with an optimized USB setup, another 5 from grub, 5 more by moving my GPS out of init scripts, and probably another 30 seconds with a custom kernel, 10+ more by running in Framebuffer instead of X. Linux bios project, well, 3 seconds from power on to kernel loaded is what they claim.

When I am not running a beta version of what other people will be running on ambiguous hardware I will do a custom kernel. I like to point to MediaCar as an example of fast boot on linux. Put that on the HDD with Linux bios, wow. It would be even faster!

To speed up boot time in linux:
- Custom compile kernel for your hardware. (lose HW ambiguity (sp?))
- Hard code all USB devices (not recommended but possible)
- Load the UI at the earliest possible point in initialization (before network, after pointer, may require moving init scripts around)
- Remove all unneccessary startup scrips / daemons.
- Use linux bios project (if you are really brave).
- Use the framebuffer directly.

With a custom build kernel I was getting my desktop (P4 3.06 768M RAM) to load from Power on to full Gnome Desktop (with mozilla, gaim, and xchat loaded) in 45 secs. This is including a 5 sec grub time AND passwd login (I have a long passwd).

If you want help we (yes i am volanteering everyone ) can get your boot time in linux WAAY below what XP will do. The turn-by-turn GPS will have to come later

Let us know what you need help with .

Although I dont run a carpc, i have been messing with a mini-itx c3-800. I have used damnsmalllinux and just disabled much of the hardware detection. I get about 1 min - 1 min 10 secs. This includes the backup feature which is lengthy - about 15-20 seconds.

I think (being a relative linux newbie) that "off-the-shelf" linux is slower, but it CAN be configured to be faster....the question is - how much time do you have??

30sec for winamp to play.

Thanks for all the detail pkg.

Just an update - since switching to Gentoo, my boot time has decreased to about 80 seconds from cold boot to X, and the frontend running. Since I'm using KDE for the WM, the time it takes for it to load is included as well. Almost all the "cool stuff" wrt KDE is disabled, including many of the background services like kwrited, etc. The only reason I'm even using KDE is to take advantage of the FFT module in aRts (spectrum analyzer display).

Pkg: As for hardcoding the USB stuff in the kernel, that's fine if you don't plan on using swsusp or swsusp2 but they need to be compiled as modules otherwise as they have to be unloaded at suspend and reloaded at resume.

I haven't had time to fully test swsusp2 but I'll post my results when once I know more...

One other thing I've noticed is that LILO appears to be a second or two faster than GRUB at getting to the kernel load point.

One more thing for anyone using the ati_remote module - don't put it in /etc/modules.autoload.d/kernel-2.6. Put it in your .bashrc or another script so it's loaded well after the USB stuff is initialized or it will act really weird and/or be incredibly slow. And don't forget to add ati_remote to the list of modules to reload as well (if you're using swsusp/swsusp2) and use either a udev rule like I believe pkg is doing or some other mechanism to allow your frontend/background daemon to read the proper /dev/input/eventX file.

Okay I jumped the gun a bit about the ati_remote module. My USB stuff wasn't set up quite right. Now that I've compiled all the necessary USB stuff as modules and inserted them in the right order, ati_remote works just fine being loaded straight away in the /etc/modules.autoload.d/kernel-2.6 file.

Apologies in advance if this seems like a bit of a blog

I just measured my boot time. The time from power on until my software is responding is between 29 and 33 seconds. I measured several times. I'm interested in seeing how fast it is when I remove all the networking and udev stuff. I plan on allowing my software to enable the network explicitly since the unit will be in my car most of the time. BTW, my system is 667mhz.

Originally Posted by TheLlama

I just measured my boot time. The time from power on until my software is responding is between 29 and 33 seconds. I measured several times. I'm interested in seeing how fast it is when I remove all the networking and udev stuff. I plan on allowing my software to enable the network explicitly since the unit will be in my car most of the time. BTW, my system is 667mhz.

That seems on-par with what I've achieved in the past given your CPU clock is roughly half of the VIA C3 I'm using. I'm guessing without udev and delayed network setup you'll only gain 5s max but 5s is still 5s If you can go from cold boot to functional in 20s that would be a very good thing - even though I'm getting about 15s with hibernation it's not entirely without it's problems - I'm currently seeing a slowdown in the aRts daemon that appears to be cumulative to the point of annoying after about the 10th hibernation. There aren't any dropped frames or degradation in the sound, just longer and longer delays between when a sound should be heard and when it's actually heard. If I cold boot the slowdown disappears.

why not kill artsd on resume and restart it.

It would kill everything using it in the process (mp3 backend and spectrum analyzer mainly).

I'll play around with allocating larger buffers tonight to see if that helps (my buffers are teeny right now).