Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.dcom.modems
Subject: Re: UUCP g stats
Message-ID: <331@auspex.UUCP>
Date: 27 Oct 88 23:39:31 GMT
References: <184@arnold.UUCP> <1892@van-bc.UUCP> <2032@udccvax1.acs.udel.EDU> <13922@mimsy.UUCP> <741@wsccs.UUCP>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 26

>> The problem is that I cannot get the Vax (or Sun or . . .) to use anything
>> less than 10 bits.
>> 
>> Remember, the idea is to find the use of the `available' bandwidth,
>> which is no better than the rate at which I can get my Vax hardware
>> to send or receive.  (I know: `fixed in 4.0' :-) )
>
>	The actual connection on the line is SYNCHRONUS, removing the
>need for stop-bits.  While it is true that you still communicate to the
>TrailBlazer or the HST asynchronusly, the actual connection is synchronus;
>Timing is provided by a seperate clock, not the start and stop bits which
>are needed to prevent framing errors in an asynchronus connection.

Umm, I think you missed his point.  The point is that you can't stuff
data down the modem any faster than the serial port will allow; any
extra bandwidth opened up by not using stop bits can't be spent sending
data from the host, because the data isn't coming in fast enough.  It
has to be spent sending error-correcting-code bits or something like
that.

Another way of looking at it is that if my host talks to the modem at
19.2KB, I can at most send 1,920 octets a second over the modem, even if
the modem can send data at 1GB/second.  If it can send data faster than
1,920 octets a second, it will spend some time either sending octets
that weren't given to it from the 19.2KB connection to the host, or
twiddling its thumbs.