On Apr 11, 2023, at 1:00 PM, Thomas DeBellis <tommytimesharing@gmail.com> wrote:

Regarding its performance, I don't think netpth was ever a candidate for full productization, apparently being more of an internal tool for DECnet specialists.  However, this is only a guess.

From the edit history, it looks like it started out life in 1982 being put together by Stu Grossman, who I thought was working on Stanford at the time.  That would be surprising as I had thought Stanford didn't run Tops-10.  But maybe I'm wrong on both counts.  It then appears to have been adopted by Bill Davenport, Gunnar Lindell and Carl Appellof.  I don't know about Bill or Gunnar, but I'm pretty sure I remember Carl being at DEC.

I would guess netpth was part of a Tops-10 SWSKIT and was then partially ported to Tops-20.  It only uses those Tops-20 JSYi that are necessary to do its job.  Since Phase IV DECnet on the PDP-10 was first developed under Tops-10 (where it could run in user mode) and then ported to Tops-20 (it's all under conditional assembly), the API's are remarkably similar.  What I mean by that is the Tops-10 UUO and Tops-20 JSYS calling interface are nearly plug compatible with the exception of the UUO having more flexible register scheduling.

So, I think the crashing is due to error conditions that weren't anticipated in those early days, that is, that you would never not get told what the adjacent nodes were.  It is also not impossible that some of the fixes that I put into Tops-20 to report secondary error conditions could be triggering this.

I do remember netpth working at some point, Peter Lothberg demonstrated it about a year and a half ago on 10/21/21, viz:

[Routing path from MRC (59.41) to LEGATO (2.1)]

 From               Via        Back     Thru                           Cost    Hops
MRC    (59.41)    =>NI-0-0   / TAP-0       <=   OPS1VA (59.59)          -1      -1
OPS1VA (59.59)    =>GRE-3    / GRE-4       <=   IAD2   (59.1020)        -1      -1
IAD2   (59.1020)  =>DMC-0    / MUL-59-1020 <=   A2RTR  (2.1023)         -1      -1
A2RTR  (2.1023)   =>TAP-0    / QNA-1       <=   LEGATO (2.1)            -1      -1

I ran a few tests looking for various PyDECnet versions and their responses to a SHOW NODE xxx:: STATUS, viz:

Node	PyDECnet Version	Next Node?
A2RTR::	V1.0-596	Yes
PYRTR::	T1.1-640	No
STORTR::	*** Not Reported ***	Yes (Numeric, Only)
DEC000::	V1.0-583	No
NOVA::	V1.0-596	Yes
A29RT2::	T1.1-648	No

This suggested running a test through the older versions, which worked, viz:

[Routing path from VENTI2 (2.522) to SAMV02 (2.152)]

 From             Via         Back      Thru             Cost   Hops
VENTI2 (2.522)  =>NI-0-0    / BRG-0  <= A2RTR  (2.1023)    10      3
A2RTR  (2.1023) =>MUL-2-150 / MUL-1  <= SAMISH (2.199)      9      2
SAMISH (2.199)  =>ETH-0     / UNA-0  <= SAMV02 (2.152)      4      1

So what is this?  A newer version of PyDECnet isn't 'doing the right thing'?