johnl@esegue.segue.boston.ma.us (John R. Levine) (02/15/90)
It's widely known that 386/ix (2.0.2, new X5 driver in case you care) async
throughput stinks, particularly if your async port has an unbuffered 8250
UART. So I got a 16550A, unsoldered the 8250 from my internal Telebit
modem, soldered in a socket, and stuck in the 16550A. I can send stuff to
other sites at 1200-1400 cps, which is what I hoped for. Inbound news is
still a lousy 500 cps. What gives? The modem is set up as ttyd1, with tty00
being a mouse that I don't use much. That wouldn't be a problem, would it?
--
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."jackv@turnkey.gryphon.COM (Jack F. Vogel) (02/16/90)
In article <1990Feb15.070638.1086@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: >.... I got a 16550A, unsoldered the 8250 from my internal Telebit >modem, soldered in a socket, and stuck in the 16550A. I can send stuff to >other sites at 1200-1400 cps, which is what I hoped for. Inbound news is >still a lousy 500 cps. What gives? The modem is set up as ttyd1, with tty00 >being a mouse that I don't use much. That wouldn't be a problem, would it? John, I would check with the site that is sending you the news and see what kind of figures they show. I suspect what you will find is that their figures show the 1200-1400 cps even though yours look slower. I found this when I run the TB+ on the standard COM port, it must be something to do with the buffering between the modem, the port and memory. However, with the modem on my Bell ICC (which has 256K onboard) the figures are nearly identical in and out (i.e. 1200-1600). The only reason I don't always run on the ICC is that the crazy thing has a tendency for its onboard software to crash or something, so when I leave town for a week I move it. This brings up a question, are others out there using the ICC seeing this sort of behavior? Basically the symptom is that DTR will go down, you could still open the port, but things are just dead. You can simply use the supplied idebug program and reset the card and then things are fine, but needless to say this doesn't make for very good unattended operation :-}. This happens intermittently, but quite frequently. I have never been able to connect a crash with any particular event. Disclaimer: IMHO only. -- Jack F. Vogel jackv@seas.ucla.edu AIX Technical Support - or - Locus Computing Corp. jackv@ifs.umich.edu
cpcahil@virtech.uucp (Conor P. Cahill) (02/18/90)
In article <6717@turnkey.gryphon.COM> jackv@turnkey.gryphon.COM writes: >This brings up a question, are others out there using the ICC seeing this >sort of behavior? Basically the symptom is that DTR will go down, you could We saw the same kind of behavior on our ICC card and were never able to come up with a reason for it. It sometimes happened when there was only 1 port in use at 9600 baud and sometimes worked fine when all 6 ports were being used heavily at 38400. Since I got my megaport, both my ICC and maxspeed cards have been gathering dust in my closet. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
jgd@rsiatl.UUCP (John G. De Armond) (02/19/90)
johnl@esegue.segue.boston.ma.us (John R. Levine) writes: >It's widely known that 386/ix (2.0.2, new X5 driver in case you care) async >throughput stinks, particularly if your async port has an unbuffered 8250 >UART. So I got a 16550A, unsoldered the 8250 from my internal Telebit >modem, soldered in a socket, and stuck in the 16550A. I can send stuff to >other sites at 1200-1400 cps, which is what I hoped for. Inbound news is >still a lousy 500 cps. What gives? The modem is set up as ttyd1, with tty00 >being a mouse that I don't use much. That wouldn't be a problem, would it? John, You might want to rig up some send and receive data indicators (LEDs or whatever) and watch the data as you receive your feed. I've noted on my external telebits that few other sites, especially larger machines, can keep the pipe full at 19200 bps. Especially if your feed is working from a modem server, your feed rate is pretty typical. Here at RSI, we get our primary uucp and News feed from emory which feeds its modems over an ethernet link. We generally average <800 cps. the problem is easy to observe with data lights. The feed is bursty and rather regular which probably means small packets on a busy ethernet. Remember too, that if you have spoofing turned on, the modem handles the ACK traffic and is the primary throttle to receiving speed. If your machine cannot for some reason, handle the incomming rate, you should see alarms in the uucico debug output. This symptom is very easy to spot with data lights. I will note that on this machine, a 20 mhz non-cached 386 clone, the X5 drivers would not reliably handle 19.2kb if any other jobs were running. Cron could kick something off and immediately characters would be dropped. The alarms in the debug output were obvious. We installed a smart async board (Stargate, highly recommended) and eliminated this problem. In any event, I'd highly recommend adding status lights to any internal modem. This is easy to do (low current LED and a resistor) and will help you solve many problems that are very difficult to instrument otherwise. John -- John De Armond, WD4OQC | We can no more blame our loss of freedom on congress- Radiation Systems, Inc. | men than we can prostitution on pimps. Both simply Atlanta, Ga | provide broker services for their customers. emory!rsiatl!jgd | - Dr. W Williams | **I am the NRA**