[HECnet] Thousands of DECnet errors on Tops-20

[Peter Lothberg]

A DDP device is a "DDCMP speaker on a ANF10 front end". 

It's basically a 576 byte card punch/reader on the front end with corresponding 
device on the T10 side. We used it on the KI to talk both DECnet-IV and IP (to 
a BSD 4.3 vaxen with a DMR-11.) It was done as a hack by Robert Hauk, who 
also put in ANF10 over Ethernet. (remmember the DECnet frontend for the DTE 
was only phase 3). 

Dept of useless knowledge.. 

-P 

> From: "tommytimesharing" <tommytimesharing at gmail.com>
> To: "hecnet" <hecnet at Update.UU.SE>
> Sent: Sunday, January 17, 2021 5:10:08 PM
> Subject: Re: [HECnet] Thousands of DECnet errors on Tops-20

> The only serial lines that I saw DECnet running on were synchronous connections.
> The local connections between CU's 20's (before we got the CI's and NI's) were
> 56K baud synchronous lines running on KMC11's, which we thought were pretty hot
> stuff ...until... Non-data center connections (our chemistry VAX, CMU & CWR
> 20's) were asynchronous lines running 9.6K baud (on DUP11's, I think).

> The PANDA monitor's Multinet code implements serial IP (SLIP), which it will run
> over an ordinary DL or DH based asynchronous lines. I didn't immediately see
> anything similar for DECnet, but it is doubtful that MRC would have put that it
> in; the code was supposed to run on a 2020, which has different IO drivers. If
> his 2020 5.0 changes ever do surface, it may be conceivable that some of them
> might be retrofitted into 7.1 (depends on what's applicable).

> It is now possible that I will eventually figure out what this mysterious DDP
> device is. I reconfigured both 20's to have the largest buffer possible (
> DECNET BUFFER-SIZE 1476 in SYSTEM:7-1-CONFIG.CMD , which I checked in the
> running monitor), rebooted and ... I'm still getting the same frame too long
> error, viz:
>> ***********************************************
>> DECNET ENTRY
>> LOGGED ON 16-Jan-2021 01:29:38-EST MONITOR UPTIME WAS 0 day(s) 0:16:8
>> DETECTED ON SYSTEM # 3691.
>> RECORD SEQUENCE NUMBER: 35752.
>> ***********************************************
>> DECNET Event type 5.15, Receive failed
>> From node 2.522 (VENTI2), occurred 16-JAN-2021 01:29:11

>> Line NI-0-0

>> Failure reason = Frame too long
>> Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 08 0A

>> ***********************************************
>> DECNET ENTRY
>> LOGGED ON 16-Jan-2021 01:29:38-EST MONITOR UPTIME WAS 0 day(s) 0:16:8
>> DETECTED ON SYSTEM # 3691.
>> RECORD SEQUENCE NUMBER: 35753.
>> ***********************************************
>> DECNET Event type 5.15, Receive failed
>> From node 2.522 (VENTI2), occurred 16-JAN-2021 01:29:28

>> Line NI-0-0

>> Failure reason = Frame too long
>> Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 FF 0B

>> ************************************************************************
> Darn it‼️ So now I've got some modifications to actually make to the monitor to
> give some better error information (like the number of bytes overrun, if I can
> extract it). So maybe I'll stumble over whatever DDP does. It's odd; I can't
> think of any device that a pack of KL's could share except something like a
> dual ported disk or magnetic tape drive and that's only two KL's.

> Meanwhile, I'll also do a tcpdump so I can try to correlate what Tops-20 is
> silently whining about with what's coming over the bridge.

> Finally, something to beware of if you are running the KLH10 micro-engine and
> have a very large file that you're backing up (you're all running regular
> backups, right ?) The amount of disk activity will somehow prevent KLH10's
> front end timer from popping so, unless you are running my changes to DTESRV,
> you're going to hang with a DTEKPA BUGINF . A quick hack is to deposit a -1
> into FEDBSW , which will keep the 20 from trying to reboot the front end (which
> KLH10 absolutely does not know how to handle).
> So the quarterly full backups worked fine on the development machine (VENTI2)
> which has the patch, but not on the production machine (TOMMYT) which does not.
> Pity, I had been up over 32 weeks and was only a little short of 3,000 hours
> uptime.

>> On 1/15/21 11:58 PM, Johnny Billquist wrote:

>> I saw that and wondered as well.
>> I was thinking maybe it could be for DDCMP devices without more specifically
>> defining what it would be, since DDCMP could be run over any serial line?

>> Johnny

>>> On 2021-01-15 22:53, Peter Lothberg wrote:

>>> The 2020 has a KMC11 and up to 2 DUP11, and those are the interfaces
>>> the "MRC T20 DECnet thing supports.

>>> On the list of devices/sizes you posted is a "DDP" device and I wounder if you
>>> knew what that is?

>>> --P

>>>> From : "tommytimesharing" [ mailto:tommytimesharing at gmail.com |
>>>> <tommytimesharing at gmail.com> ]
>>>> To : "hecnet" [ mailto:hecnet at Update.UU.SE | <hecnet at Update.UU.SE> ]
>>>> Sent : *Friday, January 15, 2021 4:24:07 PM
>>>> Subject : *Re: [HECnet] Thousands of DECnet errors on Tops-20

>>>> DDP? I thought it was DUP-11.

>>>>> On 1/15/21 4:21 PM, Peter Lothberg wrote:

>>>>> Well, MRC was receiving "suggestions" from Stu Grossman on how to do it, but if
>>>>> my memory does not fail me the block size was 312, due to lack of buffer space
>>>>> in the already crammed single section 512KW 2020. I'm afraid my tape and
>>>>> disk-pack are in Seattle. I knew it was not 576 as it had two DUP-11's and
>>>>> using it for transit failed...

>>>>> Quiz, do you knew what a DDP is?

>>>>> -P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20210117/c51af6d7/attachment-0001.htm>