Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!mailrus!ames!sgi!calcite!vjs From: vjs@calcite.UUCP (Vernon Schryver) Newsgroups: comp.unix.microport,comp.unix.i386 Subject: Re: life after death (of uport) Summary: 2.0.2 is better, not good Keywords: ISC-2.0.2 uport-3.0e Message-ID: <60@calcite.UUCP> Date: 11 Aug 89 17:08:59 GMT References: <57@calcite.UUCP> <6344@turnkey.gryphon.COM> <1989Aug10.230329.24196@robohack.uucp> Organization: Rhyolite Software, Mountain View, CA Lines: 56 In article <1989Aug10.230329.24196@robohack.uucp>, woods@robohack.uucp (Greg A. Woods) writes: > ... > First off, you do not say which version of ISC 386/ix you are working > with. The one described as being good is from 2.02.... > Greg A. Woods > woods@{robohack,gate,tmsoft,ontmoh,utgpu,gpu.utcs.Toronto.EDU,utorgpu.BITNET} > +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario; CANADA Ahem. In the original article in this string, I meant to say that the ISC 2.0.2 asy driver is far better than the Microport 3.0e asy driver, in the sense of "less bad" rather than absolutely "good." I've observed some serious difficulties. First, the 2.0.2 driver frequently looses characters on this Everex Step/20 with a TB+ at 19.2 on a card with 61550A's. I have not hacked the code to get the UART status to prove that overruns are happening (no source, of course), but watching the results of `uucico -x9` and listening to the speaker convinced me. Jim Murray's driver also looses characters, tho much less often. My result is a loss of UUCP performance from 1400 for uport to 1100 with ISC, both with Jim's driver. I suspect the ISC version is not turning on the FIFO. There is a reference to "16550" somewhere in the conf. files or documents, but ISC techincal support knows nothing about it. A moment's thought about now many serial cards come with 16550A's instead of 16450's offers a clue. I am concerned that this (presumed) overrun problem shows terrible interrupt latency elsewhere in the kernel, which will be difficult to find, tho perhaps easy to fix. Second, the 2.0.2 driver is said by ISC technical support to not support the industry practice RTS/CTS flow control. (It's not "standard" as in RS-{232C,422,...}, but it is a de facto standard.) The 2.0.2 asy driver does not correctly understand DCD. If you try `cu -d`, you'll notice that SVR3.2 cu(1) and UUCP like to open the device with and later turn off NDELAY. The 2.0.2 driver seems to understand NDELAY to mean (1) "open even if DCD is false, and die if ever NDELAY and DCD are both false", instead of (2) "open even if DCD is false, and do not pay attention to DCD until DCD has been true." Whatever, the result is that cu(1) looses the port as soon as it turns off NDELAY. You'll notice that this use of NDELAY differs from the Microport scheme of relying only on minor device numbers, and the Sun use of CLOCAL. Code of mine using NDELAY as (2) above in another universe coexists successfully with uugetty, HDB UUCP, cu, SLIP, et al, so I think it's a good idea. The only work-around I could discover before abandoning ISC's driver was to wire DCD permanently true. You might try the SVR3.[01] cu and uucico. This may be needed only on an out going line. The ISC 2.0.2 use of NDELAY seems to apply not only to ttyd[01], but also to tty0[01], which seems like another bug. I've been told Jim Murray's driver "will not work", and I must admit that while it works for me, I do not use COM ports in VP/ix. I've also heard that ISC is testing an improved driver, but I do not know if these specific problems have been fixed. Vernon Schryver vjs@calcite.uucp or {sgi,pyramid}!calcite!vjs