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


On Sat, 31 Aug 1996 00:59:11 Dan Ackerman <ackerman.29 wrote: 
>
>On Fri, 30 Aug 1996 14:44:06 Ronald Andersson <dlanor@ wrote: 
>>
>>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.
>
>     STiK is and isn't interupt driven.  It's on a timer interupt.  This got rid
>of the evnt_multi call in the .ACC which caused serious problems with magic. 
>However an evnt on a port won't kick STiK in.  
>
>     When I get a chance I'll look at the device lib and the send routines.  It
>might be possible to get another boost of speed out of it by scanning the buffer
>and sending blocks when possible.
>
>     However for (c)SLIP you have to read byte by byte.  As you don't know when
>an escape character will pop up.  I could try reading in a block, but then we
>would need to scan for escapes and process them out and also watch that we only
>have one packet in the block we grabbed.  It would be easy in any circumstance
>with multiple connections running at the same time to have multiple blocks of
>varying sizes comming in. 

You have to 'read' byte by byte yes, but not necessarily direcly from a port.
The important thing is only that you do get sequential bytes from the incoming
data stream, but you can just as well 'read' this from a buffer which is filled
automatically by an interrupt routine.  (I used to think STiK did it that way.)


>     I don't think PPP would give us this limitation, so there is hope there. 
>However I've really only studied the command level and negotiation section of
>PPP and just skimmed the rest.  So it's possible that I've missed some hefty
>stuff in there as well.

Well, I'm sure that will become evident (and debugged) once we get working on it,
but I think an interrupt system can be designed suitable for any form of use.


>>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.
>
>     I can see where this would have merit, but right now I consider this
>something that needs to wait til I can make STiK into only a TSR.  At that point
>in time we could move all the port interaction code into a seperate module and
>then replace it when desired.

That sounds like a useful thing to do of course, but as I see it the actual
interrupt routines do not need to share variables etc with STiK at all, so they
could be developed and debugged completely independently of STiK.

In fact, if my hopes concerning the usefulness of the TOS interrupt routines
(best complemented by HSMODEM) prove true, all that work is already complete !!!


>>Did you ever compare a byte-per-byte file copier with one using buffers...?
>>There is always a significant speed difference between such implementations.
>>
>
>     Yes I know this, however without some major overhauling and alot of effort,
>getting block transfers into SLIP isn't going to be easy.  I've seen no source
>code yet for SLIP that handles transmission of DATA for SLIP in anymode but byte
>by byte.  As I said I'll try and see if we can squeeze it in on send but I'm not
>going to guarantee anything without looking it over.

Again, the term 'transmit' is misleading, because the important thing is only the
byte by byte creation of an output data stream, which is then best transmitted by
an interrupt routine fetching data as needed from its output buffer.

This way the SLIP code is in no way affected by 'waiting' for the port to finish
sending previous bytes, it only needs to detect if the interrupt output buffer
gets full, and then return partially complete.

For a complete package this could cut down 'transmit' time from a full second at
14k4 speed to a mere few milliseconds, leaving all the remaining time for useful
client work.  The _actual_ transmission will take longer of course, but that is
fully transparent both to the client program and to the STiK routines.


>     If HSMODEM has some slick way of doing this, then we might want to look at
>that and see about getting Sheutzows (sp?) permission to distribute HS_MODEM
>with STiK as it will be a necessity.

It is in fact a necessity for all high-speed modem usage, since Atari never did
succeed in writing bugfree routines for RTS/CTS handshaking.
(Oh, and his full name is "Harun Scheutzow", so you only missed a 'c'.)

The latest release package is a 122660 bytes ZIP package, so it may be hard to fit
into our standard release package.  But we can always keep it available on the
same sites and recommend its use in our documentation.


>     Right now the only routines that STiK uses that are byte by byte are SLIP
>IN and SLIP OUT.  All the rest of the routines use blocks out of the internal
>buffer.

Well, if they must they must I suppose, but we would still be better off if those
SLIP routines 'read' and 'wrote' their bytes via interrupt buffers, leaving the
actual port interaction to some dedicated interrupt routines.


>>I'm still unclear as to how it reads (or attempts to).
>>Is an interrupt system active or not ?
>
>     When the system timer goes off (50 sec) it calls housekeep(), the first
>thing housekeep does is see if it's already in use if it is it returns.

