[HECnet] BQTCP without DECnet

[Thomas DeBellis]

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).

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.

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 /maybe/ do 10 characters a second (I.E., about 110 baud).

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.

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.

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.

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.

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 SLOGIN). 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...

> ------------------------------------------------------------------------
> On 5/9/20 6:57 PM, Johnny Billquist wrote:
>
>    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?
>
> 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.
>
> 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.
>
>   Johnny
>> ------------------------------------------------------------------------
>> On 5/9/20 1:50 PM, Lee Gleason wrote:
>>
>>    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.
>>> ------------------------------------------------------------------------
>>> On 5/8/20 10:32 PM, Johnny Billquist wrote:
>>>
>>> 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.
>>>
>>> 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.
>>>> ------------------------------------------------------------------------
>>>> On 5/8/20 9:51 PM, Lee Gleason wrote:
>>>>
>>>>    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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20200510/b3d5c65f/attachment.html>