abcscnge@csun.UUCP (Scott Neugroschl) (11/10/87)
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 }/whh@pbhya.UUCP (Wilson Heydt) (11/16/87)
In <882@csun.UUCP> Scott Neugroschl writes: >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 have a similar problem. On our ZILOG System 8000 (their UN*X machine), >we lose data. . . I've been using kermit (rel 2.27) between a Compaq--at 4.77 MHz you don't get much slower--and a Cadmus 9730 at 9600 bps with no problems at all. Have you tried kermit for this? (The version of kermit I have for the Compaq only goes to 9600 bps so I don't know about 19.2 kbps) ========================================================================= Hal Heydt | Analyst, Pacific*Bell | Real men write self 415-645-7708 | modifying code. {dual,qantel,ihnp4}ptsfa!pbhya!whh |