12 Jan
2021
12 Jan
'21
2:39 a.m.
I know some DECnet implementations make that distinction, but not all do. RSTS just has a
datalink buffer size and derives the other numbers from that. PyDECnet does too, but
there the size is (currently) hardcoded at 576 for point to point and 591 for Ethernet.
The 576 was taken from the VMS standard size as I remember it (on the DEC engineering
network).
As I said, I could add a circuit parameter to use a different size. Depending on the
configuration that can create packet loss due to oversized packets being discarded in
transit.
On the earlier question how this can be happening suddenly: it isn't area routing
messages that are too large, that's not possible because they can only contain 63
entries (one per area), each entry being 2 bytes. But the L2 messages will be large in
the case of the periodic messages, since those report every address in the area so
typically there will be 1024 entries. That's too much, of course, so the L1 routing
message is sent in several parts, but each part is normally made as big as the datalink
buffer size permits. So given the PyDECnet setting of 591 for Ethernet, an L1 routing
message can be up to that size. If the recipient has 576 as its buffer size that's
not going to work.
paul
On Jan 11, 2021, at 8:24 PM, Johnny Billquist <bqt
at softjar.se> wrote:
Thomas, I wonder if you might experience the effects of that ethernet packet size might
be different than the DECnet segment buffer size.
This is a little hard to explain, as I don't have all the proper DECnet naming
correct.
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.
The DECnet segment buffer size is the maximum size of packets you can ever expect DECnet
itself to ever use.
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.
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.
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.
After all, ethernet packets can be up to 1500 bytes of payload.
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.
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.
Johnny
On 2021-01-11 23:43, Thomas DeBellis wrote:
Paul,
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.
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.
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.
I think there are two forensics to perform here:
1. Investigate when the errors started happening; whether they predate
Bob adopting PyDECnet
2. Investigate what the size difference is; I don't believe that is
going into the error log, but I'll have to look more carefully with
SPEAR.
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.
> ------------------------------------------------------------------------
> On 1/11/21 4:41 PM, Paul Koning wrote:
>
>> On Jan 11, 2021, at 4:22 PM, Thomas DeBellis<tommytimesharing at gmail.com>
wrote:
>>
>> 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
> 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.
>
>> 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:
>>
>> ? I could stub out the length error entry (XWD UNLER%,^D5) in the NIEVTB: table
in DNADLL.MAC.
>> ? I could put in a filter ($NOFIL) for event class 5 in the NMXFIL: table in
NTMAN.MAC.
>>
>> 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).
> 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.
>
> 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.
>
> Perhaps I should change PyDECnet to have a way to send shorter than max routing
messages.
>
> paul
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se <mailto:bqt at softjar.se> || Reading murder
books
pdp is alive! || tryin' to stay hip" - B. Idol