[HECnet] Thousands of DECnet errors on Tops-20

[Johnny Billquist]

On 2021-01-18 00:17, Thomas DeBellis wrote:
> Well, the frames certainly won't be larger than 1,500 bytes, right?  So 
> I'm guessing they'll be the maximum.  Problem is, all of that stuff is 
> hidden under several layers of drivers, so I'm not sure how I'm going to 
> get the overage passed back.  And I also need to put in some BUGINF 
> logic to alert if I get more of these than whatever I decide the 
> interval to be.

That depends on what they count. Like I said - ethernet payload is 1500. 
Then you have the ethernet headers which is 14 bytes, plus the crc 
trailer, which is 4 bytes. If you count them, you end up at 1518 bytes.
Depends on the hardware I guess.
I have no idea what the NIA-20 expose.

> About DDP 'sharing'; it is not quite like that.  Late in the product 
> cycle, DEC updated Tops-10 to handle symmetric multi-processing where 
> all processors could do I/O.  Previous versions of Tops-10 had a single 
> master processor, which handled processing and _all_ of the I/O and 
> slave processors (I think up to five) which would just handle 
> computation.  If you had to do I/O you had to wait to run on the master.
> 
> Aside from excessively loading the master processor, you could only buy 
> as many peripherals as a single-KL could handle.  With SMP, you can plug 
> the peripheral in pretty much anywhere and it will work no matter what 
> processor is doing I/O.  The decision is straightforward; if you're 
> doing I/O and the processor you are running has the device (dual ported 
> or not), then you proceed.  If the processor can not access the device 
> on the I/O, bus then the request is queued for the processor that does.

Right. Pretty much how it works on any system. Even ASMP is like that, 
except you cannot (are not allowed) to hook any peripherals to the slave 
processors.

> Except...
> 
> In ROUTER.MAC under the Tops-10 conditional at CALKON+2, one finds the 
> following
> 
>     LOAD T4,LIDEV,+RC.LID(RC) ;GET THE DEVICE TYPE
>     CAIN T4,LD.DDP            ;IS IT NOT CPU-DEPENDANT?
>     JRST CALKO5               ; NOT CPU DEPENDANT, GO AHEAD AND DO IT.
>     LOAD T4,LIKON,+RC.LID(RC) ;GET THE CPU NUMBER OF THE CIRCUIT
>     CAMN T4,.CPCPN            ;ARE WE ON THAT CPU NOW?
>     JRST CALKO5               ; YES
> 
> If you are a DDP (LD.DDP), then you are not CPU dependent and you go 
> ahead always, otherwise, you have to be on the CPU that owns the device 
> (.CPCPN) So I'm not sure if it makes any difference, but DDP is not CPU 
> dependent; not sure if that is a synonym for 'shared'.  If I stumble 
> over something more, I'll report it.

Oh. I think that is sortof clear. DDCMP is not hardware in the first 
place, so the processing can happen on any CPU. It's only when the bytes 
actually need to go in or out that you then need to route it to a 
processor that actually have the serial port.

It's actually the same in RSX. The DDCMP layer is sortof between the 
hardware driver and the higher level protocols, and it's not tied to any 
specific CPU.

But that code would suggest that LD.DDP is just an indication of whether 
something is CPU dependent or not, and would have anything to do with DDCMP.

> I'll find out about tcpdump later tonight.

Great.

   Johnny

> 
>> ------------------------------------------------------------------------
>> On 1/17/21 5:34 PM, Johnny Billquist wrote:
>>> ------------------------------------------------------------------------
>>> On 2021-01-17 23:10, Thomas DeBellis wrote:
>>>
>>> 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.
>>
>> Definitely interested in what size we are talking about here, but I am 
>> sort of suspecting you are getting 1500 byte frames, and it sounded 
>> like the code you looked at suggested the maximum frame size to be 
>> slightly short of this.
>>
>> As for DDP, it's totally unrelated to this, so how about playing with 
>> that another day?
>>
>> Also not sure why you think it would be shared from a hardware 
>> perspective.
>>> 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.
>>
>> Would be a bit interesting, yes.

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol