Tiny Core Linux
General TC => General TC Talk => Topic started by: P5music on January 11, 2011, 06:24:58 AM
-
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.
-
Why should it be a separate iso, shouldn't everyone benefit from fast boots?
-
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?
-
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:
[ 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
-
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..?
-
@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.
-
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* ;)
-
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.
-
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.
-
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).
-
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?
-
a very fast booting distro is http://www.xpud.org/ (http://www.xpud.org/)
-
"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.
-
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.
-
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).
-
"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.
Booting a PC uses a lot of resources and energy, so suspend to disk instead of shutdown and (a later) boot could actually save energy.
With suspend to RAM there would be a certain threshold of time at which either shutdown would use more or less energy in comparison. My estimated guess would be that 2 boots a day may use more energy than suspending to RAM.
-
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).
Such is unavoidable with a stock kernel having to work with a wide range of hardware.
You could tune behavior of kernel to a certain degree at boot time with optional parameters:
http://www.kernel.org/doc/Documentation/kernel-parameters.txt
YMMV ;)
-
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).
I think that with recent hardware it accounts for a very little extent respect to uncompressing data in RAM, creating filesystem, creating dev directory, module loading and timeouts.
loading extensions "onboot" could make up for the vast part of differences of boot times.
indeed fast boot would encompass remastering; at least "tclocal" trick should be used (I fear both do not work for every combination of extensions).
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.
I think, as well as the member I answered, that we can say tinycore handles backup/restore in a fashion similar to a boot/init script. The meaning was that.
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 was addressed by Hiroki Kaminaga (I know just his work, I don't know others) in "Improving Linux Start Time Using Software Rescue". It gains just 50% time.
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.)
You are talking about "coreboot" project. But I do not think it is a useful way: kernel patching is the most easy and effective way to gain boot speed, then also init scripts have to be customized.
Grub is typically used, but which bootloader is the FASTEST?
It seems that some time can be gained also patching the boot loader. It has to be investigated.
With suspend to RAM there would be a certain threshold of time at which either shutdown would use more or less energy in comparison. My estimated guess would be that 2 boots a day may use more energy than suspending to RAM.
the king of all tricks would be storing a RAM image of a booted system and loading it at boot then jump to a suitable kernel routine. But it is not clear if devices would be initialited. This could be solved with a quick "wake-up" routine.
In fact the entire boot process could be re-thought but it would remain a linux system I think.
-
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).
I think that with recent hardware it accounts for a very little extent respect to uncompressing data in RAM
If that is what you really believe, then you can just use the cpio archive without compression, avoiding the step of uncompression at boot, at a cost of having to read a bigger size of data.
-
very instructive to watch this in detail:
http://www.slideshare.net/andrewmurraympc/elce-the
-
I'm a nobody when it comes to these things but I do remember I've read how they do it in ROM when they do linux almost instant on for Asus and others that have a dualboot option.
They already know the hardware so they don't have to do all the searching a general os need to do to determine what hardware there is.
So one way to achieve it would be to first get to know the computer it is supposed to boot from and then the internal script change the boot so it act like those premade fast boot up in Asus?
Am I too naive maybe. But would it not work to have a slow first time during frugal install and then next time a super fast boot?
Xpud are one of the fast one as I remember.
-
I found this interesting too:
www.microsoft.com/windowsembedded/en-us/products/westandard/default.mspx
http://www.youtube.com/watch?feature=player_detailpage&v=Xay8nE6GusA
http://www.youtube.com/watch?feature=player_detailpage&v=87LHizlgDQk
-
Not sure how an advertisement text for "Windows Embedded Standard 7" could be related to TC...
And the titles of both of those videos are misleading refering to "boot" when they obviously show resuming instead.
-
I found this interesting too:
www.microsoft.com/windowsembedded/en-us/products/westandard/default.mspx
http://www.youtube.com/watch?feature=player_detailpage&v=Xay8nE6GusA
http://www.youtube.com/watch?feature=player_detailpage&v=87LHizlgDQk
Out of curiosity, when finding a chance I hibernated a win XP install on a 9 year old laptop, and resuming took... 6 seconds - same as in that "record breaking" video :P
(And that's with a 5400rpm hdd)
-
obviously
, so this is a misunderstanding caused by the guys' mistake... Uhm, I don't think so.
However probably they could have used also the "Hibernate Once Resume Many (HORM)" feature of WES7.
But no need to guess that, other videos are available about genuine boot.
(this is in a virtual machine; note: WES=XP embedded)
http://www.youtube.com/watch?v=aZ2iEj12Wos&feature=player_detailpage
(this is on a probably slow device)
http://www.youtube.com/watch?feature=player_detailpage&v=c8Q4h1u-bgA
-
Hibernate once, resume many? I don't see much point in that on a general purpose computer. Then again, that's been done for years already on Canon cameras (they run linux :)).
-
Hibernate once, resume many? I don't see much point in that on a general purpose computer. Then again, that's been done for years already on Canon cameras (they run linux :)).
Couldn't the same be said for firmware images of type OpenWRT et al, or even some others shipped by manufacturers of various embedded devices?
-
Then again, that's been done for years already on Canon cameras (they run linux :)).
Originally, The ASIC in Canon cameras was x86-compatible and ran Datalight ROM-DOS (http://findarticles.com/p/articles/mi_m0EIN/is_1999_Feb_23/ai_53930374/). The next version of the ASIC migrated to 32-bit ARM and VxWorks (http://en.wikipedia.org/wiki/DIGIC#Custom_firmware). Since 2007, the cameras run DryOS (http://www.canon.com/technology/canon_tech/explanation/dryos.html), an operating system with a 16KB kernel developed internally at Canon.
-
Originally, The ASIC in Canon cameras was x86-compatible and ran Datalight ROM-DOS (http://findarticles.com/p/articles/mi_m0EIN/is_1999_Feb_23/ai_53930374/). The next version of the ASIC migrated to 32-bit ARM and VxWorks (http://en.wikipedia.org/wiki/DIGIC#Custom_firmware). Since 2007, the cameras run DryOS (http://www.canon.com/technology/canon_tech/explanation/dryos.html), an operating system with a 16KB kernel developed internally at Canon.
Hm, maybe my memory is faulty. I do think it was Canon, but maybe it was another camera manufacturer.
-
obviously
, so this is a misunderstanding caused by the guys' mistake... Uhm, I don't think so.
However probably they could have used also the "Hibernate Once Resume Many (HORM)" feature of WES7.
But no need to guess that, other videos are available about genuine boot.
(this is in a virtual machine; note: WES=XP embedded)
http://www.youtube.com/watch?v=aZ2iEj12Wos&feature=player_detailpage
Another video which does not really reveal anything regarding to boot time...
That guy attempts to shutdown windows before it has finished booting and then wonders why it takes longer to shutdown than to boot... easily reproducible