# Bootup Time Improvement (bootchart)

## zx2c4

Based on this bootchart image: http://data.zx2c4.com/bootchart.png, how do you think I can improve my startup speed? I use baselayout 2, netplug, and parallel startup. Any advice?

----------

## michel7

parallel startup is not good cause there are some services which doesnt work propertly

----------

## zx2c4

Care to qualify that statement? Which version? Which services? Any of the services that I use?

I use parallel startup and it has shaved off 6 seconds from startup while causing NO problems.

Any advice on how I can further reduce startup time? 25 seconds is still WAY too long for my hardware.

Speaking of which:

```
tux zx2c4 # cat /proc/cpuinfo

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 14

model name      : Genuine Intel(R) CPU           T2250  @ 1.73GHz

stepping        : 8

cpu MHz         : 1733.000

cache size      : 2048 KB

physical id     : 0

siblings        : 2

core id         : 0

cpu cores       : 2

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 10

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor est tm2 xtpr

bogomips        : 3461.68

clflush size    : 64

processor       : 1

vendor_id       : GenuineIntel

cpu family      : 6

model           : 14

model name      : Genuine Intel(R) CPU           T2250  @ 1.73GHz

stepping        : 8

cpu MHz         : 1733.000

cache size      : 2048 KB

physical id     : 0

siblings        : 2

core id         : 1

cpu cores       : 2

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 10

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor est tm2 xtpr

bogomips        : 3458.01

clflush size    : 64

```

```
tux zx2c4 # lspci

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)

00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03)

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)

00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)

00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01)

00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)

00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)

00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)

00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1)

00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01)

00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 01)

00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400

03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)

03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller

03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19)

03:01.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01)

03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a)

03:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05)

0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

```

```
tux zx2c4 # lsmod

Module                  Size  Used by

fglrx                 703616  36

iwl3945               143712  0

```

```
tux zx2c4 # lsusb

Bus 005 Device 001: ID 0000:0000

Bus 004 Device 002: ID 046d:c506 Logitech, Inc. MX-700 Cordless Mouse Receiver

Bus 004 Device 001: ID 0000:0000

Bus 003 Device 001: ID 0000:0000

Bus 002 Device 001: ID 0000:0000

Bus 001 Device 005: ID 0d49:7100 Maxtor

Bus 001 Device 003: ID 03f0:3817 Hewlett-Packard

Bus 001 Device 001: ID 0000:0000

Bus 001 Device 002: ID 413c:a005 Dell Computer Corp.

```

----------

## i92guboj

Parallel startup gives problems. Believe it or not. hdparm and some net services can fail, because the Gentoo init system is not designed to do that. Think with your head. If is was safe, it wouldn't come disabled by default. It has been there for years. The Gentoo devs are not evil beings that like to make our machines slower intentionally by disabling magical performance boosts.

25 seconds is too much... Well, if you think so, you should be looking into initng or suspend. The regular init system needs time to boot. I don't think it is a big deal at all. You are spending much more time looking for uber optimizations than you will ever spend booting your machine. Not to count the time you will spend when you run intro trouble. Baselayout2 is also hard masked for a reason.

BTW, that times are not way too hight (as you say) for your hardware. Not at all.

If you want a faster bootupt with the current init system, you can only achieve that by loading less services. Services are not black magic, are programs, and all the programs need time to load.Last edited by i92guboj on Sat Oct 06, 2007 2:10 am; edited 1 time in total

----------

## BitJam

As the artist formerly known as pink said, I think you should consider using suspend if a 25 second boot is too much for you.

----------

## albright

 *Quote:*   

> The regular init system needs time to boot. I don't think it is a big deal at all.

 

You are right ... as things are. But you are wrong as things *should*

be. What if light bulbs took 25 seconds to turn on? There is no law

of nature which says computers have to take seconds to boot up.

It is because pioneers keep pushing that we will eventually have

machines that are a little bit closer to what they should be.

25 seconds???!!! By god, it should be 25 microseconds!

----------

## i92guboj

 *albright wrote:*   

