Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #9153 > unrolled thread

Oh for the days of fast boot

Back to article view | Back to alt.os.development

Contents

  Oh for the days of fast boot James Harris <james.harris.1@gmail.com> - 2016-01-28 14:36 +0000
    Re: Oh for the days of fast boot JJ <jj4public@vfemail.net> - 2016-01-29 06:45 +0700
    Re: Oh for the days of fast boot Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-28 19:31 -0500
      Re: Oh for the days of fast boot "wolfgang kern" <nowhere@never.at> - 2016-01-29 11:06 +0100
        Re: Oh for the days of fast boot James Harris <james.harris.1@gmail.com> - 2016-01-29 15:47 +0000
          Re: Oh for the days of fast boot "wolfgang kern" <nowhere@never.at> - 2016-01-29 20:53 +0100
            Re: Oh for the days of fast boot James Harris <james.harris.1@gmail.com> - 2016-01-30 10:57 +0000
              Re: Oh for the days of fast boot "wolfgang kern" <nowhere@never.at> - 2016-01-30 21:49 +0100
                Re: Oh for the days of fast boot James Harris <james.harris.1@gmail.com> - 2016-01-30 23:46 +0000
                  Re: Oh for the days of fast boot "wolfgang kern" <nowhere@never.at> - 2016-01-31 10:48 +0100

#9153 — Oh for the days of fast boot

OS booting these days can be very slow. By contrast here is a reminder 
of how quickly computers used to boot:

   https://www.youtube.com/watch?v=cirDDXisVAg

As you can see, finding the switch is the bit that took most time. :-)

James

[toc] | [next] | [standalone]

#9154

On Thu, 28 Jan 2016 14:36:30 +0000, James Harris wrote:
> OS booting these days can be very slow. By contrast here is a reminder 
> of how quickly computers used to boot:
> 
>    https://www.youtube.com/watch?v=cirDDXisVAg
> 
> As you can see, finding the switch is the bit that took most time. :-)
> 
> James

It also remind you that older electronic devices are more durable than the
current one. There no way current computers could survive after taking all
those suffering.

[toc] | [prev] | [next] | [standalone]

#9156

On Thu, 28 Jan 2016 14:36:30 +0000
James Harris <james.harris.1@gmail.com> wrote:

> OS booting these days can be very slow. By contrast
> here is a reminder of how quickly computers used to boot:
> 
>  [link]
> 
> As you can see, finding the switch is the bit that
> took most time. :-)

DOS still boots quickly.  This machine takes 23 seconds
to cold boot DOS, i.e., BIOS + DOS, from a SATA hard disk,
with a bunch of drivers and some file deletions, etc.
I'm sure that would be much, much slower on an IBM AT.

64-bit Linux plus machine start up here takes 42 seconds
on this machine which has parts from 2009 and boots Linux
from an SSD.  It has to be much faster than that today,
given six years and the new faster SATA protocols and SSDs.

Windows 10 is fairly quick on a different machine (2010)
with a hard disk.  It usually takes under a minute to
display the desktop which is roughly the same as my Linux
machine, except that Windows 10 also continues to load
drivers for a while after the desktop is displayed.  This
may be due to the hard disk instead of SSD.  But, it's only
that quick if you don't have "fast boot" deactivated, and
you don't have non-MS anti-virus software installed.  The
non-MS anti-virus software seems to be the largest cause
of boot up slowdown for Windows 10, e.g., taking the time
to boot to three to five minutes.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#9158

Rod Pemberton wrote:
 
>> OS booting these days can be very slow. By contrast
>> here is a reminder of how quickly computers used to boot:
>>  [link]
>> As you can see, finding the switch is the bit that
>> took most time. :-)

:) We better start counting from power switch activated. 
 
> DOS still boots quickly.  This machine takes 23 seconds
> to cold boot DOS, i.e., BIOS + DOS, from a SATA hard disk,
> with a bunch of drivers and some file deletions, etc.
> I'm sure that would be much, much slower on an IBM AT.

> 64-bit Linux plus machine start up here takes 42 seconds
> on this machine which has parts from 2009 and boots Linux
> from an SSD.  It has to be much faster than that today,
> given six years and the new faster SATA protocols and SSDs.
 
> Windows 10 is fairly quick on a different machine (2010)
> with a hard disk.  It usually takes under a minute to
> display the desktop which is roughly the same as my Linux
> machine, except that Windows 10 also continues to load
> drivers for a while after the desktop is displayed.  This
> may be due to the hard disk instead of SSD.  But, it's only
> that quick if you don't have "fast boot" deactivated, and
> you don't have non-MS anti-virus software installed.  The
> non-MS anti-virus software seems to be the largest cause
> of boot up slowdown for Windows 10, e.g., taking the time
> to boot to three to five minutes.

