Xref: utzoo news.software.b:2188 comp.dcom.modems:3760
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!tank!uwvax!rutgers!att!alberta!ubc-cs!van-bc!unifax!sl
From: sl@unifax.UUCP (Stuart Lynne)
Newsgroups: news.software.b,comp.dcom.modems
Subject: Re: TMN-netnews update
Message-ID: <113@unifax.UUCP>
Date: 1 May 89 18:40:08 GMT
References: <1RH0R8#4BF6fX=eric@snark.uu.net> <1989Apr29.224526.22914@utzoo.uucp>
Reply-To: sl@unifax.UUCP (Stuart Lynne)
Organization: Wimsey Associates
Lines: 47

In article <1989Apr29.224526.22914@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <1RH0R8#4BF6fX=eric@snark.uu.net> eric@snark.uu.net (Eric S. Raymond) writes:
>>Result? The 'blazer has to have S58=0 (no handshake) or S58=3 (XON/XOFF) set
>>for the T5100 to even *open* it -- and XON/XOFF isn't usable because the start
>>and stop chars are in-band for UUCP's 'g' protocol. Without handshaking
>>dropped characters are inevitable. Massive lossage either way.
>
>Aha, a chance to catch Eric in an error! :-)  The uucp-spoofing mode in the
>Trailblazer, when it kicks in, shuts XON/XOFF off, so there is no conflict.
>With a packet protocol running between host and modem, you don't need any
>low-level handshaking if your host interface is halfway well built.

There are two types of character losses. First from not being able to
service the received character interrupts fast enough, and second running
out of room for the data in the driver buffers (clists). If the driver runs
out of room it will flush the data. Prior to actually running out of room it
will attempt to flow control.

With uucp protocol "g", with a window size of 3 you will not overrun the
CLISTS (at least not in standard system v). So the only problem is whether
you can actually service interrupts fast enough to actually receive the
data.

This can be partially helped by designing the interrupt levels so that
serial drivers have the highest priority. In fact higher than the kernel is
protected from (effectively making allmost all of the kernel interruptable).
Then have the serial drivers only send and receive data from it's own data
areas (not from the systems clists). Fill or empty the drivers data areas
from a clock interrupt service routine.

If you then allow that routine to do (for example) hardware handshaking you
can handle fairly high data transfers without huge buffers. If the device
you are talking to doesn't handle RTS/CTS type flow control you have to
provide enough data space to handle the worst case. On Xenix for example at
19.2 you have to buffer about 60 chars to be safe (the clock poll should
empty the data every 2 milli seconds, you can receive something like 20
char's per millisecond at 19.2).

The bottom line is that if you have a decent serial driver you can run the
TB's without *any* flow control because the windowsize of three prevents the
standard drivers from overflowing the clists and flushing them. And if you
*really* do need flow control it can be done by using hardware (RTS/CTS)
full duplex flow control. Anyone who has a Trailblazer hooked up to an SCO
286 system can demonstrate this fact to you. 

-- 
Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)