>  *Quote:*   The regular init system needs time to boot. I don't think it is a big deal at all. 
> 
> You are right ... as things are. But you are wrong as things *should*
> 
> be. What if light bulbs took 25 seconds to turn on? There is no law
> ...

 

I didn't imply that. That are completely your words. 

I just said that it is not possible to take much more from the standard init system. Which is completely true.

I also pointed to a couple of methods that would be more productive than to try to screw your init scripts with parallel startup: initng and suspend. You completely missunderstood me, or maybe I explained very bad. Besides that, you can't compare a light bulb with a computer. The same that you can't compare a whistle with the Nut Cracker from Tchaikovski. The former can be played in a second, the later needs time. Period.

We will boot in 25 microseconds in a couple of decades. Maybe. Don't worry about that. I just think that it is not a big deal to "waste" 25 seconds to boot. Of course eveyone is free to do whatever s/he wants. I just said he is not in the correct way. Since that way has already reached an end, and in the way, he might have screwed something that he could regret tomorrow.

----------

## zx2c4

 *Quote:*   

> Parallel startup gives problems.

 

I've never had a problem with it. In fact, it has only helped me.

 *Quote:*   

> Baselayout2 is also hard masked for a reason. 

 

Maybe so, but again, I've never had a problem, and it has only helped me.

 *Quote:*   

> you should be looking into initng or suspend. 

 

Suspend is out of the question. As far as initng... what's the compatibility like? How's it compare in speed with baselayout-2? Isn't there another popular init replacement for gentoo? How do these two compare with ubuntu's upstart?

 *Quote:*   

> BTW, that times are not way too hight (as you say) for your hardware. Not at all. 

 

If the software was better, it would boot a lot faster. Look at the CPU/IO usage -- it's not at 100% all the time. That is to say -- the hardware is not being utilized to its fullest extent always, as it should. I'd prefer one huge 100% serge and then BAM it's booted already. Also -- perhaps the algorithms in someplaces could be optimized to require less cpu usage, so it can devote more cpu usage to other tasks.

 *Quote:*   

> If you want a faster bootupt with the current init system, you can only achieve that by loading less services. 

 

Which services do you think I could remove from startup?

Please stop attacking the intention of this post, and only reply if you have something to contribute to the post's intention (that is: advice on how to optimize things).

----------

## i92guboj

 *zx2c4 wrote:*   

> Please stop attacking the intention of this post, and only reply if you have something to contribute to the post's intention (that is: advice on how to optimize things).

 

I am not attacking. I am telling you that the faster boot will be with suspend but you are right in one thing. I shouldn't have entered the thread.

----------

## zx2c4

Suspend is just normal hard-drive suspend, right?

Can anyone think of a way for me to maximize performance using normal bootup? Is initng faster than baselayout-2? What about eInit? How do they compare? What about upstart? etc etc

From the graph that you see, should I be tinkering with my services in anyway?

----------

## BitJam

Why is suspend out of the question?  It would certainly let you indulge your urge to tinker.

An expensive way to maximize performance for normal booting is to get one of those new solid-state drives.  If you do, I would suggest keeping /var and /tmp and swap on normal drives to increase longevity.

Along those same lines, you might want to take a look at your file system and possible fragmentation.  It appears that most of your boot time is spent doing disk seeks.  But I've got a fairly recent amd 3600x2 system with a SATA drive and yet it takes me about 30 seconds to boot to the command line and another 30 seconds to get KDE going and restore my KDE session (8 desktops and lots of open windows).

Edit: PATA --> SATALast edited by BitJam on Sat Oct 06, 2007 6:27 pm; edited 1 time in total

----------

## zx2c4

 *Quote:*   

> on normal drives to increase longevity. 

 

Do you mean to suggest that solid-state drives wear out quickly? 

 *Quote:*   

> Along those same lines, you might want to take a look at your file system and possible fragmentation.

 

I'm pretty sure that my filesystem is badly fragmented. How do defrag it? I use ext3.

From wikipedia: *Quote:*   