I take it you mean the VBL interrupt, which is not constant however, but depends
on the screen resolution used.  NTSC => 60 Hz,  PAL => 50 Hz,  SM124 => 71.25 Hz
and even those values can vary with use of various resolution expanders.
That might be one reason for inconsistent test results on various systems.


>     If it's not in use it does some STiK processing.
>
>     Handles resolves
>     SLIP IN
>     SLIP OUT
>     Couple other things here but they are escaping me.  Basically all the
>things that STiK needs to keep running.

That sort of interrupt may still be useful to have, to keep things flowing, even
when (if) we also have a basic interrupt system for the raw data streams.


>     Each of these processes first check and see if they have anything to do. 
>If they don't then they return.
>
>     When housekeep is done the normal system timer vector is processed.
>          (or at least whatever routine was occupying it's space when STiK
>          loaded)

That's needed of course, although I usually prefer calling that routine first,
since some system routines really dislike irregularity in this context.
But I couldn't do that in C, so I guess it might be a bit risky, since it needs
pushing a simulated exception frame onto the stack.

Strange though!  I just traced all XBRA chains in the system (with STiK connected)
and I could not find the STiK identifier in any of them.  This could mean you are
using the 'vbl list' instead, but as you describe it above your usage is illegal.
You must always use XBRA in stealing a vector already in use.

Even more seriously though, the 'vbl list' is not always executed, since this is
skipped during time critical operations (eg: disk operations).


>     There is already an internal 12k send buffer.  4k would probably be enough
>I might step it back down.  There is one for recieve and one for send.  These
>are used respectively for slip in and slip out.  When the send buffer is full
>then it returns partially complete and starts again when it runs again.  When
>the slip in can't get a byte it returns and starts again where it left off when
>run again.

Now you've lost me I'm afraid.
When is that output buffer actually transmitted (and how) ?
And who fills that input buffer, (and how) ?

If you already use buffers between your own routines and the device lib even for
SLIP, then it should be very simple to adapt this to interrupt driven buffers.


>>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.
>>
>
>  This would not slow anything down.  The question here is what would do the
>interupt routines and what are they going to grab?  (where are they going to
>reside?)  

The basic interrupt routines exist in all TOS versions, and are used by most
serial communication programs, but HSMODEM is needed to correct some bugs.

They simply transmit what's in the 'Tx' buffer until empty, and fill the 'Rx'
buffer with incoming data, and in so doing also use RTS and CTS to ensure
that each modem will stop transmission when/if needed by the other party.

Filling that 'Tx' buffer and emptying the 'Rx' buffer would be done by the STiK
routines in our case, simply by calling the Fread/Fwrite routines as described.
Although dedicated speed-optimized versions of these may be preferable later.

Either way, this would transfer data to/from the STiK packet oriented buffers
and the raw data stream buffers of the interrupt routines.

Note that systems with several serial ports (eg: TT) have completely separate
interrupt buffers for each port, so there is no problem using this method in a
future multi-port STiK either.  (And that will _require_ interrupts anyway.)


>>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.
>>
>
>     In older versions of STiK, both SLIP IN and SLIP OUT would return without
>checking on whether more data was waiting to be recieved or sent.  I changed it
>so that STiK will recieve as long as data is coming in and there is buffer space
>for it and to send as long as the send buffer isn't full or until there are no
>more packets queued.

Hmmm, returning for each byte handled could lead to a tremendous overhead cost,
and might also cause the event_loop of the client to be executed so frequently,
that his calls to STiK would come far too seldom for efficient operation.
So under present conditions the current method is preferable.


>>>     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.
>>
>
>     It was the above fix that cured this problem mostly as well as some
>optimisation of the actual slip sending routine.

Yes, I see how the old method would slow things down.


>     So how was this for a small class in the operations of STiK as I understand
>and remember it ;)

Pretty good, but this brings us to my remaining blind spot, namely the device lib.
I'm still not entirely clear as to how it works internally, and whether there are
any interrupt routines involved in this, although this now appears unlikely.


>ps. Ronald the code for setting the IP version in uncompressed slip is buggered.

Yep, I noticed that in another mail from you which I've answered, and I saw that
you had some additional info for me in yet another, so I'll get on it at once.
(Well, once I'm done with the mail that is.)

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