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

Groups > alt.os.development > #9162

Re: Oh for the days of fast boot

Show all headers | View raw

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 

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web