> There is no online ext3 defragmentation tool working on the filesystem level. An offline ext2 defragmenter, e2defrag, exists but requires that the ext3 filesystem be converted back to ext2 first. But depending on the feature bits turned on the filesystem, e2defrag may destroy data; it does not know how to treat many of the newer ext3 features.[4]

 Hmmmm... :-\ Any advice?

----------

## i92guboj

[quote="zx2c4"] *Quote:*   

> 
> 
>  *Quote:*   Along those same lines, you might want to take a look at your file system and possible fragmentation. 
> 
> I'm pretty sure that my filesystem is badly fragmented. How do defrag it? I use ext3.
> ...

 

The only reliable method is to tar or copy it to any other place and then reformat the partition and put the content back again. Make sure you preserve permisions or you will be in trouble. That's -p for tar and -a for cp.

PS. Make sure that fs is not being used while tarring or copying it. Ideally, boot from a livecd and mount it read-only. Otherwise, you risk getting a corrupt tar file.

----------

## zx2c4

Would you recommend I switch to a 'better' filesystem? JFS? XFS? ZFS?Last edited by zx2c4 on Sat Oct 06, 2007 6:17 pm; edited 2 times in total

----------

## BitJam

 *zx2c4 wrote:*   

> Do you mean to suggest that solid-state drives wear out quickly? 

 

If you are writing to them a lot, yes.  This problem is discussed in the wiki article I linked to.

 *Quote:*   

> I'm pretty sure that my filesystem is badly fragmented. How do defrag it? I use ext3.

 

The first thing to do is to move /usr/portage into its own small-block xfs partition since it is well known to cause massive fragmentation.  I think you might want /var on its own partition as well.

If you have a large enough spare partition then defragging is very easy.  Boot with the install cd, mount your root partition and your spare partition and then use the "cp -a" command to copy everything on the root partition to the spare.  Add a new entry in grub.conf and adjust your new /etc/fstab and you are in business.  If you made a mistake, you can still boot into your old root.

But I must warn you.  Even with a perfectly de-fragged disk, your boot time will still be dominated by disk seeks.  That's because all the programs that are starting up along with all their config files and libraries would still be spread all across a perfectly de-fragged disk so there will still be a ton of seeks.  Of all the things controlling your boot time, disk seeks are the only thing that haven't really benefitted from Moore's Law.  I've got a laptop that is ten times faster than a super computer I was using in the early 90's but seek times haven't changed much, maybe by a factor of 3 at best.

This is why suspend is the perfect solution for your problem.  The memory image is stored on disk in one big contiguous file.  Your boot time will no longer be limited by disk seek time, it will instead be limited by either disk throughput or CPU.   Suspend can offer you speed gains that are unattainable with either tweaking init or defragging.

----------

## zx2c4

These are excellent points. I will certainly look into suspend.

Also -- why is there no process activity until about 9 seconds in?

----------

## BitJam

 *zx2c4 wrote:*   

> why is there no process activity until about 9 seconds

 

I think that no processor activity is being reported because the part of your system that lets CPU activity be monitored isn't working until 9 seconds in.

----------

## zx2c4

What about init starting at 9 seconds in as well?

----------

## BitJam

Same deal.  If your computer was instantly all set to work then your boot time would be zero.  Init is the first userland process to run (I think) but if you scroll down in the graph you posted you will see that the kernel is busy getting things set up before then.

----------

## i92guboj

 *BitJam wrote:*   

> Same deal.  If your computer was instantly all set to work then your boot time would be zero.  Init is the first userland process to run (I think) but if you scroll down in the graph you posted you will see that the kernel is busy getting things set up before then.

 

It is, so that point is totally valid.

[quote="BitJam"] *zx2c4 wrote:*   

> 
> 
> If you have a large enough spare partition then defragging is very easy.  Boot with the install cd, mount your root partition and your spare partition and then use the "cp -a" command to copy everything on the root partition to the spare.  Add a new entry in grub.conf and adjust your new /etc/fstab and you are in business.  If you made a mistake, you can still boot into your old root.
> 
> But I must warn you.  Even with a perfectly de-fragged disk, your boot time will still be dominated by disk seeks.  That's because all the programs that are starting up along with all their config files and libraries would still be spread all across a perfectly de-fragged disk so there will still be a ton of seeks.  Of all the things controlling your boot time, disk seeks are the only thing that haven't really benefitted from Moore's Law.  I've got a laptop that is ten times faster than a super computer I was using in the early 90's but seek times haven't changed much, maybe by a factor of 3 at best.

 

