11 Apr
2023
11 Apr
'23
8:39 p.m.
In reverse order, I think the numeric-only concern is addressed easily
enough, assuming you think your own local executor's node data base is
up to date.
This is more or less the case on TOMMYT:: and VENTI2::, which download
the latest and greatest from MIM:: on a weekly basis and then use my
SETNODE rewrite to compute the set difference between the current and
new definitions in order to change as little as possible in the
monitor's volatile storage.
In short, if the remote node doesn't know, try recovering by asking the
local executor. That seems straightforward.
The question in my mind is what is 'reasonable' for netpth do to recover
if it doesn't get told the next node? By reasonable, I mean is the
process algorithmic (I.E., do this that or the other thing) or heuristic
(I.E., here are some good guesses) ?
------------------------------------------------------------------------
On 4/11/23 2:01 PM, Paul Koning wrote:
I didn't realize that. T1.1 will report next node if it's in the same
area or if it's adjacent. It should do so also if it's in a different
area, and I have coded that fix.
The "numeric only" happens if the node number in question isn't in the
node name database of that particular node.
paul
> ------------------------------------------------------------------------
> On Apr 11, 2023, at 1:00 PM, Thomas DeBellis
> <tommytimesharing(a)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'?