[HECnet] Thousands of DECnet errors on Tops-20

[Thomas DeBellis]

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.

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.

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.

I'll find out about tcpdump later tonight.

> ------------------------------------------------------------------------
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20210117/5e1bbe29/attachment.htm>