Here is what I measure on my machines (in seconds):

BIOS      8..12 vary with version (with quick memory test)
DOS 6.00      8 +1   per HD [120K](w/o EMM,XMS,CD,mouse)
KESYS004      4 +0.5 per HD [512K](with XMM,CD,mouse,etc..)
KESYS015      2 +0.3 per HD (as above and more)   

XPpro      ~200 and several minutes for everything working
win7       ~500 ditto

__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#9159

On 29/01/2016 10:06, wolfgang kern wrote:
>
> Rod Pemberton wrote:
>
>>> OS booting these days can be very slow. By contrast
>>> here is a reminder of how quickly computers used to boot:
>>>  [link]

That Commodore Pet boot was just as I remember it: it was a toss-up as 
to whether the ready prompt or the display would be there first. If the 
CRT was warm it would win. If cold, the prompt would be there first. 
Either way, the time-to-ready was no more than about 3 or 4 seconds. 
Halcyon days in comparison to modern machines.

...

> Here is what I measure on my machines (in seconds):
>
> BIOS      8..12 vary with version (with quick memory test)
> DOS 6.00      8 +1   per HD [120K](w/o EMM,XMS,CD,mouse)
> KESYS004      4 +0.5 per HD [512K](with XMM,CD,mouse,etc..)
> KESYS015      2 +0.3 per HD (as above and more)

I presume you don't need DOS to start first in order to get KESYS up and 
running. If not, your KESYS figures are very impressive indeed.

Assuming that KESYS015 is a later development of KESYS004 can you say 
what you did to make it so much faster?

James

[toc] | [prev] | [next] | [standalone]

#9160

James Harris wrote:

>>>> OS booting these days can be very slow. By contrast
>>>> here is a reminder of how quickly computers used to boot:
>>>>  [link]
 
> That Commodore Pet boot was just as I remember it: it was a toss-up as 
> to whether the ready prompt or the display would be there first. If the 
> CRT was warm it would win. If cold, the prompt would be there first. 
> Either way, the time-to-ready was no more than about 3 or 4 seconds. 
> Halcyon days in comparison to modern machines.

My olde 'Zilog PC' run at 4MHz and booted in much less than one second 
from a ROM-chip (and this was wayback in 1978).
And right, we had a 'brown-out recovery' (not more than ~50mS hw-delay).

> ...
>> Here is what I measure on my machines (in seconds):
>>
>> BIOS      8..12 vary with version (with quick memory test)
>> DOS 6.00      8 +1   per HD [120K](w/o EMM,XMS,CD,mouse)
>> KESYS004      4 +0.5 per HD [512K](with XMM,CD,mouse,etc..)
>> KESYS015      2 +0.3 per HD (as above and more)
 
> I presume you don't need DOS to start first in order to get KESYS up and 
> running. If not, your KESYS figures are very impressive indeed.

Yes, KESYS is a bootable standalone sysyem.

> Assuming that KESYS015 is a later development of KESYS004 can you say 
> what you did to make it so much faster?

beside that I learned more tricks to speed up code in general meanwhile,
the main speed gain came from lesser BIOS calls at start and KESYS015 
seem to use BIOS supported UDMA features to load the starting OS-image 
by INT13/42 instead of INT13/02. [saved alot of load time]
btw: I checked BIOS UDMA actions and found the PRDs at 09fd20 (EDBA)
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#9161

On 29/01/2016 19:53, wolfgang kern wrote:

...

> My olde 'Zilog PC' run at 4MHz and booted in much less than one second
> from a ROM-chip (and this was wayback in 1978).

On the one hand, to boot an OS these days requires much more hardware 
initialisation which will take time. On the other, all of a computer's 
components are much faster. Windows is known to be bloated so is not a 
good guide as to what can be achieved. Unix is leaner but still takes 
significant time to go through checking for and initialising each 
component. That just makes your KESYS boot times more impressive.

> And right, we had a 'brown-out recovery' (not more than ~50mS hw-delay).

I see that a brownout is a drop in voltage

   https://en.wikipedia.org/wiki/Brownout_%28electricity%29

But I am not sure why you mentioned it.

>>> KESYS004      4 +0.5 per HD [512K](with XMM,CD,mouse,etc..)
>>> KESYS015      2 +0.3 per HD (as above and more)

...

>> Assuming that KESYS015 is a later development of KESYS004 can you say
>> what you did to make it so much faster?
>
> beside that I learned more tricks to speed up code in general meanwhile,
> the main speed gain came from lesser BIOS calls at start and KESYS015
> seem to use BIOS supported UDMA features to load the starting OS-image
> by INT13/42 instead of INT13/02. [saved alot of load time]

