<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Was this maybe that magical version 5 of Tops-20 that MRC put
together for the 2020? I sure would love to see the sources for
that! I'm not sure if this is relevant, but the following macro
in D36COM is of interest:<br>
</p>
<blockquote><font size="+1"><tt>DEFINE KNMMCS,<</tt><tt><br>
</tt><tt>; Symbol,Name,Cost, Maximum receive block
size</tt><tt><br>
</tt><tt> KNMMAC LD.TST,TST, 1, 0
;TST DEVICE</tt><tt><br>
</tt><tt> KNMMAC LD.DTE,DTE, 3,
<^D576> ;DTE DEVICE</tt><tt><br>
</tt><tt> KNMMAC LD.KDP,KDP, 4,
<^D576> ;KDP DEVICE</tt><tt><br>
</tt><tt> KNMMAC LD.DDP,DDP, 5,
<^D576> ;DDP DEVICE</tt><tt><br>
</tt><tt> KNMMAC LD.CIP,CI, 2,
<^D576> ;CI DEVICE</tt><tt><br>
</tt><tt> KNMMAC LD.NI ,NI, 1,
<^D1504-%RTEHS> ;NI DEVICE</tt><tt><br>
</tt><tt> KNMMAC LD.DMR,DMR, 2,
<^D576> ;DMR DEVICE</tt><tt><br>
</tt><tt>>;END OF KNMMCS</tt></font><br>
</blockquote>
<p>What can be seen is that the maximum block size is 576 in <u>all</u>
cases except the NI, which is 1476 bytes. I don't know if any of
these devices are relevant to the 2020; one assumes that the DTE,
CI and NI are not.<br>
</p>
<blockquote type="cite"
cite="mid:255303651.7257.1610483393333.JavaMail.zimbra@stupi.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div style="font-family: arial, helvetica, sans-serif; font-size:
12pt; color: #000000">
<div>
<hr width="100%" size="2">On 1/12/21 3:29 PM, Peter Lothberg
wrote:<br>
<div><br>
</div>
The DECnet segment size has to be the same "network wide".<br>
</div>
<div><br data-mce-bogus="1">
</div>
<div>If I remember right DECnet looks at the two end nodes and
uses the smalles segment size, <br data-mce-bogus="1">
</div>
<div>so if there is any transit node in the path with a small
segment size things will not work as <br data-mce-bogus="1">
</div>
<div>it will drop packets bigger than it''s size.<br
data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>The only SW/HW combination I knew of that has other than
576 is MRC/Stu DECnet for <br data-mce-bogus="1">
</div>
<div>Tops20 4.x on DEC2020.<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>-P<br data-mce-bogus="1">
</div>
<div><br>
</div>
<hr id="zwchr" data-marker="__DIVIDER__">
<div data-marker="__HEADERS__">
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
</b>"tommytimesharing" <a class="moz-txt-link-rfc2396E" href="mailto:tommytimesharing@gmail.com"><tommytimesharing@gmail.com></a><br>
<b>To: </b>"hecnet" <a class="moz-txt-link-rfc2396E" href="mailto:hecnet@Update.UU.SE"><hecnet@Update.UU.SE></a><br>
<b>Sent: </b>Monday, January 11, 2021 11:58:56 PM<br>
<b>Subject: </b>Re: [HECnet] Thousands of DECnet errors on
Tops-20<br>
</blockquote>
</div>
<div data-marker="__QUOTED_TEXT__">
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<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>
<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>
<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>------------------------------------------------------------------------
<br>
On 1/11/21 4:41 PM, Paul Koning wrote: <br>
<br>
<blockquote>On Jan 11, 2021, at 4:22 PM, Thomas
DeBellis<a href="mailto:tommytimesharing@gmail.com"
target="_blank" rel="nofollow noopener noreferrer"
moz-do-not-send="true"><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>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>
<br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>