Return-Path: <gooseman@on.ON-Luebeck.DE>
Received: from on.ON-Luebeck.DE (on.ON-Luebeck.DE [193.29.188.2])
          by hugin.oden.se (8.8.4/8.8.4) with ESMTP
	  id AAA22579 for <dlanor@oden.se>; Tue, 24 Dec 1996 00:33:01 +0100
Received: (from majordomo@localhost)
          by on.ON-Luebeck.DE (8.8.4/8.8.4)
	  id AAA14031 for stik-outgoing; Tue, 24 Dec 1996 00:24:32 +0100
X-Authentication-Warning: on.ON-Luebeck.DE: majordomo set sender to stik using -f
Date: Tue, 24 Dec 1996 00:24:24 +0100 (MET)
From: Peter Rottengatter <perot@pallas.amp.uni-hannover.de>
To: stik@ON-Luebeck.DE
Subject: Re: STIK: Work on STiK
In-Reply-To: <Pine.LNX.3.93.961223204001.331A-100000@modem-b-63.mp.usyd.edu.AU>
Message-Id: <Pine.A32.3.91.961223232919.18774C-100000@pallas.amp.uni-hannover.de>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: stik@ON-Luebeck.DE
Precedence: bulk
Reply-To: stik@ON-Luebeck.DE
X-UIDL: 5db55ad66faeb4745a03f000252115a1


On Tue, 24 Dec 1996, Martin Mitchell wrote:

> On Fri, 20 Dec 1996, Peter Rottengatter wrote:
> 
> > The conclusion on this is that we are really tight on CPU time here, as 
> > the IP core is executed within an interupt, we cannot allow *any* 
> > unneccessary overhead here, and I fear separating the IP from the kernel 
> > will produce quite a lot of overhead. Note that we need to care for 
> > people with a 8 MHz 68000, one meg RAM and TOS 1.0.
> 
> Indeed. I have such a machine, a 1040STFM. However I believe your fears
> are at best unfounded, and at worst completely inaccurate. For example,
> you advocate a scheme using Pexec() for loading modules. This is indeed a
> simple system, which is its main strength.
> 
> However consider the memory wasted by this method. If you want each
> program to be in standard format then 256 bytes is wasted per module for a
> basepage. Let's look at the real cost of this:
> 
> Likely modules necessary for normal Internet usage on a 1040STFM:
> 
> Modules       |    Estimated minimum overhead per module (bytes)
> Needed        |      Pexec() method    |   Custom (NVDI) method
> ------------------------------------------------------------------
>               |                        |
> TCP.STX       |          256           |           0
> UDP.STX       |          256           |           0
> RESOLVE.STX   |          256           |           0
> SERIAL.STX    |          256           |           0
> ------------------------------------------------------------------
> Total:        |         1024           |           0
> ------------------------------------------------------------------
> 
> I estimate the size of the kernel code needed to implement a custom system
> is no greater than 64 bytes larger than using Pexec().

The zeros on the right side are rather questionable. I'd say it would be 
interesting to see how you'd achieve that in 64 bytes. The loading and 
starting of the modules is all done by one single OS call (Pexec), while 
with a custom design even in assembler it'd be very difficult to open the 
file, figuring out the size and requirement of working memory, mallocing 
enough memory for both, then loading the actual contents, closing the 
file, and jumping to an appropriate entry point. For all this 250 bytes 
is a better guess even in assembler, in C it's probably 500. But let's for 
a moment assume that you achieve it in 64 bytes. Then your scheme is lots 
more complicated, and there are lots of opportunities to spread bugs.

Lets not be silly here. The Pexec methods does cost a kilobyte.
This is only one part out of thousand even on a one megabyte system. 
Putting lots of effort in something that saves that little memory needs 
to be called simply inefficient ! Think about ways to get rid of the 
problem that ownership of allocated memory can't be transferred to the 
system, the resulting dynamic memory allocation scheme would save 
hundreds of kilobytes. Such an effort would be ten thousand percent (!)
more effective than the one you're proposing here.

The other thing you call a problem is loading the modules. My good ole 
520 ST loads eight (!) of them (SERIAL, CENTR, ETHER, MIDI, LCLTLK, TCP, 
UDP, RESOLVE) in about a tenth of a second, far faster than I can measure 
using my watch. And you call that slow ? If it's slow on your machine 
than it's obviously not the concept of the modularity.


> > > However from the high level view, looking at the design as a whole, and
> > > indeed at the C code, I think it is far more desirable to make IP a
> > > module. It improves the modular nature of the structure, designed as it is
> > > in a more 'object-oriented' way than the current STiK.
> >
> > Say you something about object-oriented programming. It's been invented 
> > to handle some difficult problems. It's well suited for some, perhaps many 
> >
> > [ ... lots of stuff by myself deleted by myself ;-) ... ]
> >
> > Probably you're a fan of the object-oriented ansatz, I'm not. I use 
> > methods that are useful, not fashionable.
> 
> I quote the entire paragraph so you can see what I said. I merely said
> that your design is more object oriented than the current STiK.

Ooops, yes, you're right, I need to apologize. Your statement needs to be 
read carefully, I obviously didn't do that. You might have guessed that 
people before tried to convince me using object-oriented reasoning. ;-)


> And what do I read? A lengthy diatribe completely irrelevant to my
> comment.

Sorry again. Hopefully this clears that up.

What I mean is that the communication between the IP protocol, the actual 
datagram distributor, the router, the module interface and the miscellaneous 
functions is so intense that pressing it through the hole of a module 
interface will produce significant, unwanted overhead. This is probably 
badly worded, but it's difficult to tell this to someone who does not 
know the code. I think I may call myself a reasonably experienced 
assembler programmer, I do know the resources, and the limits, of a 8 MHz 
MC 68000 rather well.

Above you complained about memory wastage of one kilobyte. Making IP a 
module will cause a memory overhead that is probably larger, mainly due 
to all that communication, which must be done then via agreed-upon 
structures, and lots of pointers to all sort of functions and data 
structures must be exchanged. I simply got better and more important 
work to do, like finishing essential parts of STiK and SERIAL.STX, only 
counting those things that are of relevance to this mailing group, than 
torturing myself with implementing a scheme for which I do not see any 
benefits, but that will produce overhead.


> > > It will also simplify the coding of the kernel, which will have enough
> > > disparate code hanging off it as it is. (misc functions, internal memory
> > > allocators, modules handling, general init, vector bending etc).
> > 
> > This is true, but no reason at all to make it separate.
> 
> That's right, but it's equally valid for me to say: 'Why should IP be
> included along with all the miscellaneous functions?'
> 
> If you think that having it there will produce the speed and efficiency
> needed to service interrupts quickly, well you're very mistaken. That is
> an implementation detail, not a design issue.

Ok, I take you by your words : It's not an issue, just a minor detail. So 
then let *me* decide how I do it, right ?


Cheers  Peter

---------------------------------------------------------------------
   Peter Rottengatter             perot@pallas.amp.uni-hannover.de
---------------------------------------------------------------------

.
