jgray@toad.pilchuck.Data-IO.COM (Jerry Late Nite Gray) (11/09/87)
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.
Thanks in advance,
---------------
Jerrold L. Gray
UUCP:{ihnp4|caip|tektronix|ucbvax}!uw-beaver!tikal!pilchuck!jgray
USNAIL: 10525 Willows Road N.E. /C-46
Redmond, Wa. 98052
(206) 881 - 6444 x470
Telex: 15-2167abcscnge@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 |