18 Jan
2021
18 Jan
'21
12:17 a.m.
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.