On Tuesday, March 11, 2014 13:27:25 Yamaban wrote:
On Tue, 11 Mar 2014 12:20, Jason
wrote: Hi Yamaban,
<snip>
Look into your /boot dir, add the size of your kernel and your initrd.
Look at the specs of your disk, continous transfer-rate, take about 60% of that (some UEFI implemtations are a little better and reach 80%).
Insufficient data to perform calculation. Based on what should I take 60 or 80% percent?
either your disc datasheet (Manfufac.Website->DiscModell->Tech.data) or by using hdparm -t [/dev/your-disc] e.g. /dev/sda, please see "man hdparm" beforehand.
"continous transfer-rate" means transfers bejond internal disc-cache, e.g. more than 64MB. "hdparm -t" does that.
This transfer-rate is measured with good drivers in a working OS. UEFI / BIOS use "barebones" essential generic dirvers to access the disc and thus reach at max 60% (most BIOS, early UEFI) to 80% (best BIOS, some recent UEFI) of that maxima.
the only thing I see here affecting the boot is what driver is in use, IDE, AHCI etc, but that would affect the whole of system.
Divide the sum of kernel and initrd by the reduced transferrate.
Now you have the pure time it takes to load the kernel and the initrd into memory.
If you take a older Laptop HDD (27 MB/s) and a newer SSD (150MB/s) the difference looks big, but the size of the kernel+initrd is not that big that the difference will make more than one (1) second of boot time.
This is simply not true.
I've had a 3.5" HDD with 30 MB/s and now a SSD with 120 MB/s. the time from end-of-grub to begin-kernel-init didn't shink to 25% (theoretical) but reached 30% (still good, IO saturation)
At a kernel of 4.5 MB and a initrd of 10.5 MB that makes:
15 MB / 30MB/s = 0.5 sec 15 MB / 100MB/s = 0.15 sec
"BIG" difference. This is the time it takes for the boot-loader (grub/grub2/lilo/gummiboot/syslinux/etc) to load the kernel and its initrd into memory.
Then the boot-loader starts / executes the kernel.
Ok, i think I see where is the problem in this discussion.
After the kernel is loaded, the BIOS / UEFI will give control to the kernel, which initializes the HW with its drivers. Here comes the kernels own IO routines to play.
Now the kernel loads the rest of the OS with its own (optimized) routines.
And here most of the Disk I/O of the Boot / Restore process happens.
Restore after hibernate happens after the kernel initalises all the hardware, then the 'hibernate' image is loaded from the swap partition. In most cases the size of this image is about 1/4 to 1/2 of the size of the RAM. 4BG RAM => 1GB to 2GB to transfer from disc into memory Sample for 1GB:
1000MB / 30MB/s = 33.33 sec 1000MB / 100MB/s = 10 sec
Now, this is really felt and experienced difference.
I have misunderstood.
For a 'normal' / full boot the summed size of all transfers is about the same, but more spread out and mixed in between the start-up of all the different services needed.
Still, the most 'win' a SSD brings in full boot is the missing seek-times due to having no moving parts.
No.
BIOS/UEFI btl> secondary bootloader> Init> kernel > userspace
Please correct this in Your notes:
BIOS/UEFI btl> secondary bootloader> (load kernel+initrd into mem) > start kernel > Init > deamons (userspace) > Ready-to-use
Ok. I knew that but somehow misunderstood at some point.
BIOS/UEFI ctl is relinquished moment it hands over to secondary btl. Exception is in some cases where thermal tables of the _hardware_ can be changed during run time by UEFI and few other bits, but nothing related to actual boot.
This differs from model to model. For some models the BIOS / UEFI data is discarded, and later reloaded by the BIOS / UEFI kernel-driver. For other the "secondary bootloader" has to hand trough the data, or the kernel could not start correctly (later reload fails, mostly older model, or 'mobiles')
In the end what I'm trying to communicate is:
The most speed-up a SSD vs a HDD gives, is after the kernel and the initrd it self is loaded. And this is proven.
Agreed, I took it as actual full system boot somehow (up until userspace), not that you're talking about kernel unpacking/transfer to RAM. That said, it is really negligible what you pointed out. I'm using SSDs since 5yrs ago and couldn't go back to HDD at this point. The actuall boot got from 45 sec to 15 sec to usable desktop, depending on the machine. Therefore my inital comment. I'm sorry for the confusion. To extend, I might have approached this topic with you with prejudice that was based on 20% non-partitioned space and daily chron job for trimming:) So I'm sorry for that too.
- Yamaban.
Kind regards, Jason -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org