Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!van-bc!sl
From: sl@van-bc.wimsey.bc.ca (Stuart Lynne)
Newsgroups: comp.dcom.modems
Subject: Re: USR 9600 baud dual standard
Message-ID: <2509@van-bc.wimsey.bc.ca>
Date: 11 Oct 90 09:43:20 GMT
References: <1990Oct8.195418.1817@cbnews.att.com> <2461@van-bc.wimsey.bc.ca> <2170@jwt.UUCP>
Organization: USENET Public Access, Vancouver, B.C., Canada
Lines: 27

In article <2170@jwt.UUCP> john@jwt.UUCP (John Temples) writes:
>In article <2461@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes:
>
>>van-bc run's 2 PEP modems with baud rates locked at 19.2. With no flow
>>control.
>
>How can you pump data at 19.2k bps into a modem which can only
>transmit it at 17-18k bps without using flow control?

With uucp you only ever send a maximum of 220 bytes of data before stopping
and waiting for an ack packet. The modem will not send an ack when it no
longer has enough buffer space. But it always can receive without error the
three packets (220 bytes) that you will send without acknowledgement.

This will also work between two Unix systems. Again because the serial
driver will always buffer at least 220 bytes without loosing anything even
if uucico has been swapped out. It's most likely the reason that the packet
size has been kept at 64 bytes. Three of them will fit into the default
buffer on modern (post V7) Unix's (255 bytes).

The big problem that people tend to confuse this with is character overrun.
Where the receiving system just cannot receive the data at that speed and
looses characters even though it's buffer is not full. 

-- 
Stuart Lynne	Unifax Communications Inc.
		...!van-bc!sl 604-937-7532(voice)     	sl@wimsey.bc.ca