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 TAA18536 for <dlanor@oden.se>; Wed, 25 Dec 1996 19:06:41 +0100
Received: (from majordomo@localhost)
          by on.ON-Luebeck.DE (8.8.4/8.8.4)
	  id TAA14935 for stik-outgoing; Wed, 25 Dec 1996 19:05:32 +0100
X-Authentication-Warning: on.ON-Luebeck.DE: majordomo set sender to stik using -f
Date: Wed, 25 Dec 1996 19:06:37 +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.961224113611.778D-100000@modem-b-63.mp.usyd.edu.AU>
Message-Id: <Pine.A32.3.91.961225182838.16965H-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: de13fdcd284e9130003fd32f73c250d2


On Tue, 24 Dec 1996, Martin Mitchell wrote:

> On Tue, 24 Dec 1996, Peter Rottengatter wrote:
> 
> > > 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.
> 
> Again, please read what I said. I said "no greater than 64 bytes larger
> than using Pexec()" - definitely not the same as 64 bytes. I trust you did
> not deliberately misunderstand me.

I try not to. However, you're giving a table suggesting that minimum 
overhead of a custom system can be 0 bytes, compared to 256 for the Pexec 
solution. This is simply not true. If you call the effects of Pexec (that 
is including the call itself of course, so it's even a little more than 
256) an overhead, than you must count all effects of a custom system too. 
I did not really calculate above, but it is obvious that all that what I 
cited is neccessary (forgot relocation of the loaded code), and is saved 
if Pexec is used. You thus need to compare a piece of custom code that 
does all the relevant things, with the Pexec requirements. I'm just 
convinced that if you count all that, then the Pexec approach is even 
more moderate in memory requirement, especially if the second half of the 
basepage is reused, as Ronald noted.


> In fact, memory allocation is not included in the 64 byte estimate as
> there will already be allocation routines to use. The Fsfirst()/Fsnext()
> calls for scanning the directory are common to both methods, and are not
> included in the 64 byte estimate either. In fact all it would need is
> 'Fopen()/calc RAM needed/jsr malloc/Fread()/Fclose()/jsr module's init'

You're right that the Fsfirst is common to both, but I didn't count it, 
what you'll notice if you read my comment again.


> > 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.
> 
> That's easy. The STiK kernel calls Pterm(). I really do not think it is

No, it does not.


> sensible to unload any of the above 4 essential modules during a STiK
> session, as all of them are necessary for normal operation. In any case,

It is not possible to unload *any* module during a STiK session. This has 
been discussed earlier, and we all agreed that it is unneccessary to 
provide ability to unload a module.


> > 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.
> 
> If that is the actual speed, then I am impressed. However you still waste
> 2048 bytes that cannot be used, which concerns me.

I must correct myself a little. This was an estimation from my memory. In 
reality loading all 8 modules takes about a third or a half of a second.
This is without MagiC, but TOS 1.4, loading from harddisk.

I tried to produce a loading time as you quoted by using my old 1040STFM 
with TOS 1.4 and loaded STiK with all 8 modules from floppy disk (!). It 
did load them in about three or four seconds (all 8 of them !), and that 
from floppy ! So I only have one explanation left for your loading time : 
You use TOS 1.0 or TOS 1.2 in your machine. Both are well-known for the 
bad habit of clearing all memory before starting a loaded program in 
Pexec, which could very well produce this loading time.

Assuming that you really use such an out-dated TOS, I must say you should 
not blame the inefficiency you're observing to the Pexec concept, but to 
the stupid implementation of Pexec in your TOS. Asking for efficiency 
but using TOS 1.0 or TOS 1.2 is a contradiction for me. The very first 
step towards efficiency should be spending a couple of dollars or pounds 
for EPROMs for TOS 1.4. People using TOS 1.0 or TOS 1.2 should be able to 
live with a minor inconvenience like loading time of 10 seconds.


> > 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.
> 
> Perhaps communication has caused difficulties in understanding here as
> well. I'm not suggesting that the kernel just copy data from one structure
> to another before calling the IP module. Rather I think that the
> integration should be much closer with less overhead. The performance
> should not be degraded by this method, and there should be no significant
> additional memory cost.

There is, believe me. I did not mean copying data, of course that would be 
bad. Maybe Ronald can explain that better. I've read his attempt, and I 
admit it sounds somehow more convincing than my writing.


> > > 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 ?
> 
> I did not say it was a minor detail. And I mean that speed and efficiency
> come from such implementation details.
> 
> Your last comment is very telling. Did you release your CONCEPT.TXT and
> diagram for real comment from people on the list? Or self gratification
> from disengaging in a consultative design process and taking unilateral
> decisions?

I'm sorry, my comment was a little emotional. I'm just a little tired of 
my attempts to make you believe what I write. Of course I released the 
CONCEPT.TXT for comments. I did get a number of comments, and I also 
changed things due to those (ask Ronald, for instance, if you don't 
believe me). But some issues do not improve things if changed, and I find 
it very difficult to make you believe that the sort of modularity you 
propose here is one of those issues. It's just bad luck for you that 
with both things you fight for here your arguments do not convince me.


> Also why the secrecy? If your design is so quick already, please send me
> the skeleton module system so I can really check its speed.

There is no secrecy. The reason I did not spread code yet is that there 
are still changes going on. I'm already regretting that a couple of days 
ago I already sent Dan some code, so that he could start with porting 
TCP. I found changes neccessary meanwhile, and now I have to sent it 
again, which he probably doesn't like very much. It's a simple issue : 
Specifications must not be released before they are sort of finished.

And you should not try to check loading speed using TOS 1.0 or TOS 1.2, 
if you have one of those. Since I sent Dan some stuff, you'll find the 
skeleton in your mail soon too, probably before the end of the year ;-)


Cheers  Peter

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

.