This is where i/o schedulers come in handy. They reorder the i/o operations so they are read in a more efficient way. Still, in a big disk, it is just impossible to keep the drive busy in a smart manner all the time. The only way to really speed this up is to use raids with redundant hard drives. No SATA, SCSI or anything can make such a mechanical component faster, even if they try hard. Mechanical components are not like chips. A chip usually has an access time measure in nanoseconds, they usually vary between n*10^-9 (nanoseconds) and n*10^-11.

Mechanical devices like harddrives has, at best, an access time measured in miliseconds (n*10^-3), and sometimes, even slower times (n*10^-2). That means they are inherently, from one to many hundreds (or even thousands) million times slower than any silicon based device. And that is just the access time. When we talk about seek times the thing is worse. Mechanical beings have to move, electronic ones do not. And electrons on a semiconductor move very fast  :Razz: 

 *Quote:*   

> This is why suspend is the perfect solution for your problem.  The memory image is stored on disk in one big contiguous file.  Your boot time will no longer be limited by disk seek time, it will instead be limited by either disk throughput or CPU.   Suspend can offer you speed gains that are unattainable with either tweaking init or defragging.

 

No need to add anything here. The faster your hd is, the faster your system will load. Here, seek times are not that important either, because the image is usually stored in a swap partition or something like that. So the image in in contiguous sectors.

----------

## zx2c4

 *i92guboj wrote:*   

>  *BitJam wrote:*   Same deal.  If your computer was instantly all set to work then your boot time would be zero.  Init is the first userland process to run (I think) but if you scroll down in the graph you posted you will see that the kernel is busy getting things set up before then. 
> 
> It is, so that point is totally valid.
> 
> 

 

Is there anyway to speed up the kernel? Any options that should be different? http://data.zx2c4.com/config-2.6.22-gentoo-r8

 *Quote:*   

> This is where i/o schedulers come in handy. They reorder the i/o operations so they are read in a more efficient way. Still, in a big disk, it is just impossible to keep the drive busy in a smart manner all the time. 

 

Is there anyplace where this could be optimized, or does the standard kernel have the best options already set?

----------

## i92guboj

 *zx2c4 wrote:*   

>  *i92guboj wrote:*    *BitJam wrote:*   Same deal.  If your computer was instantly all set to work then your boot time would be zero.  Init is the first userland process to run (I think) but if you scroll down in the graph you posted you will see that the kernel is busy getting things set up before then. 
> 
> It is, so that point is totally valid.
> 
>  
> ...

 

Not significantly. You can edit the kernel makefile to insert "vodoo magic" cflags, if that is what you meant. Not worth the trouble if you ask me.

Also, note that you are talking about speeding up the boot process. During the boot process, the kernel needs time to initialize the devices. There is no way around that. The only thing you can do, is to try not to compile in the kernel stuff that you will not use. So, these devices will not be probed. That will save you a few milliseconds  :Razz: 

Besides that, the only way to make a kernel faster that I know is to buy a faster machine.

 *Quote:*   

> 
> 
>  *Quote:*   This is where i/o schedulers come in handy. They reorder the i/o operations so they are read in a more efficient way. Still, in a big disk, it is just impossible to keep the drive busy in a smart manner all the time.  
> 
> Is there anyplace where this could be optimized, or does the standard kernel have the best options already set?

 

This is a bit taken from your config,

```

#

# IO Schedulers

#

CONFIG_IOSCHED_NOOP=y

CONFIG_IOSCHED_AS=y

CONFIG_IOSCHED_DEADLINE=y

CONFIG_IOSCHED_CFQ=y

CONFIG_DEFAULT_AS=y

# CONFIG_DEFAULT_DEADLINE is not set

# CONFIG_DEFAULT_CFQ is not set

# CONFIG_DEFAULT_NOOP is not set

CONFIG_DEFAULT_IOSCHED="anticipatory"

```

