john@uw-nsr.UUCP (10/25/86)
After converting to DG/UX revision 3.00 people dialing in to our system with Racal-Vadic equipment get so many errors that they can't use the system. We have a Data General MV/10000 running DG/UX 3.00. Of the 40 tty lines available eight have modem control and are attached to various modems, line drivers and multiplexors. Five of the eight lines are connected to Micom 300 / 1200 baud modems set up for auto- answer. They are not set up for autobauding. In the past they have always worked flawlessly. Under the previous revision of DG/UX (2.02) all of our users were able to dial in and use the system. However, one of the major changes in revision 3.00 of DG/UX was `totally rewritten' IAC code. This is code that it downloaded at boot time to the Intelligent Asynchronous Controllers (IAC's). Under the new revision people dialing in with equipment manufactured by Racal-Vadic get so many errors that the can't use the system at all. Often what they type is not echoed but seems to be received; other times the echoed character is wrong although the received character is correct. To date the problem seems to be confined to Racal-Vadic VA3434 1200 baud acoustic couplers and a Racal Maxwell 1200 / 2400 baud modem being used at 1200 baud. I am sorry but I don't have a model number on the latter. I am writing this from home over a Hayes Smartmodem. It works fine and any errors can be attributed to operator error :-) I seem to recall some folklore about Racal-Vadic equipment being somehow different from other types of equipment. However, when everything is working I don't save such information. Now I am wishing that I had. So, if anyone could shed some light on this situation I would certainly appreciate it. Of course I suspect that the new IAC code is the problem. However, I am certainly no TC expert and would welcome suggestions about possible problem areas. Thanks, John -- John Sambrook Work: (206) 545-7433 University of Washington WD-12 Home: (206) 487-0180 Seattle, Washington 98195 UUCP: uw-beaver!uw-nsr!john
berger@clio.Uiuc.ARPA (10/29/86)
I don't know enough about your hardware to determine how likely it is, but is it possible that your baud rate clock was affected by the new software? I ran into a problem similar to what you describe - dialup lines with high grade commercial modems had lots of errors, but the ones with cheap plastic modems worked better. The problem turned out to be a design flaw - the baud rate master clock operated at a rate that had a 1.7% error when divided down - the Western Electric 212a specs call for a maximum 1% (high) error (1.5% low). The commercial modems wouldn't tolerate a higher-than-spec error, but the cheap modems did. We resolved the problem by changing the baud rate master clock speed and all the baud rate divisors programmed into the comm board. And our new NEC modems have a switch for Western Electric specs vs. wider speed fault tolerance.