12 Jan
2021
12 Jan
'21
2:28 a.m.
I finished doing my initial analysis to set up for larger buffers.? The
576 being reported by the VENTI2 NICE object is the default if you don't
set the buffer size.? There is a 28 byte overhead for a header that must
be accounted for, so the maximum size appears to be 1476 bytes (1500-28).
This can only be set once at system startup.? In the
SYSTEM:7-1-CONFIG.CMD file, the following should be inserted: DECNET
BUFFER-SIZE 1476.?? When Tops-20 boots, the file is parsed by SETSPD and
various parameters can be set into the DECnet initialization block
(IBBLK in D36COM). Once SETSPD is done, D36INI is called which brings up
DECnet and the NRT and CTERM servers and locks out further changes.
I'll see about testing this on one of my systems by the weekend.
Judging from the source code, I suspect Tops-10 has the same problem.? I
don't remember how to find errors there, however.
------------------------------------------------------------------------
On 1/11/21 5:43 PM, 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
>