vjs@calcite.UUCP (Vernon Schryver) (08/06/89)
A long note comparing 3.0e and 2.0.2 in which ISC is found acceptible:
After having difficulty getting a new Logitech bus mouse working with
DOSMerge 1.1+3.0e, and feeling abondoned, I ordered from ISC in NH from
here in CA. ISC's presales support was much better than the other amateur
UNIX houses I've dealt with. They answered questions on the conservative
side of complete accuracy. They care about answering the phone quickly.
The 75% offer is fair--they credited my full uport purchase price, but not
the $100 tape driver. For $499.50 on a credit card, I got C, DWB, VP/ix,
manuals, $0 tax (out of state? what about Santa Monica?), and UPS-blue.
(Oh, and something called "TEN/PLUS User Interface," which looks like
another case of MAC-envy, combined with raging emacs-is-the-universe.)
Without asking, an invoice came in the mail. I always had to call uport
more than once for each purchase. The post-sales support has been ok.
There have been none of the sullen, ever changing series of dishonest
answers to a single, repeated question that I so enjoyed from uport. ISC
seems to prefer their 800 number, tho I offered to use my nickel.
ISC manuals are not as complete as Microport's. They omit the important
half of DWB. The paper bound volumes are much harder to use than uport or
AT&T binders, tho with better typography. The wire-bound volumes are
terrible (bindings are always tangled; hard to close). Some man-pages are
repeated. Microport's release notes were too consise, but ISC's are too
verbose; I do not know which are/were worse.
The floppy driver is incredibly slow. The filesystem is great, not
suffering from the ancient free list botch. (The SDS 940 had bit maps;
there was no excuse for a free list in UNIX.) The slow floppy makes
installation painfully slow--too bad they don't distribute tapes like
computer companies. Their use of AT&T sysadm installation is nicer than
Microport's. It took about 30 hard hours to move all of my stuff from
uport to ISC, and I'm an old kernel hack with daytime access to source.
UNIX is will not make it in the mass market until and unless this improves.
The 1/4" cartridge driver is wonderful. No hangups. No disabled
interrupts during rewind. However, it is not available under DOS, making
VP/ix's file stuff even harder. Uport's was available under DOS, but did
not work. Like uport, mt(1) does not work, presumably because the driver
does not do standard ioctl's. They do not document but do ship mt(1).
They do document but do not ship tapecntl(1). They don't seem offer a
piece of offal like uport's tape(1) for rewinding, retensioning and
skipping, so I guess you have to hack your own. I see no way to reset
the driver, but only a piece of junk like uport's tape driver needs that.
The 8 virtual consoles are nicer, but more awkward to use. Since VP/ix
uses SYSREQ, they are still available with things like LOTUS, unlike uport
and DOSMerge. I don't know what would help.
There is kernel evidence of Weitek support, but no documentation, no *.a.
Implausibly, there are no words about 387's. Maybe they just work.
The at386 terminfo entry is broken--moria did not work--, but not as badly
as uport's. Recall that even uport's at386 net postings were wrong. ISC
includes terminfo source, making fixes easier.
There is a real csh, unlike the victim of AT&T lobotimization shipped by
uport. By itself, this made the pain worthwhile. No ksh, but I bet what
came with 3.0e would work. The uport Greenhills C compiler works.
The 2.2 smail-/bin/{,l,r}mail ISC ships is kaput. A sendmail port is
included, so with the publically available smail 2.5, you can fix things
better than you could with uport.
The ttymap(1) command does nothing for me. The sample maps are trashed
with backspace characters.
The ISC asy driver is better than uport's--DTR does the right thing; no
lock-ups. Watching a TB+ at 19.2 on a standard card hacked with 16550's in
a 20MHz Everex convinced me ISC has worse worst-case interrupt latency than
uport, causing the ISC asy driver to loose lots of characters, doing bad
things to TB+/UUCP through put. It's easy to hack Jim Murray's P.D. driver
enough to fit, and it does much better, tho not as well as it did with
3.0e. This is evidence of ISC or new AT&T SVR3.2 interrupt latency bugs.
VP/ix does not support background execution. Almost no I/O redirection,
contrary to the VP/ix manual. (For a good time, type "dir</dev/null"
Switch consoles & kill the shell to restore things). This is silly, since
the hooks to support DOS on a plain tty should be smart enough to do
nothing if fd's 1&2 are pipes or closed. Running DOS swill with make(1) is
a pain, tho possible. VP/ix is far less flexible then DOSMerge, but it has
far fewer bugs. Microsoft Word & Lotus work better, tho Word 5.0 cannot
understand the VP/ix image of the UNIX filesystem. Word does understand
DOSMerge UNIX files. (Note to ISC: Microsoft has never heard of a
"multiuser Word;" the "network" Word is just paperwork. This is a bug in
VP/ix, not "copy protection" in Word.)
I started calling Everex, ISC, et al because of mouse troubles. Guess what
does not work with VP/ix? A fix is promised in a future release and I
found a work-around, which kills the mouse under UNIX. I guess I won't be
buying X for a while. Still, ISC 2.0.2 is better than Microport 3.0e, so I
feel no remorse. If you think will Microport rise from its ashes, it would
be reasonable to stay with them for the 2-3 years before SVR4 is usable in
this market.
Vernon Schryver
vjs@calcite.uucp or ...{pyramid,sgi}!sgi!calcite!vjsjackv@turnkey.gryphon.COM (Jack F. Vogel) (08/08/89)
In article <57@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: >A long note comparing 3.0e and 2.0.2 in which ISC is found acceptible: [ ... much text deleted ... ] >The ISC asy driver is better than uport's--DTR does the right thing; no >lock-ups. Watching a TB+ at 19.2 on a standard card hacked with 16550's in >a 20MHz Everex convinced me ISC has worse worst-case interrupt latency than >uport, causing the ISC asy driver to loose lots of characters, doing bad >things to TB+/UUCP through put. It's easy to hack Jim Murray's P.D. driver >enough to fit, and it does much better, tho not as well as it did with >3.0e. This is evidence of ISC or new AT&T SVR3.2 interrupt latency bugs. This is a comment as well as a request for information. I find it odd that you say that the ISC asy driver is better than uport since I have not been able to get it to work properly at all. When using the driver and putting a getty on either tty00 or tty01 whenever the phone rings the damn thing just cycles DTR off and back on and a new getty is spawned. I do not find a driver that will never answer the phone to be terribly useful :-}. Of course I can force DTR on using a modem dip switch but this is unacceptable as well. I know it is not the gettydef entry (using 2400H) or the modem settings since it works with the above mentioned PD driver. That driver was fairly easy to port, the hardest part being figuring out the need for the minor() macro. However when using it I would periodically get kernel panics in tdrecint(). (I have 16450 UARTs). I don't know which is better a driver that will not answer the phone or one which panics the system when the phone rings :-} :-}!! My solution at the moment is to run both modems on the ICC card, that driver seems to work fine. Now the question I have is does anyone have any idea with what is wrong with the asy driver? I find it difficult to believe it is that broken. Is there a modem controlled minor that i don't know about or a configur- ation problem?? I have had a couple of cases of binary corruption in the ISC media, could that be the problem?? Any suggestions would be gladly received. -- Jack F. Vogel jackv@seas.ucla.edu AIX Technical Support - or - Locus Computing Corp. jackv@ifs.umich.edu
johnl@esegue.uucp (John Levine) (08/10/89)
In article <6344@turnkey.gryphon.COM> jackv@turnkey.gryphon.COM writes: >Is there a modem controlled minor that i don't know about or a configur- >ation problem?? ... Try /dev/ttyd0 and /dev/ttyd1, minor numbers 16 and 17. I find that they work reasonably well for my dialin Telebit. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 {ima|lotus}!esegue!johnl, johnl@ima.isc.com, Levine@YALE.something Massachusetts has 64 licensed drivers who are over 100 years old. -The Globe
woods@robohack.uucp (Greg A. Woods) (08/11/89)
In article <6344@turnkey.gryphon.COM> jackv@turnkey.gryphon.COM writes: > In article <57@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: > >A long note comparing 3.0e and 2.0.2 in which ISC is found acceptible: > > [ ... much text deleted ... ] > > >The ISC asy driver is better than uport's--DTR does the right thing; no > > This is a comment as well as a request for information. I find it odd that > you say that the ISC asy driver is better than uport since I have not been > able to get it to work properly at all. When using the driver and putting > [....] > > Now the question I have is does anyone have any idea with what is wrong > with the asy driver? I find it difficult to believe it is that broken. > Is there a modem controlled minor that i don't know about or a configur- > ation problem?? I have had a couple of cases of binary corruption in the > ISC media, could that be the problem?? Any suggestions would be gladly > received. 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. Second, there is a modem control minor device, partially described in asy(7). RTFM :-) Finally, yes, there was a bug in the earlier releases. 1.0.6 is definitely broken, and I have no idea what 2.01 is like. Presumably 2.01 has the new HDB with modem control features as well. This version of HDB works wonders on my 3b2, but we still suffer with 1.0.6 at work. The trick there is to tie DCD high, and forget about expecting a SIGHUP on loss of carrier. -- 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
vjs@calcite.UUCP (Vernon Schryver) (08/12/89)
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
pim@cti-software.nl (Pim Zandbergen) (08/12/89)
vjs@calcite.UUCP (Vernon Schryver) writes: >In article <1989Aug10.230329.24196@robohack.uucp>, woods@robohack.uucp (Greg A. Woods) writes: >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. This is exactly how NDELAY should work. You should set CLOCAL immediately after having opened with O_NDELAY, if you want to keep the line after having turned off NDELAY. Cu and uucp will do this if you specify \M (set CLOCAL) and \m (turn it off) in the Dialers file. This feature was introduced in HDB uucp in System V r 3.1. -- Pim Zandbergen internet : pim@cti-software.nl CTI Software BV uucp : ..!uunet!ctisbv!pim Laan Copes van Cattenburch 70 phone : +31 70 542302 2585 GD The Hague, The Netherlands fax : +31 70 512837