innovating Tinycore proposal - preliminary poll

[P5music]

Hello,
this thread is about the possibility of creating a third stem of Tinycore (along with microcore.iso and tinycore.iso) focused on boot time optimization, aiming to reach near "instant boot" (in a perspective view).

It is an amazing endeavour for Tinycore because:
"The time that a product takes to boot directly impacts the first perception an end user has of the product. Regardless of how attractive or well designed a consumer electronic device is, the time required to move the device from off to an interactive, usable state is critical to obtaining a positive end user experience. Turning on a device is Use Case #1."

this is from
http://elinux.org/Boot_Time

In this page you will find many suggestions about the possible optimization: many are very feasible, especially on recent hardware (that all of us have, along with old PCs).

So this thread is like a poll. You are encouraged to say your opinion, in particular about what method you consider effective or feasible, or the way it should be implemented.
You also could post dmesg output excerpts (syslog printk.time=1 boot options) in order to point out which steps slow down your boot. You will find that many of those delays are unreasonable and you can know why reading the above mentioned web page or reading documentation about linux boot process, available on the web.

It's an opportunity for Tinycore to be the innovation leader in this field. It is coherent with Tinycore's phylosophy: the boot time is the first reason one likes Tinycore in the first time.

You are wrong if you are thinking that hidden laboratories of smart companies with geeks inside are working on this. Many embedded devices that are sold like commercial products are slow to boot, some are slower than PC boots and corresponding application loads.

[curaga]

Why should it be a separate iso, shouldn't everyone benefit from fast boots?

[jerramy]

I fully support the quest to achieve as close to instant boot as possible. I'd like to see where this topic goes, and hope that any good suggestions are integrated into Tiny Core's main release.  I agree that boot time is a cruicial first impression made.

I must say that Tiny Core is already the fastest booting linux I've found.  It seems to me (though I haven't compared recently) that it's faster than the other two or three competing products.

If dmesg were modified to include timestamps, it would aid in the profiling of bootup.  What other logs are available?  Does the stuff "quiet" suppresses go somewhere, or is that just dmesg?

[P5music]

Why should it be a separate iso, shouldn't everyone benefit from fast boots?

It'd better start as experimental Tinycore side-project. There are issue to solve, I do not think it can work on every kind of hardware Tinycore works on now, just from start. However it has to be investigated.

If dmesg were modified to include timestamps, it would aid in the profiling of bootup.

you have to use
"syslog printk.time=1" boot options
maybe you have to drop the "quiet" option too.
here's an example from my system:

Code: [Select]

[    0.272718] Trying to unpack rootfs image as initramfs...
[    0.483556] Freeing initrd memory: 8241k freed

[    0.886042] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    3.897038] floppy0: no floppy controllers found

[    3.898416] Probing IDE interface ide0...
[    4.433376] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

[    4.433481] Probing IDE interface ide1...
[    4.966706] ide1 at 0x170-0x177,0x376 on irq 15

[    7.744081] Adding 760844k swap on /dev/ramzswap0.  Priority:-1 extents:1 across:760844k SS
[   10.725731] scsi 6:0:0:0: Direct-Access     Generic- Multi-Card       1.00 PQ: 0 ANSI: 0 CCS

[   10.730078] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[   11.294334] scsi 7:0:0:0: Direct-Access     Generic  USB SD Reader    

[   11.296234] sd 7:0:0:1: Attached scsi generic sg4 type 0
[   11.963721] sd 7:0:0:1: [sdd] Attached SCSI removable disk

[   11.972410] sd 7:0:0:0: [sdc] Attached SCSI removable disk
[   16.856770] generic-usb 0003:14AA:0226.0001: timeout initializing

[   17.011500] generic-usb 0003:062A:0000.0002: input: USB HID v1.10 Mouse [HID 062a:0000] on usb-0000:00:1d.7-1.4/input0
[   18.030920] sky2 eth0: enabling interface

[floppy]

I found a thread in this forum which files to be excluded from backup/restore (this backup/restore step is part of a booting). This is one aspect of gaining speed.
An aspect I wanted to have a look (when I have time) is to use CPU tools available in the extensions. Perhaps something can be done there. So, if somebody has an Idea how gaining speed with an AMD K6-2 450MhZ..?

[maro]

@P5music: I believe it would be helpful if you would edit all your posts where you are misspilling the required boot code: it is printk.time=1 (instead of 'printk.times=1') what users could use to gain timestamps for the kernel boot phase.

[tinypoodle]

You also could post dmesg output excerpts (syslog printk.times=1 boot options) in order to point out which steps slow down your boot. You will find that many of those delays are unreasonable

TC appears to me so much resources usage optimized that with all my various setups I have never noted any potential of unreasonable delay at boot time except from:
1. Restoring unnecessary files contained in backup.
2. Loading extensions onboot which are not necessary (though latter might bring more convenience for some users).

Various features which are not needed by a user - though far from creating unreasonable  delay - could be disabled by according boot codes, e.g. those starting with a no*   

[floppy]

Hello,
this thread is about the possibility of creating a third stem of Tinycore (along with microcore.iso and tinycore.iso) focused on boot time optimization, aiming to reach near "instant boot" (in a perspective view).

my next try will be to install a flash card on IDE adapter (for OS).
A second IDE + flsh card with the TCE could perhaps help.
For my privat use, I will stop there.
Except an extension would be made for system-optimization.
Lets see if the industry do something: I expect yes.

[P5music]