You mean you used fewer BIOS calls and your newer BIOSes used or allowed 
you to use the faster int13/42? Interesting point. I suppose that almost 
any sensible OS initialisation will use negligible CPU time and that all 
of its startup delay will be waiting for hardware of some sort.

> btw: I checked BIOS UDMA actions and found the PRDs at 09fd20 (EDBA)

I get the feeling that you mean there is some significance to that which 
I should remember. I know we discussed the EBDA in the past. I think we 
also discussed PCI-based DMA via NCQ and PRDs. But if I was supposed to 
make a link there I missed it. Should your last comment have reminded me 
of something?

James

[toc] | [prev] | [next] | [standalone]

#9162

James Harris wrote:

>> My olde 'Zilog PC' run at 4MHz and booted in much less than one second
>> from a ROM-chip (and this was wayback in 1978).

>> And right, we had a 'brown-out recovery' (not more than ~50mS hw-delay).
> I see that a brownout is a drop in voltage
>   https://en.wikipedia.org/wiki/Brownout_%28electricity%29
> But I am not sure why you mentioned it.


I mentioned 50mS needed for restart after power-glitch detection then.

> On the one hand, to boot an OS these days requires much more hardware 
> initialisation which will take time. On the other, all of a computer's 
> components are much faster. Windows is known to be bloated so is not a 
> good guide as to what can be achieved. Unix is leaner but still takes 
> significant time to go through checking for and initialising each 
> component. That just makes your KESYS boot times more impressive.

Perhaps less impressive if you know what my OS wont do ... 
and I measured only the time before the user prompt is visible ;)

And of course I don't support all possible things that may be inside 
other PCs than the ones assembled by me.
So there is no blue-tooth, nor WAN, no smartcard, no pdf-reader ... 
 
External connected things like printers and RAM-sticks were checked 
and initialised (or ignored) when the user decide to use it or not.

And in opposition to M$ I never would let my OS try to enter the net 
20 times/S behind the neck of the user to inform me about whatsoever.
KESYS got only LAN, but no internet anyway. 

Legacy port detection (just for presence) take only a few cycles per 
port and (rare implemented) COM/LPT will initialise within one mS.
Mouse and keybd init have to wait for 5mS each (do else during wait),   
HD/CD Identify last for 256 cycles to get +500 cycles for interprete,
PCI-scan takes about 30000 cycles/device (I count 24 here yet), so 
this is also not a time-eater (~1e6 cycles = 1/3mS on a 3GHz machine).
VESA identify, EDID and mode listing takes almost no time too.

The main time consumers are: 
* HDs (from hw detection over Identify and partition chain 
      until root-folders mounted from all identified volumes)
* VESA/VGA setup graphic mode may take several seconds for 
  very high resolutions, my standard 1024*768*256 needs ~0.7 Seconds.

 
>>>> KESYS004      4 +0.5 per HD [512K](with XMM,CD,mouse,etc..)
>>>> KESYS015      2 +0.3 per HD (as above and more)
>>> Assuming that KESYS015 is a later development of KESYS004 can you say
>>> what you did to make it so much faster?
>> beside that I learned more tricks to speed up code in general meanwhile,
>> the main speed gain came from lesser BIOS calls at start and KESYS015
>> seem to use BIOS supported UDMA features to load the starting OS-image
>> by INT13/42 instead of INT13/02. [saved alot of load time]
 
> You mean you used fewer BIOS calls and your newer BIOSes used or allowed 
> you to use the faster int13/42? Interesting point.

the older OS used just 13/02, 13/42 seem to work faster.

What I forgot to mention is that my new version have all standard 
modules stored as a single consecutive block that can be loaded at once 
to a defined address, while the old version had self-relocating modules 
which were loaded step by step dynamically and used memory-alloction. 

> I suppose that almost any sensible OS initialisation will use negligible 
> CPU time and that all of its startup delay will be waiting for hardware 
> of some sort.

We can do many things 'while waiting' ;)
 
>> btw: I checked BIOS UDMA actions and found the PRDs at 09fd20 (EBDA)
 
> I get the feeling that you mean there is some significance to that which 
> I should remember. I know we discussed the EBDA in the past. I think we 
> also discussed PCI-based DMA via NCQ and PRDs. But if I was supposed to 
> make a link there I missed it. Should your last comment have reminded me 
> of something?
 
No, I just remember that we once searched for usable things in EBDA.
__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#9163

On 30/01/2016 20:49, wolfgang kern wrote:
>
> James Harris wrote:
>
>>> My olde 'Zilog PC' run at 4MHz and booted in much less than one second
>>> from a ROM-chip (and this was wayback in 1978).
>
>>> And right, we had a 'brown-out recovery' (not more than ~50mS hw-delay).
>> I see that a brownout is a drop in voltage
>>   https://en.wikipedia.org/wiki/Brownout_%28electricity%29
>> But I am not sure why you mentioned it.
>
>
> I mentioned 50mS needed for restart after power-glitch detection then.

