To: stik@ON-Luebeck.DE
Subject: Re: [13]  STIK: STIK/DIALER                                                     

Hrrm, this is the second time I try sending this mail.
Evidently I forgot to save it in my mail folder as well as in my folder for
STiK improvement ideas.

That's why you only got a copy of Dan's post without my comments that time.


On Mon, 26 Aug 1996 12:55:56 Dan Ackerman <ackerman.29 wrote: 
>
> Ooops, no actually I (Ronald) wrote what's below (Dan answered):
>>
>>Unfortunately our discussion on the interrupt support makes it clear that it is
>>only between packets that the routines do not block.  During actual reception
>>or transmission they are still apparently locked in the STiK code, spending most
>>of the time waiting for data on the serial interface.

>     They don't wait here.  STiK reads in data, when no data is available it
>returns and lets the system get on with it's work.  When it's actually getting
>data, yes it does block.  But need we worry about this?

I'm not sure, it depends on _how_ it gets the data, and I simply don't know that.
I quote Peter's description of the device lib shortcomings below:

> >The device-lib provides calls for receiving and transmitting bytes. I 
> >wanted to modify it that way, that the send() call only writes it's data 
> >to some buffer, so that it can return immediately, and some interupt 
> >routine writes byte by byte to the port. That way the send() only has to 
> >block if the amount of data exceeds the buffer size. Correspondingly for 
> >receive(). I guess no changes are needed for other parts of STiK.

I got the impression from what he said, that at present STiK is not interrupt
driven after all, but simply polls the port for bytes, and then reads them in one
by one, with a similar procedure for transmission writing to the port.

Reading or writing one byte to a port takes less than a micro-second, but at 28k8
speed the waiting time per character is appx 347 micro-seconds, or 694 at 14k4.
This means that the computer could do a lot of other things if interrupt driven.

An interrupt system as described has some overhead for pointer and buffer handling
but would probably release more than half of the above 'wait delay' for user APPs.
This should allow the system to maintain the illusion of 'full' speed even in
many situations where at present it appears completely blocked.

Hopefully this description is wrong, so that the built-in interrupt buffering is
at least active, but then it is still inefficient to handle data byte per byte.

Did you ever compare a byte-per-byte file copier with one using buffers...?
There is always a significant speed difference between such implementations.

The same sort of speed loss exists for byte-oriented serial communication, so
only the interrupt routines should fill their buffers byte per byte (they must).
All other routines should allow multiple byte transfers.


>     When you are getting info off the net which are you more concerned about?
>
>          1. Getting the data onto your machine as fast as possible
>
>          or
>
>          2. Screw the speed I want to be able to play break out
>
>     Sorry I know this is exaggerated.  But it's fairly rare to be getting so
>much info across to make this noticeable.  The only time I notice it much is
>when I get mail, since this is Text and has the compression kicked in on my
>modem.
>
>     I don't see how you can improve it much with out completely slowing down
>the connection.  If STiK can read data it reads it, no data it returns and comes
>back later to finish the packet or start the next.

I'm still unclear as to how it reads (or attempts to).
Is an interrupt system active or not ?

If not, then this needs to be corrected ASAP, since data is too easily lost.
If active, then the interface to read/write data to the buffers needs to be
multi-byte oriented to eliminate single-byte oriented overhead losses.


>When STiK sends data it sends it til there is no more to send.

Write operations will need an ability to return 'partially' complete, in case
there was not room in the transmit buffer for all the data.  With an interrupt
system these should also always return directly after transferring the data to
the buffer of the interrupt routines.

Function return values could be (like gemdos Fread/Fwrite) the number of bytes
successfully transferred, so the caller can determine if all of the data was
completed, and retry later as needed.  This way no blocking is necessary,
and I don't see how any of the above would slow anything down.


>     As these connections become slowed down if you take to long to respond I
>feel this is the best way to do it.  Because stepping it back not only
>potentially increases the time by the extra time you are trying to give the GUI,
>but will cause the system on the other end to slow down in relation to you,
>causing a potentialially exponential increase in time depending upon the
>connection.  (vague enough ;) )

I'm not sure what you mean by 'stepping back' here, but it doesn't sound good,
so please don't do anything having those effects.


>     I could step back the send to give more time to the system, but I can
>remember the days where it took 45 minutes to send a 100k file.  I'd rather not
>go back.

I agree, don't do that.

I think there are other ways to 'liberate' CPU time, partly described above,
but I know too little of the internals of the current mode of operation to
be entirely certain what (or how) such ways should be implemented.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
