Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!csustan!csun!abcscnge
From: abcscnge@csun.UUCP (Scott Neugroschl)
Newsgroups: comp.sys.ibm.pc,comp.unix.questions
Subject: Re: Serial Port XON/XOFF problems
Message-ID: <882@csun.UUCP>
Date: Mon, 9-Nov-87 23:49:55 EST
Article-I.D.: csun.882
Posted: Mon Nov  9 23:49:55 1987
Date-Received: Thu, 12-Nov-87 06:53:49 EST
References: <749@pilchuck.Data-IO.COM>
Reply-To: abcscnge@csun.UUCP (Scott Neugroschl)
Organization: California State University, Northridge
Lines: 58
Keywords: Serial, XON, XOFF, handshake
Xref: mnetor comp.sys.ibm.pc:9965 comp.unix.questions:4866

In article <749@pilchuck.Data-IO.COM> jgray@toad.pilchuck.Data-IO.COM (Jerry Late Nite Gray) writes:
= 
= Lately we have been trying to solve a problem with one of our hardware products
= in which we have trouble transferring data to a PC a high serial rates. 
= We were hoping that XON/XOFF handshaking protocol would work properly with all
= software communication programs to allow flawless transferring of programmer
= data to and from the PC. PC to programmer transfers are fine, but the "upload"
= to the PC drops characters "occasionally". 
= 
= It seems that the actual baud rate, where things break down, depends on the
= software running on the PC as well as the clock rate and the class of PC/XT/AT
= (and assuming 386 machines, though this hasn't been tried yet). For example
= software not designed for throughput (translation: uses DOS interrupts
= for everything) can't handle 4800 baud. But even fairly high throughput
= packages (Procomm, Vterm, etc.) break down in the 9600 and 19200 baud range
= depending on the situation. Uploading to the screen is frequently flawless
= (and pointless when you think about it) though saving data to a file
= (especially to a floppy) causes character dropping.
= 
= At first I thought this was due to our units not ceasing the transmission of
= data soon enough after receiving an XOFF character. After much experimenting
= with serial driver code, UART settups and the like I ruled this out and
= started analyzing the serial bus with some available equipment. Low and behold,
= it appears that the errors hardly ever occur with the events of XOFF
= transmission from the PC. It seems that in all of the cases I have tried so far
= that the software package on the PC just doesn't send out the XOFF character
= when it should to prevent overruns.
= 
= So the point of this article is the basic question. Is the software/hardware
= performance for the serial port so bad in the PC domain that no high baud
= rate transfer can be guaranteed using XON/XOFF? I would be interested in other
= peoples experience in dealing with this problem.
= 
= PLEASE Email directly to me. I will summarize and post to the net if there is
= sufficient interest.
= 
= Incidently we have solutions that amount to "throttling" data by putting
= end-of-line delays as specified by the user so he can tailor his serial
= bandwidth to fit his processing overhead. This achieves "near" 9600 and
= 19200 baud rates (depending on DOS system). I have noticed that other
= software packages for the PC also support this mechanism for sending
= data to other machines.


We have a similar problem.  On our ZILOG System 8000 (their UN*X machine),
we lose data.  We maintain about 20 extra buffer slots, and manually
send our own XON/XOFF.  When the buffer is full except for those 20 slots,
we send the XOFF, but continue reading for circa 2 seconds.  Unfortunately,
we also have problems with our kernel losing data... We also thought
the problem was disk I/O, so we made a 20K internal buffer, and flushed
it only when we hit 20K.  We were sporadically losing data around every
15K or so.  Anyone whose had experience w/ZILOG's little toy, please
send advice...

Thanks in advance
-- 
Scott "The Pseudo-Hacker" Neugroschl
UUCP: {litvax,humboldt,sdcrdcf,rdlvax,ttidca,}\_ csun!abcscnge
      {psivax,csustan,nsc-sca,trwspf         }/