[unios] Re: Priorities

[Srikant Sharma (Chiku)]

From: "Srikant Sharma (Chiku)" <srikants@wipinfo.soft.net>

On Fri, 4 Dec 1998, Pat Wendorf wrote:

> From: Pat Wendorf <beholder@ican.net>
> 
> > Do you put a 256 ultrasparc processor MPP machine in the same category as
> > a uni processor IBM PC ?
> 
> One processes faster by using a different method... that IS the difference...  With a scalable OS, you can take advantage of that fact.

And what exactly is a scalable OS ?

scalability can be extended (or rather defined) for machines whose BASIC 
architecture is the same. i.e say we write a scalable OS for SMP machines
scalability 8 CPUs to 64 CPUs etc ....

but we can't say that same stuff is valid for 256 CPU MPP machine. The
scalability can be determined over similar stuff .... extending it's working
on a different category is fetching it too far.

> 
> > Do you think the Algorithm required to schedule different tasks on these
> > two machines will be the same .. in effect will the Kernel be same for
> > both these machines ?
> 
> Nope, and I did not expect them to be... UniOS does not mean One-Kernel-Fits-All... What I mean is one base system can encompass all computers.  It may not be
> perfect, or the fastest solution possible, but I don't believe it would be that far off.

If the kernel(s) is/are going to do all the checks  what happens to its size ?

> 
> If we create a system that takes advantage of ONE type of computer on ONE type of architecture, for ONE type of processing we could have a very very fast, very
> stable system... but what the hell would be the point?  We are here to find something better, something new... not re-create what we already have.  If I wanted

As far as code perspective is concerned .. I don't think that all generic 
code can be written without making it so bulky that its useless. 
Remeber Heseinberg's principle.

Well, making a generic frame work for every thing is altogether a different 
matter. An outer layout ..... a structural design which is generic  can be
possibly written (developed). Later on individual components can be coded
(Following the Ladder Development model)  which are put on a machine according
to the requirements.

(Don't you think windows NT follows a similar path ?)

> that, I'd just hook up a keyboard and printer to my Sony Playstation :)
> 
> > IT CAN BE SAME COMPUTER THAT RUNS AN ASSEMBLY LINE, A GAME, A WORD PROCESSOR
> >
> > Oh really ?
> > Do you think  the basic hardware will always be the same .. i.e a basic machine
> > and the rest of the stuff will be managed by software (in short OS) ?
> 
> No it will almost never be the same, but it CAN be the same.. and it can be the same OS, if the OS was designed right from the beginning.
> 
> I'm sorry, but I've seen it done.  My own laptop can play games, control assembly lines, and word process... You can't tell me it can't be done.  It does NOT do
> any one of those processes perfectly, but it CAN do them all.

This is the difference ... the resulting system becomes :
'A jack of all trades but master of NONE' 
My question is how good is such a system ? 
A person's needs are limited. He would rather go for a Master stuff which
perfectly fulfill his needs.  This is basic human nature.
> 
> > A game involving great GUI requires a Graphic accelerator .. the driver for
> > which needs to be written. Better make it even faster  put the  graphic
> > related code in the Kernel it self ... better .. make the kernel's only functionto control the graphic accelerator...  This is the most optimized for of that
> > game machine ..  At this highest level this game machine is an 'Embeded System'
> 
> We don't want an embedded system... there are lots of those, and most of them are not scalable (not counting QNX)...  We are not looking for perfect... just as
> good as possible without sacrificing flexibility.

That's the point I am trying to drive at ...  
versatility is required .. but the trade offs need to be seriously considered.

> 
> >
> > A specialised machine for a specific purpose.  A computer required for controlling Air traffic .. , Weather forcasting .... require huge number
> 
> > crunching .. that too in real time ....  These are huge MPP machines with
> > tremendous number crunching power ... and the irony is that these are the
> > machines which usually provide just a  raw stream of Data  which is then
> > fed to different computers which are again specialised in simulations.
> >
> > Are you going to control this different Hardware with same software ?
> 
> One OS could handle all of it... The OS would not work the same way on every machine... it would have the same interface and the same programming method, but I
> said nothing about it running the same way.... that would be totally impossible.  This was not a mistake we were planning on making :)
> 