You can change the default scheduler there and test. But it is not going to have a big impact on boot time. You can also pass the elevator=<scheduler> parameter to your kernel on grub.conf. I want you to understand one thing: none of this is better under every circumstance. None at all. It is was, it would be the only one, because the rest of them would be useless.

CFQ is nice for desktop environments because it is supposed to be the most fair scheduler in that circumstances. It is intended to be the most adequate to improve interactivity. This is the opposite to raw performance on a single task, which is what you are aiming for. Anyway, at bootup, there's no multitasking at all.

----------

## absozero

```
parallel startup is not good
```

why?

----------

## Matteo Azzali

Same for me, I'm using parallel startup since months and nothing went wrong.

I'm on x86 and this is the list of my init scripts:

```
           alsasound |      default

            bootmisc | boot

             checkfs | boot

           checkroot | boot

               clock | boot

         consolefont | boot

               cupsd |      default

                dbus |      default

                hald |      default

              hdparm | boot

            hostname | boot

            iptables |      default

             keymaps | boot

         kmyfirewall |      default

               lircd |      default

          lm_sensors |      default

               local |      default

          localmount | boot

             modules | boot

               mysql |      default

            net.eth0 |      default

              net.lo | boot

            netmount |      default

            rlocated |      default

           rmnologin | boot

              serial | boot

           syslog-ng |      default

             urandom | boot

          vixie-cron |      default

                 xdm |      default

```

I also noticed that the speed difference between sysvinit parallel and other

init system (initng, einit) seems to be less than 10 seconds in my system

(I don't know and don't ask me why, I just noticed that, even if there's people

claiming to have 10 seconds boot with those init systems, my results are different.....)

PS: baselayout 1 here, with version 2 things may beahave differently.

Also, when you want to change some important package, bugzilla for it, to check

what could give issues.

----------

## zx2c4

 *i92guboj wrote:*   

> 
> 
> CFQ is nice for desktop environments because it is supposed to be the most fair scheduler in that circumstances. It is intended to be the most adequate to improve interactivity. This is the opposite to raw performance on a single task, which is what you are aiming for. Anyway, at bootup, there's no multitasking at all.

 

Very interesting. I will certainly mess with these.

My rc-update show:

```
zx2c4@tux ~ $ sudo rc-update show

             bootmisc | boot

              checkfs | boot

            checkroot | boot

                clock | boot

          consolefont | boot

                cupsd |      default

             hostname | boot

              keymaps | boot

                local |      default nonetwork

           localmount | boot

              modules | boot

             net.eth2 |      default

               net.lo | boot

            net.wlan0 |      default

             netmount |      default

             nxserver |      default

            rmnologin | boot

                 sshd |      default

            syslog-ng |      default

              urandom | boot

              volfixd |      default

                  xdm | boot

```

Any suggestions on what I can remove or change?

----------

## i92guboj

 *zx2c4 wrote:*   

> 
> 
> My rc-update show:
> 
> ```
> ...

 

Those are the ones I'd better leave untouched always:

```
zx2c4@tux ~ $ sudo rc-update show

             bootmisc | boot

              checkfs | boot

            checkroot | boot

                clock | boot

          consolefont | boot

             hostname | boot

              keymaps | boot

                local |      default nonetwork

           localmount | boot

              modules | boot

             net.eth2 |      default

               net.lo | boot

            net.wlan0 |      default

             netmount |      default

            rmnologin | boot

              urandom | boot

```

Those are the ones that are not that critical

```

                cupsd |      default

             nxserver |      default

                 sshd |      default

            syslog-ng |      default

                  xdm | boot

