[HECnet] Thousands of DECnet errors on Tops-20 --> Ddp device

Sun Jan 17 14:56:12 PST 2021

L.S.

Almost good:

In the Anf10 source listings the following:

DN200 - DECSYSTEM-10 REMOTE STATION MACDLX V31 11-AUG-120 20:31 PAGE 227-1 

DNDCMP.P11 16-FEB-88 07:57 LINK DOWN 

9934 ;*** ALTHOUGH THERE IS NOTHING REALLY IN THE DDCMP SPEC TO PROHIBIT SIMPLY 

9935 ;*** STARTING OFF WITH WILD AND WIERD NUMBERS, SOME LESS-THAN-ROBUST SYSTEMS 

9936 ;*** TEND TO GET TERRIBLY CONFUSED IF THE FIRST DDCMP NUMBERED MESSAGE ISN'T 

9937 ;*** NUMBER "1", SO . . . RESET THE MESSAGE NUMBERS 

9938 ;*** MOVB LB.LAP(J),LB.HSN(J) ;HIGHEST PROC IS HIGHEST SENT 

9939 ;*** MOVB LB.HSN(J),LB.LAR(J) 

9940 035140 005065 000056 CLR LB.ROK(J) ;RESET MSG NUMBERS 

9941 035144 005065 000060 CLR LB.LAP(J) 

9942 

9943 002 .IF NE FT.DDP 

9944 TST LB.ST2(J) ;IS THIS A DDP-CONTROLLED LINE? 

9945 BPL 40$ ;NO, DO NCL'ISH STUFF 

9946 MOV J,-(P) ;YES, SAVE LBLK ADDRESS 

9947 MOV LB.DDB(J),J ;CONTEXT SWITCH TO DDP DEVICE LEVEL 

9948 JSR PC,DDPOFL ;SAY THE DDP DEVICE IS "OFFLINE" 

9949 MOV (P)+,J ;RESTORE DDB ADDRESS 

9950 RTS PC ;NOTHING MORE TO DO 

9951 001 .ENDC ;.IF NE FT.DDP

DN200 - DECSYSTEM-10 REMOTE STATION MACDLX V31 11-AUG-120 20:31 PAGE 230 

DNDCMP.P11 16-FEB-88 07:57 DDPSER - DDP DEVICE SERVICE ROUTINES 

10058 .SBTTL DDPSER - DDP DEVICE SERVICE ROUTINES 

10059 

10060 001 .IF NE FT.DDP 

10061 002 .IF NE DDPN 

10062 

10063 ;THE DDP DEVICE ALLOWS THE VARIOUS DDCMP LINES TO BE USED AS DIRECT I/O 

10064 ;DEVICES RATHER THAN AS NCL (OR NSP) NETWORK COMM LINES. 

10065 

10066 ;DDP DEVICE PARAMETERS SETTABLE ON A "PER-LINE" BASIS 

10067 ; 

10068 ; DPnnWID ;"RECORD SIZE" OR MESSAGE SIZE 

10069 ; DPnnCHK ;CHUNKS-PER-DATAREQUEST WEIGHTING 

10070 ; DPnnRNN ;RESTRICTED HOST ASSIGNMENT 

10071 ; DPnnPFH ;PREFERRED HOST ASSIGNMENT 

10072

It is for an Anf10 ddcmp device on a Pdp11/34 DN200 Anf10 workstation which might also have been (projected to?) made use of in a 2020 system.

Anf10 runs on simh Pdp11/34 with some fiddling of the emulation speed.

Best regards,

R.V.

From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Peter Lothberg
Sent: Sunday, 17 January, 2021 23:29
To: hecnet <hecnet at Update.UU.SE>
Subject: Re: [HECnet] Thousands of DECnet errors on Tops-20

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 <mailto:tommytimesharing at gmail.com> >
To: "hecnet" <hecnet at Update.UU.SE <mailto: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/1d95ef89/attachment-0001.htm>