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