NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/vmsnet/misc/1161

Internet Message Format | 1993-01-21 | 6.6 KB

Xref: sparky vmsnet.misc:1161 vmsnet.internals:1779 comp.sys.dec:7032 comp.org.decus:1134
Path: sparky!uunet!munnari.oz.au!comp.vuw.ac.nz!zl2tnm!toyunix!don
Newsgroups: vmsnet.misc,vmsnet.internals,comp.sys.dec,comp.org.decus
Subject: Re: Need faster async board...dlv11-J?  Something else?
Message-ID: <[e-mail]>
From: [e-mail] (Don Stokes)
Date: 21 Jan 93 10:58:44 GMT
Sender: [e-mail] (GNEWS Version 2.0 news poster.)
References: <[e-mail]>
Distribution: world
Organization: The Wolery
Lines: 123

[e-mail] writes:
> In article <[e-mail]>, [e-mail] (Don Stokes) writes:
> > [e-mail] writes:
> >> In article <[e-mail]>, [e-mail] (Don Stokes) writes:
> >> > Anyway, I might have a go at fiddling the driver to support 38400 (if I
> >> > can find a terminal that will go that fast!) and see how things get on.
> >
> >> I really don't see the point.  Even if you do this the actual throughput for
> >> writes won't exceed 19.2kbps.  This is (according to the manual) a limitation
> >> of the on-board DMA logic, so nothing you do to the UART chips will get around
> >> this.  You certainly can't test read throughput to 38,400 bps unless you are
> >> planning to type VERY damn fast.
> >
> > Don't knock it.  I'm having fun.  8-)
>
> Ah, now I understand!  :-)

Actually, we wound Clive's SLIP connection up to 38400 today (with YFDRIVER
hacked to do 38400, although we haven't bothered with the RTS stuff).
It _did_ make a noticable difference.  The CMU SLIP driver doesn't seem to
like operating full-duplex -- if at 19200, I chuck 800 byte packets at it to
return, it can keep up.  900 bytes and it loses very quickly.  At 38400, the
wall is more than 1200 bytes, which is about what I expect, given that output
from the DHV11 is still effectively at 19200.  Remember, we are talking
about a MicroVAX II here (attached via a Cisco 516-CS terminal server).

> (These modern chip technologies have their drawbacks.  In the good old days I
> worked on an HP machine that used a separate 7x8" card for *each* serial
> port... [instruction set looked a lot like alpha's, too!] and when we wanted it
> to go faster than HP provided for, why we just added a wire to pick off the
> baud clock a few stages earlier in the divider chain.  I just bought a
> two-serial-port card for a PC... it has *one* chip on it.  Now, I ask you, how
> much fun can that be?  :-)

Hey, you just have to make your own fun!  Those ports will go at 110kbps or
so, but the broken DOS support won't drive them that fast.  Ya gotta get to
the bare metal to drive the thing properly.

In these parts, V23 modems operating at 1200bps receive and 75bps transmit
were popular for a long time (I still have a couple batting around here; one
built around an AM7910 "world chip" and another built mostly from discrete
components).  To drive those modems from a PC, you set the 8250 to receive
at 1200 bps, and bit banged 75 bps with the break line.....

The odd one of these modems still appears from the woodwork from time to
time.

> > Funny, that.  DHV11 Techical Manual, p/n EK-DHV11-TM-001.  (c) 1983.
>
> It's worth noting that this formula for order number applies to LOTS of DEC
> hardware tech manuals.  Whether or not the manual is actually orderable and
> contains useful information is, of course, another question.  (The later the
> printing date, the more "content-free" the manual, it seems.)

This almost seems like an opportune time to restart the olde thread about
the DEC handbooks.  Maybe not tonight.  8-)

> > Quick warning to neophytes: Hacks described below [for adding RTS flow
> > control] have not been tested.
> > They're not even complete.  It's your foot and your gun.
> Good stuff!  I've been mumbling about doing something along these lines...
> I'm going to see if I can complete it and put a nice wrapper around it.

OK, but note that I got the TT$M_MODEM!TT$M_HOSTSYNC test wrong.  (It'll take
the modified path if _either_ bit is set, not both.  Originally, I just coded
to look at TT$M_MODEM, until I realised that it would only call PORT_XOFF to
output a BEL if HOSTSYNC wasn't set, dropping DTR until the port was
re-initialised, which wasn't quite what I had in mind....)

BTW: WATCH and friends have good examples of tweaking the terminal class
driver/port driver interface vectors.

> It's a shame that similar things can't be done to add RTR/CTS flow control to
> LAT ports.  (Like the DHV it already honors CTS, even when it is set to "no
> flow control" or "xon/xoff flow control", but pin 4 just stays true all the
> time.)  Unfortunately the LAT terminal port driver apparently has no way
> to request modem control signal state changes.

Uh...

| Local> help set port flow control
| DEFINE/SET PORT FLOW CONTROL
|
| FLOW CONTROL specifies the characters or signals that control
| data flow at your port.
|
| FLOW [CONTROL] {CTS     }
|                {DISABLED}
|                {DSR     }
|                {XON     }
|
| CTS means that CTS/RTS modem signals implement flow control.
| [etc]

(This is DECserver 200 V3.1)

LAT has some pretty horrible latencies.  There are (or were) ways you could
fool a terminal server & the VMS driver so that the XON/XOFF flow control
gets done on the host instead of on the server.  It's _not_ pretty.  Even
if the LAT protocol allowed for the driver to do hardware flow control, it'd
be about as much use as an ashtray on a motorcycle.  To be effective, flow
control (whatever type) has to be done by the server.

> Unfortunately with uucp we can't wait a second to read a packet.  Or even
> three packets.  If we're dealing with a Telebit spoofed connection we have
> to send at least one ACK every 210 bytes.  At 38.4k that's about 55 milli-
> seconds!

The next best thing is going to be to keep a bunch of smaller QIOs queued.
Fortunately, uucp is built around the broken unix I/O model, which is
extremely simpleminded about timeouts.  The nature of the animal is that a
timeout is an exception condition; the sending channel streams most of the
time so small QIOs will be completed by the following packet as long as the
QIOs aren't too big.  QIOs sized at less than the expected packet size will
ensure that the packet makes it to the driver while the next packet is read.
Smaller QIOs will get the packets delivered in a more timely fashion, at
the expense of the overhead of queueing and delivering the things.


--
Don Stokes, ZL2TNM (DS555)                        [e-mail] (home)
Network Manager, Computing Services Centre            [e-mail] (work)
Victoria University of Wellington, New Zealand              [phone]