--- Robert F Schaefer <rschaefe_at_gcfn.org> wrote:
> >
> >>ISTR hearing mention a while back that the remote diag console on the
> >>6K VAXen spoke a flavor of serial DECnet...
> >
> > The remote diag consoles spoke (I guess) plain
> > serial between the console and the local DEC
> > Remote Diagnostic Console box and some
> > undocumented, secret (and now probably forgotten)
> > protocol between the RDC and its partner unit
> > at the support centre.
>
> The link between the little modem-shaped box connected to the console
> port and wherever it ended up at is what I was interested in. I
> thought it was just a plain old modem, but someone said... that
> it was a flavor of DECnet. It's not quite as interesting to me now.
DECnet is a byte-oriented protocol over an unspecified physical
medium (typically RS-232 or V.35). What may be occurring here
is that the modem _is_ a plain-old-dumb (sync?) modem, but the byte
protocol between the VAX and the Customer Care center in Colorado
(where Remote Diagnostics folks used to reside) is a DDCMP or simplified
DDCMP connection as opposed to some other proprietary method of
packaging the requests and data.
Older remote diag stuff (L0006? in an 11/750) would certainly have had
some odd, proprietary, possibly interactive method of communicating
with Field Circus. I can imagine a human really dialling in and
issuing interactive commands at an 11/750. By the time the VAX 6000
came out, they probably wanted a program doing the low-level work,
so they may have rolled out a networking protocol which is not
based on human readable commands and <CRLF> command seperators, and
that allows for in-band error detection - all the things we like
about network protocols - automatic and robust, unlike throwing
commands at a console prompt.
> > As for running DDCMP over the console line, it's
> > probably possible but usually not a good idea
> > (the console line is usually deliberately pretty dumb,
> > the principle being that it's harder to screw up that
> > way).
>
> Wouldn't try it anyway. I have enough trouble with dumb serial lines!
Not just dumb in the sense of a dumb terminal, but older VAX console
lines tend to be resource hogs on the CPU, sometimes due to
the interrupt level the UART comes in at, sometimes just due to
the fact that it is a programmed-I/O device, not DMA like a DMF-32
or other "TXDRIVER" (vs "TTDRIVER") compatible serial device.
It's why I was happy to put that DMB32 of yours into my 8200 - I have
four console serial lines to start with: OPA0 and three others.
I have been told that they exact a toll on performance to use them
heavily (Kermit and the like). The normal mode for a VAX was to
stick a printing terminal on OPA0 and let it spill paper on the floor
all day. Who cares if a 300 bps connection gets serviced at half
the max transfer rate - it's not like a _user_ is waiting for the
printing to finish. For output, the OS can pace the console printing
and defer it until later, giving better response for the live humans on
the other ports. Contrast how long it takes for an operator message to
print vs. when the OS panics - with absolutely nothing better to do
that scream for help, the console speed picks up - you can hear the
change in the cadence. That's how we always knew the VAX crashed - by ear.
So... DEC didn't typically care to make the console a high-performance
port because in practice, it wasn't necessary to give high performance.
Make 'em buy an add-in card.
The above does not apply, of course, to VAXen and how they were used
by the time desktop-sized VAXen came around. Those tended to be used
more like shared PeeCees, and the console serial port was no different
than any other serial port in the machine, kinda like a SPARCserver.
-ethan
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
Received on Wed Jun 05 2002 - 15:33:18 BST