<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>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).<br>
    </p>
    <div class="moz-cite-prefix">
      <p>This can only be set once at system startup.  In the <font
          size="+1"><tt>SYSTEM:7-1-CONFIG.CMD</tt></font> file, the
        following should be inserted: <font size="+1"><tt>DECNET
            BUFFER-SIZE 1476</tt></font>.   When Tops-20 boots, the file
        is parsed by <font size="+1"><tt>SETSPD</tt></font> and various
        parameters can be set into the DECnet initialization block (<font
          size="+1"><tt>IBBLK</tt></font> in <font size="+1"><tt>D36COM</tt></font>). 
        Once <font size="+1"><tt>SETSPD</tt></font> is done, D36INI is
        called which brings up DECnet and the NRT and CTERM servers and
        locks out further changes.</p>
    </div>
    <div class="moz-cite-prefix">
      <p>I'll see about testing this on one of my systems by the
        weekend.</p>
    </div>
    <div class="moz-cite-prefix">
      <p>Judging from the source code, I suspect Tops-10 has the same
        problem.  I don't remember how to find errors there, however.</p>
    </div>
    <blockquote type="cite"
      cite="mid:9bfc99d5-aa15-2545-96ce-0f9fd598eafa@gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p> </p>
      <hr width="100%" size="2">
      <p>On 1/11/21 5:43 PM, Thomas DeBellis wrote:</p>
      <p>Paul,</p>
      <p>Lots of good information.  For right now, I did an experiment
        and  went into <font size="+1"><tt>MDDT</tt></font> and stubbed
        out the <font size="+1"><tt>XWD UNLER%,^D5</tt></font> entry in
        the <font size="+1"><tt>NIEVTB</tt></font>: 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.</p>
      <p>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.</p>
      <p>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>
      </p>
      <div class="moz-cite-prefix">I think there are two forensics to
        perform here:</div>
      <div class="moz-cite-prefix">
        <ol>
          <li>Investigate when the errors started happening; whether
            they predate Bob adopting PyDECnet</li>
          <li>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.</li>
        </ol>
        <p>A <b>warning</b> 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>
        </p>
      </div>
      <blockquote type="cite"
        cite="mid:06DE0558-38B2-4999-B164-D073D0DEB292@comcast.net">
        <hr width="100%" size="2">
        <pre class="moz-quote-pre" wrap="">On 1/11/21 4:41 PM, Paul Koning wrote:

</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">On Jan 11, 2021, at 4:22 PM, Thomas DeBellis <a class="moz-txt-link-rfc2396E" href="mailto:tommytimesharing@gmail.com" moz-do-not-send="true"><tommytimesharing@gmail.com></a> 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
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">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.

</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">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).
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">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

</pre>
      </blockquote>
    </blockquote>
  </body>
</html>