Was restart not the same thing as boot?

>> On the one hand, to boot an OS these days requires much more hardware
>> initialisation which will take time. On the other, all of a computer's
>> components are much faster. Windows is known to be bloated so is not a
>> good guide as to what can be achieved. Unix is leaner but still takes
>> significant time to go through checking for and initialising each
>> component. That just makes your KESYS boot times more impressive.
>
> Perhaps less impressive if you know what my OS wont do ... and I
> measured only the time before the user prompt is visible ;)

A user prompt is all I was expecting - as long as it is usable. IMO it's 
quite acceptable for the OS to carry out other startup actions in the 
background it they would be finished long before the user has done 
anything which needs them. They could be such as other device detection 
and initialisation, and memory checking (if done).

> And of course I don't support all possible things that may be inside
> other PCs than the ones assembled by me.

No need. I saw you had HD, CD, mouse etc. That's good enough. Actually, 
when I saw you had CD in the list I was impressed enough. IME other OSes 
can take a long time to begin using a CD.

...

> The main time consumers are: * HDs (from hw detection over Identify and
> partition chain      until root-folders mounted from all identified
> volumes)
> * VESA/VGA setup graphic mode may take several seconds for  very high
> resolutions, my standard 1024*768*256 needs ~0.7 Seconds.

OK

>>>>> KESYS004      4 +0.5 per HD [512K](with XMM,CD,mouse,etc..)
>>>>> KESYS015      2 +0.3 per HD (as above and more)
>>>> Assuming that KESYS015 is a later development of KESYS004 can you say
>>>> what you did to make it so much faster?

...

> What I forgot to mention is that my new version have all standard
> modules stored as a single consecutive block that can be loaded at once
> to a defined address, while the old version had self-relocating modules
> which were loaded step by step dynamically and used memory-alloction.

Another advantage of having all of the key initial modules loaded in one 
go (presumably from a single entity - a single file or a single run of 
disk blocks) is that it is less vulnerable to damage. As long as the 
initial file loads then the OS will have enough code at least to 
communicate with the user if something goes wrong, and probably a lot 
more. Some Windows versions need many files all to be present and 
correct or the OS will fail to boot properly.

James

[toc] | [prev] | [next] | [standalone]

#9164

James Harris wrote:

[about old my Zilog ..]
>> I mentioned 50mS needed for restart after power-glitch detection then.
 
> Was restart not the same thing as boot?

no, the power supply issued an interrupt on power glitches and this 
made the OS ignore perhaps wrong IRQs/IO-inputs and initialised the 
stack by restarting the OS but bypassing a full boot process. 

>>> On the one hand, to boot an OS these days requires much more hardware
>>> initialisation which will take time. On the other, all of a computer's
>>> components are much faster. Windows is known to be bloated so is not a
>>> good guide as to what can be achieved. Unix is leaner but still takes
>>> significant time to go through checking for and initialising each
>>> component. That just makes your KESYS boot times more impressive.

>> Perhaps less impressive if you know what my OS wont do ... and I
>> measured only the time before the user prompt is visible ;)
 
> A user prompt is all I was expecting - as long as it is usable. IMO it's 
> quite acceptable for the OS to carry out other startup actions in the 
> background it they would be finished long before the user has done 
> anything which needs them. They could be such as other device detection 
> and initialisation, and memory checking (if done).
 
>> And of course I don't support all possible things that may be inside
>> other PCs than the ones assembled by me.
 
> No need. I saw you had HD, CD, mouse etc. That's good enough. Actually, 
> when I saw you had CD in the list I was impressed enough. IME other OSes 
> can take a long time to begin using a CD.
 
It may take up to 30 seconds to read from an inserted CD/DVD, my boot 
code just detects the drive and it's type by Identify packet device.
But the routines to access CD/DVD are already part of the OS-core.  
 
...
>> What I forgot to mention is that my new version have all standard
>> modules stored as a single consecutive block that can be loaded at once
>> to a defined address, while the old version had self-relocating modules
>> which were loaded step by step dynamically and used memory-alloction.
 
> Another advantage of having all of the key initial modules loaded in one 
> go (presumably from a single entity - a single file or a single run of 
> disk blocks) is that it is less vulnerable to damage. As long as the 
> initial file loads then the OS will have enough code at least to 
> communicate with the user if something goes wrong, and probably a lot 
> more. Some Windows versions need many files all to be present and 
> correct or the OS will fail to boot properly.

Yes, this single block load saved me a lot. And predefined addresses 
for each module made also them shorter and faster than self-relocating 
code, the latter was already much faster/shorter than M$'s relocation. 
__
wolfgang 

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.development

csiph-web