Xref: utzoo comp.dcom.lans:1909 comp.dcom.modems:2637 comp.protocols.tcp-ip.ibmpc:838 comp.sys.ibm.pc:20103
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!elroy!peregrine!ccicpg!turnkey!stanton!donegan
From: donegan@stanton.TCC.COM (Steven P. Donegan)
Newsgroups: comp.dcom.lans,comp.dcom.modems,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc
Subject: Re: Communication problems involving PC-Interface and Procomm / Kermit
Summary: Interrupt Wars, PC Throughput/Capacity
Message-ID: <77@stanton.TCC.COM>
Date: 8 Oct 88 00:49:30 GMT
References: <1053@rivm05.UUCP> <13035@cisunx.UUCP>
Organization: Stanton Public Domain Systems, Stanton, Ca.
Lines: 23

> When he runs kermit he gets what appear to be flow control problems
> resulting in a messed up screen display.
> >
> > BTW. file_transfer still works because of the protocols.
> >   .....
> > Does anybody have a solution for this problem?


I have reproduced this type of problem again and again in the lab. What is
happening is fairly simple. While running a networking package with file
system support and a communications program using the RS-232 ports and
interrupt driven I/O data will get lost on the RS-232 link. This is a very
simple problem - the PC, under the DOS operating system, is simply not
capable of handling both high speed (ethernet or starlan) I/O and interrupt
driven serial port I/O at the same time. Too many portions of DOS turn off
interrupt processing and lost interrupts during this time show up at any
serial rate higher than 1200 on an 8mhz AT, worse with slower systems. Most
networking software and the file transfer protocols under terminal emulation
programs can recover from the lost data, but in terminal mode you WILL
lose data and it will be visually obvious. The answer is - turn of the
networking during critical terminal emulation functions or get an operating
system for the PC that handles these interrupts more gracefully (like
UNIX :-)) ). Sorry, but I think you're stuck with the problem :-( .