dave@lsuc.uucp (David Sherman) (03/03/88)
This old workhorse, lsuc, is generally a fine machine for our needs.
It's a Perkin-Elmer 3220 running "Edition VII Workbench", which is
v7 with a few extras from BSD. Its one wart, and one that's now
starting to bother me severely, is that it can't grok characters
arriving at >1200 bps. For output, it's fine; I read netnews at
19200 and it's noticeably twice as fast as 9600. But on input, whether
uucp on a phone line, uucp on a direct connection, data from our PADs,
or even function keys on a high-speed terminal which send multi-char
sequences, it loses chars randomly and unpredictably.
I asked P-E about it once long ago (we have source, so we don't
have software support) and was told it's a bug in the terminal
driver.
As our UUCP and netnews connections grow, it becomes harder and
harder to do everything at 1200 baud. I'd get a Telebit if we
could use it. 1 in + 3 out newsfeeds, plus about 40 regular uucp
mail connections, keep our 1200 baud modems (5 of them) humming.
Does anyone have any suggestions as to how I track down and
fix this bug, if indeed it's in the terminal driver. I have
some familiarity with the terminal driver, but not in debugging
this kind of problem. Any pointers to the likely culprit would
be appreciated. If the expertise required is the type of black art
which can't be explained, we'd be willing to pay someone to fix the bug.
David Sherman dave@lsuc.uucp
The Law Society of Upper Canada
Osgoode Hall
Toronto, Canada M5H 2N6
(416) 947-3466
--
{ uunet!mnetor pyramid!utai decvax!utcsri ihnp4!utzoo } !lsuc!davenarayan@tandem.UUCP (Narayan Mohanram) (03/05/88)
The problem is that the UART on the PE terminal board can handle only one character. If you run faster than 1200 baud, then the interrupts come in faster than every 50 ms, which kind of makes interrupt processing impossible. So things get dropped on its face. I fought this problem even when I had sources to it. Last time I remember, you could tell the comm board to collect bytes until a certin number of characters or a certain character was received, but for UUCP, there was no framing character, that could distincly tell the Comm board to interrupt. I think you are stuck at 1200 baud. narayan@ATI.TIS.LLNL.GOV
ali@pyrltd.UUCP (Ali Shirnia) (03/08/88)
dave@lsuc.uucp (David Sherman) writes: >It's a Perkin-Elmer 3220 running "Edition VII Workbench"... >It can't grok characters >arriving at >1200 bps. For output, it's fine; I read netnews at >19200 and it's noticeably twice as fast as 9600. > >I asked P-E about it once long ago (we have source, so we don't >have software support) and was told it's a bug in the terminal >driver. The problem is with both the terminal driver and the COMMS MUX on the Perkin-Elmer(Concurrent) Hardware. The terminal driver routine (ttyrint) looks for characters in the COMMS MUX's buffer. The problem is that the COMMS MUX has a 1 (one) character buffer, so you gotta be real quick to get this character off the COMMS MUX otherwise it gets overwritten by the incoming stream of characters. The terminal driver has to be very fast. If you want to fix the problem on ED7 you really gotta tear the driver apart because of the size of your performance window (i.e. 1 character). I remember loosing characters at 600 Baud. I take it you have not upgraded to Xelos because of the address space of the 3220. This problem is cured on Xelos (as far as I can remember). Apart from understanding and sympathy there is little I can do for you!! Best of luck -m------- Ali Shirnia Phone : +41 252 373035 ---mmm----- Pyramid Technology Fax : +41 252 373135 -------mmmmmmm- UUCP : <england>!ukc!pyrltd!ali