```

If you don't need printers, take out cupsd.

If you don't need ssh or nx, take them off.

Taking out syslog will save you about 0.5 seconds on startup by increasing your debug times by a hundred thousand percent when fixing issues with your system. 

Xdm is not necesary of course, and it will be taking the biggest amount of time, probably. If boot time is that relevant for you, consider loging on console, or use qingy: http://qingy.sourceforge.net/ (framebuffer required).

----------

## albright

 *Quote:*   

> Taking out syslog will save you about 0.5 seconds on startup by increasing your debug times by a hundred thousand percent when fixing issues with your system. 

 

That is true, except it's not hard to turn logging back on if trouble

arises. 

Turning off logging lets my laptop put the harddrive to sleep

better (I know you can fiddle with laptop-tools, but that makes

my computer "stutter" in annoying ways).

----------

## i92guboj

 *albright wrote:*   

>  *Quote:*   Taking out syslog will save you about 0.5 seconds on startup by increasing your debug times by a hundred thousand percent when fixing issues with your system.  
> 
> That is true, except it's not hard to turn logging back on if trouble
> 
> arises. 
> ...

 

You are right if you speak about a stable machine that is a laptop. Having things like logs or p2p on these machines virtually disables any chance to sleep (though I personally would just use a flash drive for logs or something).

But here we are talking about a very experimental system, where logs can probe valueble to diagnose any breakage. In my opinion, that 0.5 (if at all) doesn't worth the trouble at all. But it is just my opinion. Your case is completely different.

----------

## zx2c4

I was not aware of the hazards of using a logger with a laptop. The computer I'm wondering about is, in fact, a laptop. Can one of you elaborate on the effects of a logger with harddrive sleeping etc?

Also: qingy seems like a cool idea. I will look into it. Anything I should know about it?

----------

## i92guboj

 *zx2c4 wrote:*   

> I was not aware of the hazards of using a logger with a laptop. The computer I'm wondering about is, in fact, a laptop. Can one of you elaborate on the effects of a logger with harddrive sleeping etc?

 

Loggers are always writing things here and there, even when the pc is iddle. And each time you write or read, your hd sleep time is reseted. So, it virtually never sleeps. And so, it drains your battery. Still, I wouldn't shut it off while you are experimenting. If you want to avoid this while having the logger on, just put all the logs into a flash device or something like that. Then you can just link /var/log or mount -obind it to wherever you put the files.

 *Quote:*   

> 
> 
> Also: qingy seems like a cool idea. I will look into it. Anything I should know about it?

 

Qingy works on top of framebuffer, rather than X. So, you don't need that xdm anymore.

Qingy has a dropdown menu where you can choose what session to start. You can choose to start on console, or you can choose to start any x session (kde, gnome...). Of course, you can log with any user. It also features themes, screensavers and I don't know what else. 

It sits on top of directfb. So, if you have framebuffer enabled in your kernel and directfb works ok for you, you should be ok to run conky. You have to erase the xdm task from the rc-update list. After that, use the instructions on the qingy's web to set it up. It just involves a slight change in your inittab and nothing else as far as I can remember.

Beware (and the qingy docs warn you as well about this, I think) that you shouldn't use qingy in all your ttys, at least, until you checked that it works ok for you. Leave at least one tty with the regular login system. So, if for some odd reason qingy doesn't work ok with your hardware/framebuffer, you will still be able to login in your getty console.

Using qingy you will shorten your boot time since xdm will not be loaded. But of course, X will be loaded after you login unless you selected a console session.

Still, you save the time to load biggies like kdm or gdm. Conky is a small program.

----------

## zx2c4

XDM adds on only 3 seconds. :-\

http://data.zx2c4.com/bootchart_nox.png

----------

## i92guboj

 *zx2c4 wrote:*   

> XDM adds on only 3 seconds. :-\
> 
> http://data.zx2c4.com/bootchart_nox.png

 

Well, 3/25=0.12, which is an "improvement" of 12%. Not bad.

Besides that number, that I consider completely useless, I don't know if that tool is completely infalible.

xdm launches startDM.sh, which in turn launches some other stuff. Xdm is lunched at a given time, and X never returns (the xdm keeps itself open and is launched in the background). In fact, it launches in another term. That 3 seconds tells you that the script takes 3 seconds to be launched. But that doesn't mean that x+kdm or gdm is loaded in another completely virtual terminal by that time. So, it is "just another useless number".

----------

