<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Yes, I had seen this and had wondered about it after I had
reflected on the output of a <font size="+1"><tt>SHOW EXECUTOR
CHARACTERISTICS</tt></font> command(clipped)</p>
<blockquote>
<p>Executor Node = 2.520 (TOMMYT)<br>
<br>
Identification = Tommy Timesharing<br>
Management Version = 4.0.0<br>
CPU = DECSYSTEM1020<br>
Software Identification = Tops-20 7.1 PANDA</p>
</blockquote>
<blockquote>
<blockquote>
<blockquote>.<br>
.<br>
.</blockquote>
</blockquote>
</blockquote>
<blockquote>
<p> <font color="#ff40ff">Buffer Size = <b>576</b><br>
Segment Buffer Size = <b>576</b></font><br>
</p>
</blockquote>
<p>So it would appear that the 20's implementation of NICE knows of
this differentiation. I can parse for both <font size="+1"><tt>SET
EXECUTOR SEGMENT BUFFER SIZE</tt></font> and <font size="+1"><tt>SET
EXECUTOR BUFFER SIZE</tt></font>. Both fail, of course;
again, once DECnet is initialized, they are locked.</p>
<p>However, when one looks at the DECnet initialization block (<font
size="+1"><tt>IBBLK</tt></font>), it only contains a field for
buffer size (<font size="+1"><tt>IBBSZ</tt></font>), nothing about
segment size. Further, the <font size="+1"><tt>NODE% JSYS</tt></font>'
set DECnet initialization parameters function (<font size="+1"><tt>.NDPRM</tt></font>)
only contains a sub-function for buffer size (<font size="+1"><tt>.NDBSZ</tt></font>)
and <font size="+1"><tt>SETSPD</tt></font> will only parse for <font
size="+1"><tt>DECNET BUFFER-SIZE</tt></font>. I'm hopeful to
test that this weekend after I've looked further through the error
log.<br>
</p>
<div class="moz-cite-prefix">
<p>The receive code in the low level NI driver (<font size="+1"><tt>PHYKNI</tt></font>)
only checks to see whether was was received will fit into the
buffer specified. It returns a length error (<font size="+1"><tt>UNLER%</tt></font>)
to <font size="+1"><tt>DNADLL</tt></font>, but not the actual
difference. </p>
</div>
<div class="moz-cite-prefix">
<p>I have yet to puzzle out how the segment size is derived, but
it is apparently set on a line basis.</p>
</div>
<blockquote type="cite"
cite="mid:654f5462-e4d7-898d-bbe2-4789073401cc@softjar.se">
<hr width="100%" size="2">On 1/11/21 8:24 PM, Johnny Billquist
wrote:<br>
<br>
Thomas, I wonder if you might experience the effects of that
ethernet packet size might be different than the DECnet segment
buffer size.
<br>
This is a little hard to explain, as I don't have all the proper
DECnet naming correct.
<br>
<br>
But, based on RSX, there is two sizes relevant. One is the actual
buffer size the line is using. The other is the DECnet segment
buffer size.
<br>
<br>
The DECnet segment buffer size is the maximum size of packets you
can ever expect DECnet itself to ever use.
<br>
However, at least with RSX, when it comes to the exchange of
information at the line level, which includes things like hello
messages, RSX is actually using a system buffer size setting,
which might be very different from the DECnet segment buffer size.
<br>
<br>
I found out that VMS have a problem here in that if the hello
packets coming in are much larger than the DECnet segment buffer
size, you never even get adjacency up, while RSX can deal with
this just fine.
<br>
<br>
It sounds like you might be seeing something similar in Tops-20.
In which case you would need to tell the other end to reduce the
size of these hello and routing information packets for Tops-20 to
be happy, or else find a way to accept larger packets.
<br>
<br>
After all, ethernet packets can be up to 1500 bytes of payload.
<br>
<br>
And to explain it a bit more from an RSX point of view. RSX will
use the system buffer size when creating these hello messages. So,
if that is set to 1500, you will get hello packets up to 1500
bytes in size, which contain routing vectors and so on.
<br>
<br>
But actual DECnet communication will be limited to what the DECnet
segment buffer size say, so once you have adjacency up, when a
connection is established between two programs, those packets will
never be larger than the DECnet segment buffer size, which is
commonly 576 bytes.
<br>
<br>
Johnny
<br>
<blockquote type="cite">
<hr width="100%" size="2">On 2021-01-11 23:43, Thomas DeBellis
wrote:
<br>
<br>
Paul,
<br>
<br>
Lots of good information. For right now, I did an experiment
and went into MDDT and stubbed out the XWD UNLER%,^D5 entry in
the NIEVTB: table in the running monitor on VENTI2. Since then
(about an hour or so ago), TOMMYT 's ERROR.SYS file has been
increasing as usual (a couple of pages an hour) while VENTI2's
hasn't changed at all. So that particular fire hose is plugged
for the time being.
<br>
<br>
I don't believe I have seen this particular error before,
however, there are probably some great reasons for that. In the
1980's, CCnet may not have had Level-2 routers on it while
Columbia's 20's were online. We did have a problem with the
20's complaining about long Ethernet frames from an early
version BSD 4.2 that was being run on some VAX 11/750's in the
Computer Science department's research lab. They got taught how
to not do that and all was well.
<br>
<br>
Tops-20's multinet implementation was first done at BBN and then
later imported. I am not sure that it will allow me to change
the frame size. 576 was what was used for the Internet, so I
don't know where that might be hardwired. I'll check.
<br>
<br>
I think there are two forensics to perform here:
<br>
<br>
1. Investigate when the errors started happening; whether they
predate
<br>
Bob adopting PyDECnet
<br>
2. Investigate what the size difference is; I don't believe
that is
<br>
going into the error log, but I'll have to look more
carefully with
<br>
SPEAR.
<br>
<br>
A *warning* for anyone also looking to track this down: if you
do the retrieve in SPEAR on KLH10 and you don't have have my
time out changes for DTESRV, you will probably crash your 20.
This will happen both with a standard DEC monitor and PANDA.
<br>
<br>
<blockquote type="cite">------------------------------------------------------------------------
<br>
On 1/11/21 4:41 PM, Paul Koning wrote:
<br>
<br>
<blockquote type="cite">On Jan 11, 2021, at 4:22 PM, Thomas
DeBellis<a class="moz-txt-link-rfc2396E" href="mailto:tommytimesharing@gmail.com"><tommytimesharing@gmail.com></a> wrote:
<br>
<br>
OK, I guess that's probably a level 2 router broadcast
coming over the bridge. There is no way Tops-10 or Tops-20
could currently be generating that because there is no code
to do so; they're level 1, only
<br>
</blockquote>
Yes, unfortunately originally both multicasts used the same
address. That was changed in Phase IV Plus, but that still
sends to the old address for backwards compatibility and it
isn't universally implemented.
<br>
<br>
<blockquote type="cite">I started looking at the error; it
starts out in DNADLL when it is detected on a frame that has
come back from NISRV (the Ethernet Interface driver). The
error is then handed off to NTMAN where the actual logging
is done. So, there are two quick hacks to stop all the
errors:
<br>
<br>
• I could stub out the length error entry (XWD
UNLER%,^D5) in the NIEVTB: table in DNADLL.MAC.
<br>
• I could put in a filter ($NOFIL) for event class 5 in
the NMXFIL: table in NTMAN.MAC.
<br>
<br>
That will stop the deluge for the moment. Meanwhile, I have
to understand what's actually being detected; even the full
SPEAR entry is short on details (like how long the frame
was).
<br>
</blockquote>
The thing to look for is the buffer size (frame size) setting
of the stations on the Ethernet. It should match; if not
someone may send a frame small enough by its settings but too
large for someone else who has a smaller value. Routing
messages tend to cause that problem because they are variable
length; the Phase IV rules have the routers send them (the
periodic ones) as large as the line buffer size permits.
<br>
<br>
Note that DECnet by convention doesn't use the full max
Ethernet frame size in DECnet, because DECnet has no
fragmentation so the normal settings are chosen to make for
consistent NSP packet sizes throughout the network. The
router sending the problematic messages is 2.1023 (not
63.whatever, Rob, remember that addresses are little endian)
which has its Ethernet buffer size set to 591. That matches
the VMS conventional default of 576 when accounting for the
"long header" used on Ethernet vs. the "short header" on point
to point (DDCMP etc.) links). But VENTI2 has its block size
set to 576. If you change it to 591 it should start working.
<br>
<br>
Perhaps I should change PyDECnet to have a way to send shorter
than max routing messages.
<br>
<br>
paul
<br>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>