<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>True. Kermit can be tuned to be pretty fast. In 2001, when the
KLH10 micro-engine became generally available, Frank da Cruz (one
of the original authors) updated the Tops-20 version to support
long packets. The Tops-20 version is one of the two original
versions (the other being the 'micro' version).<br>
</p>
<p>I have a bit of a background in Kermit. I had the office across
the hall from Frank in 710 Watson and he was my boss for several
years. Here is the actual reason Kermit was created and why it
does some of the things it does. Around 1982, the first micro
showed up at Columbia. I don't remember the model, but it wasn't
anything IBM. I think maybe it was a SuperBee running CP/M. The
floppy drives on it were immediately recognized by staff as a good
solution to user storage which we were perennially short of. This
was a common problem with time-sharing sites that did not have
direct funding models.</p>
<p>So getting data down from the 20 was pretty easy; you just check
parity and, at 4800 baud, the micro could keep up because it had
nothing else to do. That wasn't the case with uploads. Shove too
much data into RSX20F of the time and it would roll over and drop
dead. There was some eventual logic put in to determine whether a
line might hyper-active or ringing, but that hadn't happened,
yet. This isn't anything against the front end; it was designed
with DH11 fifo's in mind and users who, in bursts, could <i>maybe</i>
do 10 characters a second (I.E., about 110 baud).</p>
<p>The front end's dismise would drop carrier on the remote
terminals, promptly throwing all the poor users off. And then all
of them would desperately try to get on again in order to not lose
their work. So the poor front end would finish rebooting only to
suffer the same fate again and again... You had to come in via a
network virtual terminal and run a program that could tell you
what was going on (by SNOOP%'ing BIGBUF) to figure out what was
going on.<br>
</p>
<div class="moz-cite-prefix">
<p>So we made some experiments to determine what the maximum
length of the line was that the front end could swallow before
being choking. It also turned out that there were some input
characters that weren't particularly welcome, either. That's
why Kermit quotes control characters and some other things and
had an input line length of between 64 and 70 characters.<br>
</p>
</div>
<div class="moz-cite-prefix">
<p>But it's not exactly 1989. I got a hold of Tops-20 in early
2003 and immediately set about fixing bugs, polishing things up
and generally making myself at home. Why? The performance of
the BBN FTP server was pretty awful, but I didn't immediately
see why (even thought I fixed some bugs). It eventually got to
the point that I punted it and rewrote the whole thing from
scratch. Download speeds went from 10's of kilobits to low
megabits; about a %1,500 increase. Uploads were another
problem; they just wedged. This behavior happens with FAL,
too. I remember using the NI (and CI) and the direction of the
transfer did not make any difference in speed.</p>
<p>So the problem appears to be the NI simulator, which I've been
looking at on and off. I had to make some changes to it in
order for DECnet to come up seamlessly on Ubuntu. Problem is,
I'd rather hack assembler. I'll get to it.</p>
<p>Were it not for Kermit, I wouldn't have anyway to get anything
into the 20 except by virtual tapes (which work fine).
Naturally, I found a couple of bugs and other things that
annoyed me, so I made some updates and gave them to Frank and
MRC. My last change was in March of 2005 (I'm <font size="+1"><tt>SLOGIN</tt></font>).
The maximum rate that I've been able to upload to the 20 over
either LAT or TVT is about 3,000 baud, still with a line length
of 70. Better than nothing...<br>
</p>
</div>
<blockquote type="cite"
cite="mid:1a03bb2d-8946-5634-aaaa-4df2d7d8d735@softjar.se">
<hr width="100%" size="2">On 5/9/20 6:57 PM, Johnny Billquist
wrote:
<br>
<br>
I'm working on an 11/73 running Mplus that is tight on disk
space, to the point that DECnet won't fit. I was wondering if RSX
TCP/IP (that consumes less disk space) would work on a Q bus
machine without DECnet. It's documented as possible for Unibus
machines - can it work on a QBus system?
<br>
<br>
Kermit is definitely always an option. With some fiddling around,
you can get it to work pretty nice, although obviously transfer
speeds aren't the greatest.
<br>
<br>
I have some vague recollection there was a driver on some DECUS
tape, but I don't remember any details. It would need some looking
in to.
<br>
<br>
Johnny
<br>
<blockquote type="cite">
<hr width="100%" size="2">On 5/9/20 1:50 PM, Lee Gleason wrote:<br>
<br>
OK, thanks for the info. I doubt I'll find a driver to use,
and don't have time to write one. For this project, looks like
it's time for me to Kermit like it's 1989.
<blockquote type="cite">
<hr width="100%" size="2">On 5/8/20 10:32 PM, Johnny Billquist
wrote: <br>
<br>
In theory it could. The problem is that you need some device
driver for the Qbus ethernet card, and unfortunately DEC
didn't provide any. There is for the Unibus ethernet, which is
why that works.
<br>
<br>
If DECnet is installed on the machine, TCP/IP will be using
the drivers provided through DECnet, so that they can
co-exist. And that is usually how it is used, so I have never
bothered looking into writing a device driver of my own for
the Qbus ethernet cards.
<br>
<blockquote type="cite">
<hr width="100%" size="2">On 5/8/20 9:51 PM, Lee Gleason
wrote: <br>
<br>
I'm working on an 11/73 running Mplus that is tight on
disk space, to the point that DECnet won't fit. I was
wondering if RSX TCP/IP (that consumes less disk space)
would work on a Q bus machine without DECnet. It's
documented as possible for Unibus machines - can it work on
a QBus system
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>