This is again what I wanted to state .. and what I have already stated in this
mail somwhere in the begining .....

We can't write a universal generic OS.....
But may be we can design the basic frame work ...
This frame work can be rather a Very High Level Design. (VHLD)
This is the phase where we define the policies.
We can determine on generic/universal policies but as we go to details
jump on to specifics... may be ... we can develop a large number of 
components which can be integrated without any fuss .. later on 
depending on the requirements fix only the necessary things together.

> > Forget the case of different categories of machines. Consider two machines
> > having exactly the same configuration  but being used for two different purposes
> > viz.  routing the network traffic ... &   image processing. ..
> > n/w traffic controller needs a kind of n/w stack built into the Kernel ..
> > needs network controller code  and not some image enhancement s/w ..
> > on the other hand a  image processing comp will require some dsp chip
> > emulators built into it ...   where do you put it to make it most optimized
> > one ? .... in kernel ...
> 
> If you put specific things like that in the kernel, then why bother making the system generic... this code would be done elsewhere, in a hardware abstract, or in
> the code itself... never in the kernel.

I think you did not get what I wanted to say here...  If you would read my prev
para may be you will see my argument in clear light.
Design the kernel modules ...  put them on to the system only if that system
is in need of that module.  Who says the kernel can not be divided into 
modules ?


> 
> 
> > For that matter My current project ( at my job)is about building an enhanced form of OS which lets you process > data warehousing  from 100 GB to terabytes.
> > Less than 100 Gb ? .. sorry we can't ensure that the overhead in the OS will
> 
> > not overshadow the actual processing requirement for such a small data.
> >
> > These are not even the hundredth part of my reasons I believe it hard to think
> > that there is a common ground between all the users.
> 
> There is a common ground between users, not between methods of processing...  there is a big difference.  Take that same machine you are programming, and try
> running a high performance game... oopps... try finding one first :)  You can't because THAT machine, and THAT OS were only made for server processes (I have
> some experience with Sparc machines :)...  But ask yourself if the hardware is physically capable of it?  Damn straight it is... hell, the hardware scrolling is
> as smooth as some arcade machines...  So why is it, if Sun wanted to go into the game market (which I doubt they ever would), they would have to write a new OS?

You are wrong here...   What common ground is there between a game player and 
a data analyst ?  (considering GUI ?)  a game players primary concern would
be good display and not huge number crunching floating point operation.
The data analyst would be less interested in GUI than the analysis.

The Methods of processing are influenced by the Users only and if you agree
that there isn't much common ground between methods (which are influenced by
the users) then you vindicate that there isn't much common ground between
users.

> Because It's just not easily scalable in this direction. The UniOS project is a scalable OS that can scale in any direction. How does it do this?  That is what

please define scalability AS YOU SEE IT ?
(this is an honest question)

> we are trying to find out... With ideas, from some very smart and experienced  people.  I don't claim that it will can be perfect, because its not an embedded
> system...  I'd bet you could get double the speed out of that program you are writing if it were embedded also :)  But you also have an OS layer to contend with.
> 
> Do you want to create something for something, or something for everything?  We already have tons of OS that fit specific need.  We don't need another... unless
> we come up with a NEW specific need.


I think that in this mail at some places I am very blunt  but that was 
all with good intention only and I did not mean to offend any one.
Also please let me kno if I am not clear at any point

bye
--
Srikant



------------------------------------------------------------------------
To unsubscribe from this mailing list, or to change your subscription
to digest, go to the ONElist web site, at http://www.onelist.com and
select the User Center link from the menu bar on the left.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios