<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Yes, it is peculiar, isn't it? It for a header. I chased it
down when I saw it:<br>
</p>
<p><font size="+1"><tt> MP %RTEHS,<2+7-6+21+4>
;Ethernet header size, composed of:</tt><tt><br>
</tt><tt> ;+2 Ethernet padding
bytes</tt><tt><br>
</tt><tt> ;+7 Router Phase-IV pad
bytes</tt><tt><br>
</tt><tt> ;-6 corrects for
assumed Phase III header</tt><tt><br>
</tt><tt> ;+21 allows for full
P-IV NI header</tt><tt><br>
</tt><tt> ;+4 allows for 4 KLNIA
CRC bytes (input)</tt><tt><br>
</tt><tt> ; & for byte
misalignment after BLT (output)</tt></font><br>
</p>
<p>The 1504 is to handle a rounding condition when converting from
bytes to words.</p>
<p>It comes out to 1476 bytes maximum data buffer size, which is
what I am re-configuring for when I reboot later this weekend.<br>
</p>
<blockquote type="cite"
cite="mid:d83217f5-8df4-77e6-f472-eb2445e47727@softjar.se">
<hr width="100%" size="2">On 1/15/21 11:49 PM, Johnny Billquist
wrote:<br>
<br>
Hum. 1504-%RTEHS seems like a weird expression. And then it would
mean RTEHS is 28? Any idea what RTEHS represents?
<br>
<br>
Anyway, the actual maximum payload on ethernet is 1500 bytes. Then
you have src and dst mac (6 bytes each), protocol (2 bytes) and
crc (4 bytes). So if we're talking full size plus overhead, it
should say 1518. I could guess that the 1504 would be payload plus
crc, but then why is 28 additional bytes taken away? That's twice
what the overhead for the rest is... And that it's exactly twice
is also intriguing...
<br>
<br>
And yeah, I would definitely assume that DTE, CI and NI are not
relevant for a 2020. But I do know of one person who at least
partially got a DELUA to work on a 2020, so maybe it could have
been possible to get ethernet on it.
<br>
<br>
Johnny
<br>
<blockquote type="cite">
<hr width="100%" size="2">On 2021-01-15 21:59, Thomas DeBellis
wrote:
<br>
<br>
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>
<br>
<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>
<br>
What can be seen is that the maximum block size is 576 in _all_
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>
<blockquote type="cite">
<hr width="100%" size="2">On 1/12/21 3:29 PM, Peter Lothberg
wrote:
<br>
<br>
The DECnet segment size has to be the same "network wide".
<br>
<br>
If I remember right DECnet looks at the two end nodes and uses
the smalles segment size,
<br>
so if there is any transit node in the path with a small
segment size things will not work as
<br>
it will drop packets bigger than it''s size.
<br>
<br>
The only SW/HW combination I knew of that has other than 576
is MRC/Stu DECnet for
<br>
Tops20 4.x on DEC2020.
<br>
<br>
-P
<br>
<br>
------------------------------------------------------------------------
<br>
<br>
*From: *"tommytimesharing"
<a class="moz-txt-link-rfc2396E" href="mailto:tommytimesharing@gmail.com"><tommytimesharing@gmail.com></a>
<br>
*To: *"hecnet" <a class="moz-txt-link-rfc2396E" href="mailto:hecnet@Update.UU.SE"><hecnet@Update.UU.SE></a>
<br>
*Sent: *Monday, January 11, 2021 11:58:56 PM
<br>
*Subject: *Re: [HECnet] Thousands of DECnet errors on
Tops-20
<br>
<br>
Yes, I had seen this and had wondered about it after I had
<br>
reflected on the output of a SHOW EXECUTOR CHARACTERISTICS
<br>
command(clipped)
<br>
<br>
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
<br>
<br>
.
<br>
.
<br>
.
<br>
<br>
Buffer Size = *576*
<br>
Segment Buffer Size = *576*
<br>
<br>
So it would appear that the 20's implementation of NICE
knows of
<br>
this differentiation. I can parse for both SET EXECUTOR
SEGMENT
<br>
BUFFER SIZE and SET EXECUTOR BUFFER SIZE. Both fail, of
course;
<br>
again, once DECnet is initialized, they are locked.
<br>
<br>
However, when one looks at the DECnet initialization block
<br>
(IBBLK), it only contains a field for buffer size (IBBSZ),
nothing
<br>
about segment size. Further, the NODE% JSYS' set DECnet
<br>
initialization parameters function (.NDPRM) only contains
a
<br>
sub-function for buffer size (.NDBSZ) and SETSPD will only
parse
<br>
for DECNET BUFFER-SIZE. I'm hopeful to test that this
weekend
<br>
after I've looked further through the error log.
<br>
<br>
The receive code in the low level NI driver (PHYKNI) only
checks
<br>
to see whether was was received will fit into the buffer
<br>
specified. It returns a length error (UNLER%) to DNADLL,
but not
<br>
the actual difference.
<br>
<br>
I have yet to puzzle out how the segment size is derived,
but it
<br>
is apparently set on a line basis.
<br>
<br>
------------------------------------------------------------------------
<br>
On 1/11/21 8:24 PM, Johnny Billquist wrote:
<br>
<br>
Thomas, I wonder if you might experience the effects
of that
<br>
ethernet packet size might be different than the
DECnet
<br>
segment buffer size.
<br>
This is a little hard to explain, as I don't have all
the
<br>
proper DECnet naming correct.
<br>
<br>
But, based on RSX, there is two sizes relevant. One is
the
<br>
actual buffer size the line is using. The other is the
DECnet
<br>
segment buffer size.
<br>
<br>
The DECnet segment buffer size is the maximum size of
packets
<br>
you can ever expect DECnet itself to ever use.
<br>
However, at least with RSX, when it comes to the
exchange of
<br>
information at the line level, which includes things
like
<br>
hello messages, RSX is actually using a system buffer
size
<br>
setting, which might be very different from the DECnet
segment
<br>
buffer size.
<br>
<br>
I found out that VMS have a problem here in that if
the hello
<br>
packets coming in are much larger than the DECnet
segment
<br>
buffer size, you never even get adjacency up, while
RSX can
<br>
deal with this just fine.
<br>
<br>
It sounds like you might be seeing something similar
in
<br>
Tops-20. In which case you would need to tell the
other end to
<br>
reduce the size of these hello and routing information
packets
<br>
for Tops-20 to be happy, or else find a way to accept
larger
<br>
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
<br>
will use the system buffer size when creating these
hello
<br>
messages. So, if that is set to 1500, you will get
hello
<br>
packets up to 1500 bytes in size, which contain
routing
<br>
vectors and so on.
<br>
<br>
But actual DECnet communication will be limited to
what the
<br>
DECnet segment buffer size say, so once you have
adjacency up,
<br>
when a connection is established between two programs,
those
<br>
packets will never be larger than the DECnet segment
buffer
<br>
size, which is commonly 576 bytes.
<br>
<br>
Johnny
<br>
<br>
------------------------------------------------------------------------
<br>
On 2021-01-11 23:43, Thomas DeBellis wrote:
<br>
<br>
Paul,
<br>
<br>
Lots of good information. For right now, I did an
<br>
experiment and went into MDDT and stubbed out the
XWD
<br>
UNLER%,^D5 entry in the NIEVTB: table in the
running
<br>
monitor on VENTI2. Since then (about an hour or
so ago),
<br>
TOMMYT 's ERROR.SYS file has been increasing as
usual (a
<br>
couple of pages an hour) while VENTI2's hasn't
changed at
<br>
all. So that particular fire hose is plugged for
the time
<br>
being.
<br>
<br>
I don't believe I have seen this particular error
before,
<br>
however, there are probably some great reasons for
that. In the 1980's, CCnet may not have had
Level-2 routers on
<br>
it while Columbia's 20's were online. We did have
a
<br>
problem with the 20's complaining about long
Ethernet
<br>
frames from an early version BSD 4.2 that was
being run on
<br>
some VAX 11/750's in the Computer Science
department's
<br>
research lab. They got taught how to not do that
and all
<br>
was well.
<br>
<br>
Tops-20's multinet implementation was first done
at BBN
<br>
and then later imported. I am not sure that it
will allow
<br>
me to change the frame size. 576 was what was
used for
<br>
the Internet, so I don't know where that might be
<br>
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
<br>
they predate
<br>
Bob adopting PyDECnet
<br>
2. Investigate what the size difference is; I
don't
<br>
believe that is
<br>
going into the error log, but I'll have to
look more
<br>
carefully with
<br>
SPEAR.
<br>
<br>
A *warning* for anyone also looking to track this
down: if
<br>
you do the retrieve in SPEAR on KLH10 and you
don't have
<br>
have my time out changes for DTESRV, you will
probably
<br>
crash your 20. This will happen both with a
standard DEC
<br>
monitor and PANDA.
<br>
<br>
------------------------------------------------------------------------
<br>
<br>
On 1/11/21 4:41 PM, Paul Koning wrote:
<br>
<br>
On Jan 11, 2021, at 4:22 PM, Thomas
<br>
DeBellis<a class="moz-txt-link-rfc2396E" href="mailto:tommytimesharing@gmail.com"><tommytimesharing@gmail.com></a>
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:tommytimesharing@gmail.com"><mailto:tommytimesharing@gmail.com></a>
wrote:
<br>
<br>
OK, I guess that's probably a level 2
router
<br>
broadcast coming over the bridge. There
is no way
<br>
Tops-10 or Tops-20 could currently be
generating
<br>
that because there is no code to do so;
they're
<br>
level 1, only
<br>
<br>
Yes, unfortunately originally both multicasts
used the
<br>
same address. That was changed in Phase IV
Plus, but
<br>
that still sends to the old address for
backwards
<br>
compatibility and it isn't universally
implemented.
<br>
<br>
I started looking at the error; it starts
out in
<br>
DNADLL when it is detected on a frame that
has
<br>
come back from NISRV (the Ethernet
Interface
<br>
driver). The error is then handed off to
NTMAN
<br>
where the actual logging is done. So,
there are
<br>
two quick hacks to stop all the errors:
<br>
<br>
• I could stub out the length error
entry (XWD
<br>
UNLER%,^D5) in the NIEVTB: table in
DNADLL.MAC.
<br>
• I could put in a filter ($NOFIL) for
event
<br>
class 5 in the NMXFIL: table in NTMAN.MAC.
<br>
<br>
That will stop the deluge for the moment.
<br>
Meanwhile, I have to understand what's
actually
<br>
being detected; even the full SPEAR entry
is short
<br>
on details (like how long the frame was).
<br>
<br>
The thing to look for is the buffer size
(frame size)
<br>
setting of the stations on the Ethernet. It
should
<br>
match; if not someone may send a frame small
enough by
<br>
its settings but too large for someone else
who has a
<br>
smaller value. Routing messages tend to cause
that
<br>
problem because they are variable length; the
Phase IV
<br>
rules have the routers send them (the periodic
ones)
<br>
as large as the line buffer size permits.
<br>
<br>
Note that DECnet by convention doesn't use the
full
<br>
max Ethernet frame size in DECnet, because
DECnet has
<br>
no fragmentation so the normal settings are
chosen to
<br>
make for consistent NSP packet sizes
throughout the
<br>
network. The router sending the problematic
messages
<br>
is 2.1023 (not 63.whatever, Rob, remember that
<br>
addresses are little endian) which has its
Ethernet
<br>
buffer size set to 591. That matches the VMS
<br>
conventional default of 576 when accounting
for the
<br>
"long header" used on Ethernet vs. the "short
header"
<br>
on point to point (DDCMP etc.) links). But
VENTI2 has
<br>
its block size set to 576. If you change it
to 591 it
<br>
should start working.
<br>
<br>
Perhaps I should change PyDECnet to have a way
to send
<br>
shorter than max routing messages.
<br>
<br>
paul
<br>
<br>
<br>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>