<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>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 <u>all</u> 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.</p>
<p>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.</p>
<p>Except...</p>
<p>In <font size="+1"><tt>ROUTER.MAC</tt></font> under the Tops-10
conditional at <font size="+1"><tt>C</tt><tt>ALKON+2</tt></font>,
one finds the following</p>
<blockquote>
<p><font size="+1"><tt>LOAD T4,LIDEV,+RC.LID(RC) ;GET THE DEVICE
TYPE</tt><tt><br>
</tt><tt>CAIN T4,LD.DDP ;IS IT NOT CPU-DEPENDANT?</tt><tt><br>
</tt><tt>JRST CALKO5 ; NOT CPU DEPENDANT, GO
AHEAD AND DO IT.</tt><tt><br>
</tt><tt>LOAD T4,LIKON,+RC.LID(RC) ;GET THE CPU NUMBER OF THE
CIRCUIT</tt><tt><br>
</tt><tt>CAMN T4,.CPCPN ;ARE WE ON THAT CPU NOW?</tt><tt><br>
</tt><tt>JRST CALKO5 ; YES</tt></font><br>
</p>
</blockquote>
<p>If you are a DDP (<font size="+1"><tt>LD.DDP</tt></font>), then
you are not CPU dependent and you go ahead always, otherwise, you
have to be on the CPU that owns the device (<font size="+1"><tt>.CPCPN</tt></font>)
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.<br>
</p>
<p>I'll find out about tcpdump later tonight.<br>
</p>
<blockquote type="cite"
cite="mid:19beecee-ee10-5f56-01ff-6312c11a841b@softjar.se">
<hr width="100%" size="2">On 1/17/21 5:34 PM, Johnny Billquist
wrote:
<blockquote type="cite">
<hr width="100%" size="2">On 2021-01-17 23:10, Thomas DeBellis
wrote:
<br>
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
<br>
As for DDP, it's totally unrelated to this, so how about playing
with that another day?
<br>
<br>
Also not sure why you think it would be shared from a hardware
perspective.
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
Would be a bit interesting, yes.
<br>
</blockquote>
</body>
</html>