csg@pyramid.UUCP (02/22/87)
I recently borrowed a pair of Racal-Vadic 9600VP modems to give them a work-
out. The results were interesting, if not particularly exciting.
BASIC STUFF:
The 9600VP is a packetized 9600bps modem, conceptually similar to the Telebit
Trailblazer although very different in implementation. Bell 103, Bell 212A,
and the packetized mode (V.29) are supported. There is no V.22bis. Both the
Hayes "AT" and traditional Vadic-style autodialing are supported.
The high speed mode uses V.29 QAM encoding, half duplex, with a full speed of
9600bps and automatic fallback to 7200, 4800, and 2400. MNP is used for error
correction, although it is Vadic's "Superset MNP," and includes compression.
The 9600VP is incompatible with all other 9600bps modems, and will not commu-
nicate with normal MNP modems even at slower speeds.
High-speed full duplex is "emulated" using a technique Vadic calls Dynamic Du-
plexing. 1200bps full duplex ("interactive mode") is used as long as the input
buffers of both modems contain fewer than 150 characters. When this threshold
is crossed, the modems switch to V.29 half-duplex ("file transfer mode") until
the buffers are empty. Vadic recommends that the block size be a multiple of
3K. The time to switch carriers is described as long compared to normal Kermit
packet size, but "inconsequential when factored over the required 3K block."
The modem is packaged in Vadic's traditional wide, flat, chisel-shaped beige
plastic cabinet, with a front panel composed of a row of nine LEDs and twelve
illuminated membrame switches. The status LEDs include the usual TD, RD, DTR,
DCD, and DSR, but no Off Hook. RI and CTS are also displayed, but RTS is not.
A tri-color LED under the speed-select switch indicates the connect speed; the
HS LED lights when V.29 is in use. An EC LED flashes when errors are corrected.
The membrane switches are no where near as useful as in the RV212 modem; you
can enable various test modes, set the speed, select sync/asynch, and switch
between talk and data modes; but you can only dial numbers that were saved in
memory, and cannot set the options. Of course, most modems have no front panel
at all (e.g., Hayes, Courier, Telebit).
There is no monitor speaker.
Power is supplied by a 2x3x4inch brick with three feet of cable coming out of
each end, so you don't have to hassle with the power brick covering two plugs
on your outlet strip. The brick produces filtered, regulated DC, unlike most
modems where the brick is just a step-down transformer and the power supply is
inside the modem.
A peek under the hood reveals a pair of Zilog Z80B CPUs running at 5.5Mhz, two
8K and one 2K CMOS SRAMs (the 2K gets standby power from a nicad cell), and a
Rockwell piggyback board with an R5300, R5301, and 10462. (I thought that was
Rockwell's 212A chip set -- anyone know for sure? The R5310, R5311, and 10464
are the V.22bis chipset.) Except for the CPUs and the line drivers, all chips
are CMOS. Line switching is done by a rather loud mechanical relay.
There is no cooling fan, which is touted by Vadic as a feature; the unit did
seem to keep cool enough on my shelf. One possible trouble spot, though: the
nicad cell is soldered to the board (typical :-( ) and it runs *hot*. Seems
silly in a $1500 modem not to make that battery customer replacable.
ADMINISTRIVIA:
The test systems were both Pyramid 98x dual processors. pyramid, our mail/news
server, was running its usual nightime mix of a half dozen uucp and news jobs,
plus background test suites from the Cobol and Fortran crowd. pyrtech, the
home machine for RTOC, was idle. vmstat(1) was running continuously on both
machines to watch CPU load. A non-intrusive Halcyon datascope watched the data
on the connection to pyramid. I don't have the necessary equipment to monitor
phone line levels and such.
I modified my "generic" Vadic dialer to select the 'f' protocol when the modem
connected with an 'ONLINE 9600' message, and used my uucico that understands
fixed interface speed. The modems were tested both with full autobauding and
with speed fixed to 9600 bps. I did not test the AT command set, other than to
verify that it worked.
The 9600VP firmware is dated "Aug 28, 86", which Vadic told me was the latest
version. (A newer version recently became available.)
RUNNING THE TESTS:
I had been told by the tech who evaluated the 9600VP for our Field Service
department that the modems had not be able to reliably establish a connection.
The Racal-Vadic rep who loaned him the modems blamed this on our Rolm CBX
phone system. When I called Vadic, the rep claimed that this was not true; the
only problem had been the tech's incorrectly setting the flow control.
In fact, our two 9600VP's do not work through a Rolm CBX. The connection would
usually "catch," but transfer was very slow, the front panel 'EC' light (error
correction) would flash constantly, and the modems would finally disconnect
after 20K bytes or so. For testing, then, I abandoned my usual outgoing phone
lines through the CBX and went with a direct local Pa Bell line. That worked
without a hitch.
I queried Vadic about the CBX. After seeing for himself on the datascope that
I was not botching the flow control, the Vadic rep claimed that no high-speed
modem could be used over a CBX because of the digitizing process it uses. I
immediately pointed out that our Trailblazers regularly shovel data through at
1050cps. After a pregnant pause, he decided to take back both of the loaner
modems, and promised he would take them to ROLM for analysis, and return them
when they worked over the CBX. That was about a month ago.
Peter Holzmann at Octopus Enterprises was kind enough to dredge up information
about the CBX and QAM encoding. It appears that a properly set up digital PBX
should have no trouble passing the Vadic's 9600bps QAM. The problem would thus
have to be in line levels, line balancing (could cause echos), or something
similarly mundane.
RESULTS:
Interactive was no contest: the 9600VP was *very* pleasant to use, with none
of the annoying pauses that plague the Telebit. Keystrokes were always echoed
promptly, and full screen refreshes came in a rush. For interactive terminal
work the dynamic duplexing seems to do its job. I did notice regular pauses
during very large runs of output (like ls -l /usr/bin), but they were not
bothersome. The Vadic rep said those were for "retraining." According to the
manual, the modem drops back to full-duplex 1200 every 3K bytes to exchange
ECC packets.
One serious problem: flow control is enabled only when the modem is running
V.29. So if fixed interface speed is used (9600bps) for a 212A connection, it
is very easy to overflow the buffers. For this and other reasons, the 9600VP
should be avoided for normal Bell 212A or 103 calls.
UUCP 'g'-protocol was worse than awful. 70 to 100cps, with lots of retries due
to mangled packets. The modem never saw a big enough packet for it to get out
of interactive mode, which I expected, but the bad transfers worry me. I saw
nothing on the datascope that made it clear what was happening. It may be due
to the lack of flow control in interactive mode, or some weird boundary
condition switching between interactive and fast mode.
Using the 'f'-protocol, I got a consistent 718 characters per second (after
subtracting out the 'f' overhead). And I mean *consistent*. You could have
used it for a stopwatch; very different from the Telebit, which constantly
varies the data rate. The datascope confirmed that transfer was occurring in
bursts at 9600bps, with the regular pauses for "retraining." If compression
was involved, it worked well enough that I could not see it.
Flow control technique didn't seem to matter; the Pyramid and the 9600VP were
equally happy with XON/XOFF or CTS/RTS. The loaded Pyramid had a lot of slop
on its XOFF response, too; up to 24 characters would trickle out. The 9600VP
always stopped within 3 characters of XOFF.
I don't have SLIP available, so I could not test that. Mark Weiser at Univer-
sity of Maryland has reported very good performace, with a real data rate (ftp
and rcp) of about 690 cps. Telnet was terrible, however, since the big TCP/IP
packet headers confuse the dynamic duplexing algorithm.
Impact of the 9600VP on the system was surprising, less than 1% CPU load. This
is actually less than that of a normal 2400bps modem using 'g'-protocol (3%),
and much less than that of the Telebit running 'f'-protocol (8%). I have to
believe that this was a fluke of the 9600VP and Pyramid SIO combination; I
sure wouldn't expect to see that kind of results on a DH-11.
MISCELLANEA:
Interface autobauding worked well, which is an advantage over the Telebit.
Good thing, too, since you really can't use fixed interface speed because of
the lack of flow control.
Call progress monitoring worked well, although not as well as on the Telebit
or on the better 2400bps modems (e.g., AT&T 2224).
As usual, all the option numbers are different from all previous RV modems.
The help menu lists all the commands and options, but not what their arguments
or values mean. The Trailblazer suffers from the same half-hearted menus.
The DCD lines can be set to RS-232C, always on, or Vadic's "Computer Systems
Interface." The DCD line is asserted until the modem attempts to dial a call.
DCD then falls until a carrier is received; it then is asserted until the true
carrier falls. I could get the uucico Vadic dialer to use this instead of
forcing DCD always on, but I didn't think it was worth the effort. (I prefer
Microcom's design, where DCD pulses low at the off transition of the real
carrier.)
212A calling other modems was disappointing, definitely below par. The 9600VP
seemed to be very vulnerable to line noise, and often failed to connect.
SUMMARY:
Like the Telebit Trailblazer, the Racal Vadic 9600VP is a bag of plusses and
minuses. It does what it's supposed to do pretty well; so does the Telebit.
Both can pay for themselves in telephone bills, and are faster then PDNs. Both
are a pain to use with existing software.
Line quality was perfect, so I'm not surprised that I never saw fallback. I
have no idea how the 9600VP would perform over noisy lines, although its be-
havior on the CBX worries me. I never saw it pass bad data, however, something
the Trailblazer is known to do when line quality is exceptionally poor.
Plusses are: excellent interactive response; comparatively low cost ($1500
list, $1050 to educational institutions); simple design (should be reliable);
some handy front panel switches.
Minuses are: No V.22bis; poor 212A; no monitor speaker; overly sensitive to
line characteristics; a trifle slower than a Trailblazer on perfect lines.
If it were my money, I'd be very reluctant to buy either the 9600VP or the
Telebit Trailblazer right now. The 9600VP is the clear winner for interactive
high speed, but the Trailblazer has a very good V.22bis (which we use a lot
here), and an slightly superior file-transfer capability. Both seem to pale
next to the crop of 9600/1200 reverse channel modems that are now available.
<csg>butler@stsci.UUCP (02/26/87)
Last November I had to evaluate several high speed modems for use in some
networking applications. I have always meant to do a full writeup and post
to the net, but have not had time. My findings at the time were that the
RACAL-VADIC was more pleasant as an interactive use modem than the Telebit,
and was a bit cheaper. A modem that was of interest but which arrived late
for me to do much testing and evaluation was the ADDCOM. It looked to have
some of the features the VADIC lacked (speaker, line quality indicator).
As far as their use, we are using them to implement some phone links while
we wait for DDS lines from the Death Star company. They don't show us the
throughput I wish they did (Still no comparison to a 9.6k DDS Line) but when
the packets get big, the modems push 'em through pretty good. Throughput seems
to be more on the order of 7200 than 9600 (because of the resync'ing the
modem does I guess). Telnet or "set host" are not the nicest things, but file
transfer isn't as bad as over 1200 baud modems by a long shot. I have NEVER
seen a bad character come out of the modem. I HAVE seen it hang up due to
line noise.
We had some real problems with our phone switch and these modems. We ended
up getting direct lines from the local carrier for these modems. Seems with
all the error correction and compression going on it takes a moment for the
modem to realize the phone has been hung up. Our phone switch generates a
"Busy" signal when the remote party hangs up. The modem kept trying to
recognize a carrier in the "busy" signal. I'm not sure whether to blame the
modem or the phone switch. The Telebit had a similar problem with the phone
switch.
There has been some difficulty getting trans-continental phone calls to connect
at something above 1200 baud. It seems to depend on solar activity, lunar
position and Nancy Reagan's mood.
Perhaps I'll post more later if there is further interest on this subject.
Alternatively, interested parties should feel free to contact me at one of
the addresses below.
Lee A. Butler
Space Telescope Science Institute 3700 San Martin Dr. Baltimore MD 21218
Arpanet: butler@stsci.arpa | butler@brl.arpa
Usenet: seismo!stsci.arpa!butler | {noao,astrovax,cfa,charm,nrao1}!stsci!butler
SPAN: scivax::butler (6405::butler)
Phone: (301) 338-4531
--
Lee A. Butler
Space Telescope Science Institute 3700 San Martin Dr. Baltimore MD 21218
Arpanet: butler@stsci.arpa | butler@brl.arpa
Usenet: seismo!stsci.arpa!butler | {noao,astrovax,cfa,charm,nrao1}!stsci!butler
Phone: (301) 338-4531