Racal-Vadic and Data General

[jo...@uw-nsr.uucp]

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

[ber...@clio.uiuc.arpa]

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.