Various features which are not needed by a user - though far from creating unreasonable  delay - could be disabled by according boot codes, e.g. those starting with a no*   

hey, you could add this to the list at http://elinux.org/Boot_Time

Lets see if the industry do something: I expect yes.

uhm, I think that industry will follow customer's bad habit to keep his/her computer on forever. In the future that could be not sustainable or smart at all. I tried (along with suspend/hibernate) and my system ends up losing interfaces or other problems and has to be rebooted  in the end a lot of times. No Mac makes exception.

my next try will be to install a flash card on IDE adapter (for OS).

the sinergy between this tricks and kernel patching/optimization could achieve great results.

However I think a try should be given to patching kernel about ide-timeout (+ the "force ide no probe" patch).
New boot options could be created: ide_timeout= for example, so the user can experiment on his/her system.

Also all that "SCSI" logging should be checked out.

I found a thread in this forum which files to be excluded from backup/restore (this backup/restore step is part of a booting). This is one aspect of gaining speed.

The first step is the kernel side of boot, init scripts are a less difficult enterprise, I think.

[tinypoodle]

Various features which are not needed by a user - though far from creating unreasonable  delay - could be disabled by according boot codes, e.g. those starting with a no*  

hey, you could add this to the list at http://elinux.org/Boot_Time

No, i had the TC specific boot "cheat" codes in mind, sorry if I was not specific about that.

uhm, I think that industry will follow customer's bad habit to keep his/her computer on forever. In the future that could be not sustainable or smart at all. I tried (along with suspend/hibernate) and my system ends up losing interfaces or other problems and has to be rebooted  in the end a lot of times. No Mac makes exception.

I cannot understand what you mean by "No Mac makes exception." and how that is related to context.
Would you care to elaborate?

I found a thread in this forum which files to be excluded from backup/restore (this backup/restore step is part of a booting). This is one aspect of gaining speed.

The first step is the kernel side of boot, init scripts are a less difficult enterprise, I think.

I could not see how housekeeping of the backup which is in the direct personal responsibility of the user would be related to init scripts.

Having booted TC over times with various setups, my impression is that size of backup and loading extensions "onboot" could make up for the vast part of differences of boot times.
It is very simple - and applies for all operating systems - the bigger the size of data which has to be read at boot time is, the longer the boot time.  
Of course it is not without importance at which speed the data is read (difference of boot media).

[jerramy]

Interestingly, I saw a post on Slashdot recently, about a 1 second linux boot.  There was an extensive video.  He'd push the reset button, the screen would flicker, and old ghost (from the previous run) would flash on the screen, and then things were populated again.  but it was more of a "1 second to an applicataion" sort of thing, I don't know about it being a full OS.  Really it was just for home automation.

Here's my idea of how the fastest possible (by defintion) operating system should work.

    When it resets, the PC is set to some fixed starting address. 
000 Registers may or may not be cleared at this point, so the first thing that should happen is that all registers should be cleared.
001 The bare minimum needed to interface to some storage device and the full range of RAM needs to be initiated.
010 Data is copied (at max speed possible) from hd0 to RAM.  The smaller this file, the faster it'll boot.
500 Registers are set to what is indicated by file from disk.
510 PC set to origin of in RAM.
511


This might be a vast simplication of the process, but the point is that what is typically done by the BIOS, needs to be done by the bootloader.  The more the bios can get out of the way the better.  Or rather, ideally the bootloader would be in the BIOS, and not in the MBR (why do we need that thing again?  It seems unnecessary.)

But since there are so many BIOSes out there, linux typically uses a bootloader in the MBR, which is what BIOS points to when it's done.  So since we're stuck with that, you probably would want to disable EVERYTHING you can in BIOS.  You want the bootloader to be a minimal as possible, and we want it to pick up at step 001 or maybe 010.

The truth is, TinyCore linux, from the time I see something that's clearly it talking, and not the bootloader doing something, is quite fast.  Most of my lost time is in the BIOS and the bootloader.

Grub is typically used, but which bootloader is the FASTEST?

[jls]

a very fast booting distro is http://www.xpud.org/

[thane]

"Of course it is not without importance at which speed the data is read (difference of boot media)."

Yes, I actually got the biggest drop in boot time when I went from running TC on a box with USB 1.1 to one with USB 2.0.

FWIW, boot time is not a top priority issue with me. At most I boot/shutdown twice a day (often without saving anything on shutdown if I haven't updated any preferences etc.), or even only once a week if I'm being less anal about not wasting energy.

[jerramy]

By disabling a lot of stuff in BIOS, and playing with kernel options, I got the BIOS and bootloader time down pretty good (under a second for each approx).  What ended up taking most of the time was the kernel (about 5 to 7 seconds). TinyCore stuff took maybe 2 or 3 seconds.  Unfortunately, my wifi doesn't work anymore (probably a BIOS setting for PCI I disabled), though  that's easily fixed.

While it's likely that TinyCore portion can be cleaned up slightly, what I noticed as taking the most of the time was silly stuff the kernel was searching for that I didn't have  (there's floppy support, even though my computer doesn't have a floppy drive).  If some of that stuff could be modprobed later instead, maybe that portion of the boot process could be hastened.

[tinypoodle]

But since there are so many BIOSes out there, linux typically uses a bootloader in the MBR, which is what BIOS points to when it's done.

That is only one out of many possible scenarios to boot linux.
BIOS is most of all needed to determine from what medium to boot (and by which priority).