11 Jan
2021
11 Jan
'21
8:33 p.m.
I was wondering if anybody else had either seen the below or noticed
it.? I didn't have as free space on my public structure as I thought I
should, so I went poking around and found:
TOMMYT:<SYSTEM-ERROR>?? Pages?? Bytes(Size)? Write Date and Time Writer
?ERROR.SYS.1;P777752????? 138,495 70909216(36) 11-Jan-2021 14:20:29
OPERATOR
To put this into perspective, we are looking at about a 304 MB file;
it's larger than what could have been held on an RP06? So I ran SPEAR
and pulled down a few of the most recent items, viz:
***********************************************
DECNET ENTRY
?LOGGED ON? 9-Jan-2021 19:02:18-EST????? MONITOR UPTIME WAS 113
day(s) 0:50:12
??????? DETECTED ON SYSTEM # 3691.
??????? RECORD SEQUENCE NUMBER: 28063.
***********************************************
DECNET Event type 5.15, Receive failed
From node 2.522 (VENTI2), occurred 9-JAN-2021 19:02:08
? Line NI-0-0
? Failure reason = Frame too long
? Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 FF 0B
There are hundreds of thousands of these, causing ERROR.SYS to grow by a
number of pages every day.? I didn't remember how to turn a DECnet node
number into dotted decimal, but I did notice the follow from the DECnet
bridge (SIGUSR1):
Host table:
0: purgatorio 0.0.0.0:0 (Rx: 2963632 (3352330) Tx: 1687334 Fw:
1276298 (Drop rx: 2076032)) Active: 1 Throttle: 598 (203)
1: legato 108.65.195.50:4711 [Ov: 0, Nov: 1693548, Lst: 0] (Rx:
1687334 (1693548) Tx: 1276298 Fw: 1687334 (Drop rx: 6214)) Active: 1
Throttle: 9054(070)
Hash of known destinations:
aa000400080a -> 0 (2.520)
aa0004000a0a -> 0 (2.522)
aa000400ff0b -> 1 (2.1023)
So one of these is coming over that bridge (2.1023).? What is AB 00 00
03 00 00?? Anybody have any ideas of what's going on?? I haven't looked
in the monitor code, yet.? If you are running any 36 bit OS, what are
you seeing?
11 Jan
11 Jan
9:13 p.m.
AB 00 00 03 00 00 is the All Routers address. It is likely a router sending a Hello
message advertising its presence, presumably coming from node 63.779.
Regards
Rob
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of
Thomas DeBellis
Sent: 11 January 2021 19:33
To: HECnet <hecnet at Update.UU.SE>
Subject: [HECnet] Thousands of DECnet errors on Tops-20
I was wondering if anybody else had either seen the below or noticed it. I didn't
have as free space on my public structure as I thought I should, so I went poking around
and found:
TOMMYT:<SYSTEM-ERROR> Pages Bytes(Size) Write Date and Time Writer
ERROR.SYS.1;P777752 138,495 70909216(36) 11-Jan-2021 14:20:29 OPERATOR
To put this into perspective, we are looking at about a 304 MB file; it's larger than
what could have been held on an RP06 So I ran SPEAR and pulled down a few of the most
recent items, viz:
***********************************************
DECNET ENTRY
LOGGED ON 9-Jan-2021 19:02:18-EST MONITOR UPTIME WAS 113 day(s) 0:50:12
DETECTED ON SYSTEM # 3691.
RECORD SEQUENCE NUMBER: 28063.
***********************************************
DECNET Event type 5.15, Receive failed
From node 2.522 (VENTI2), occurred 9-JAN-2021 19:02:08
Line NI-0-0
Failure reason = Frame too long
Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 FF 0B
There are hundreds of thousands of these, causing ERROR.SYS to grow by a number of pages
every day. I didn't remember how to turn a DECnet node number into dotted decimal,
but I did notice the follow from the DECnet bridge (SIGUSR1):
Host table:
0: purgatorio 0.0.0.0:0 (Rx: 2963632 (3352330) Tx: 1687334 Fw: 1276298 (Drop rx: 2076032))
Active: 1 Throttle: 598 (203)
1: legato 108.65.195.50:4711 [Ov: 0, Nov: 1693548, Lst: 0] (Rx: 1687334 (1693548) Tx:
1276298 Fw: 1687334 (Drop rx: 6214)) Active: 1 Throttle: 9054(070)
Hash of known destinations:
aa000400080a -> 0 (2.520)
aa0004000a0a -> 0 (2.522)
aa000400ff0b -> 1 (2.1023)
So one of these is coming over that bridge (2.1023). What is AB 00 00 03 00 00? Anybody
have any ideas of what's going on? I haven't looked in the monitor code, yet. If
you are running any 36 bit OS, what are you seeing?
10:22 p.m.
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
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:
1. I could stub out the length error entry (XWD UNLER%,^D5) in the
NIEVTB: table in DNADLL.MAC.
2. 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).
36 bitters!? If any of you could check your ERROR.SYS files, you could
be saving yourself from an eventual structure full crash or maybe you
might be providing some additional to me to help chase this.? I'd be
particularly interested in knowing if the problem is unique to KLH10 or not.
------------------------------------------------------------------------
On 1/11/21 3:13 PM, Rob Jarratt wrote:
AB 00 00 03 00 00 is the All Routers address. It is likely a router
sending a Hello message advertising its presence, presumably coming
from node 63.779.
Regards
Rob
*From:*owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> *On
Behalf Of *Thomas DeBellis
*Sent:* 11 January 2021 19:33
*To:* HECnet <hecnet at Update.UU.SE>
*Subject:* [HECnet] Thousands of DECnet errors on Tops-20
I was wondering if anybody else had either seen the below or noticed
it.? I didn't have as free space on my public structure as I thought I
should, so I went poking around and found:
?? TOMMYT:<SYSTEM-ERROR>?? Pages Bytes(Size)? Write Date and Time
Writer
?ERROR.SYS.1;P777752????? 138,495 70909216(36) 11-Jan-2021
14:20:29 OPERATOR
To put this into perspective, we are looking at about a 304 MB file;
it's larger than what could have been held on an RP06? So I ran SPEAR
and pulled down a few of the most recent items, viz:
***********************************************
DECNET ENTRY
?LOGGED ON? 9-Jan-2021 19:02:18-EST????? MONITOR UPTIME WAS 113
day(s) 0:50:12
??????? DETECTED ON SYSTEM # 3691.
??????? RECORD SEQUENCE NUMBER: 28063.
***********************************************
DECNET Event type 5.15, Receive failed
From node 2.522 (VENTI2), occurred 9-JAN-2021 19:02:08
? Line NI-0-0
? Failure reason = Frame too long
? Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 FF 0B
There are hundreds of thousands of these, causing ERROR.SYS to grow by
a number of pages every day.? I didn't remember how to turn a DECnet
node number into dotted decimal, but I did notice the follow from the
DECnet bridge (SIGUSR1):
Host table:
0: purgatorio 0.0.0.0:0 (Rx: 2963632 (3352330) Tx: 1687334 Fw:
1276298 (Drop rx: 2076032)) Active: 1 Throttle: 598 (203)
1: legato 108.65.195.50:4711 [Ov: 0, Nov: 1693548, Lst: 0] (Rx:
1687334 (1693548) Tx: 1276298 Fw: 1687334 (Drop rx: 6214)) Active:
1 Throttle: 9054(070)
Hash of known destinations:
aa000400080a -> 0 (2.520)
aa0004000a0a -> 0 (2.522)
aa000400ff0b -> 1 (2.1023)
So one of these is coming over that bridge (2.1023).? What is AB 00 00
03 00 00? Anybody have any ideas of what's going on?? I haven't looked
in the monitor code, yet.? If you are running any 36 bit OS, what are
you seeing?
10:41 p.m.
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
11:43 p.m.
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
12 Jan
12 Jan
2:24 a.m.
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 || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
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
2:56 a.m.
On 2021-01-12 02:39, Paul Koning wrote:
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).
591 is a very strange value. Where did you find that?
In RSX, by default one is derived from the other, but you can manipulate
them separately if wanted.
It's a bit unfortunate, but in general I would like to deal with them
separate in RSX.
The reason is that there is a microcode "bug" in the Qbus ethernet
controllers which can stop the controller from receiving packets when I
have IP running, as IP usually have an MTU of 1500 for ethernet. If the
system buffer size if 576, larger packets are split into parts, and this
is where the controller can get lost. But for DECnet, you obviously want
to just have 576 as the segment size.
So I in general recommend, especially for Qbus systems, that the system
buffer size is set to 1500. But if using multinet to a VMS machine in
the same area, you will then not get adjacency up, since RSX in the
DDCMP communication is using 1500 byte frames.
The second alternative is then to set the ethernet MTU for IP in RSX to
576. Which obviously is very detrimental to performance, and does not
fully solve the problem. But since TCP MSS is based on MTU, TCP
connections usually will limit themselves to an MSS that cause no
packets split into multiple buffers. But for other programs/protocols
which are not running over TCP, the risk is still there that you'll hang
the 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.
If we're talking about the buffer size thing, then this is only having
an effect on adjacent nodes, so the only type of packet loss you could
face would be if the other direct nodes can't handle this. For actual
DECnet traffic, the segment buffer size is what is used, so even if the
link buffer is larger, you won't be seeing larger packets.
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.
Yes. That is what I suspect is going on here. As mentioned in another
mail, I have only seen problems around this for links within one area,
so L1 messages.
L2 messages do not have problems.
(And I still think 591 is a very strange number...)
Johnny
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 11, 2021, at 8:24 PM, Johnny Billquist
<bqt at softjar.se
<mailto: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
>> <mailto: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
5:58 a.m.
Yes, I had seen this and had wondered about it after I had reflected on
the output of a SHOW EXECUTOR CHARACTERISTICS command(clipped)
Executor Node = 2.520 (TOMMYT)
? Identification = Tommy Timesharing
? Management Version = 4.0.0
? CPU = DECSYSTEM1020
? Software Identification = Tops-20 7.1 PANDA
.
.
.
Buffer Size = *576*
? Segment Buffer Size = *576*
So it would appear that the 20's implementation of NICE knows of this
differentiation.? I can parse for both SET EXECUTOR SEGMENT BUFFER SIZE
and SET EXECUTOR BUFFER SIZE.? Both fail, of course; again, once DECnet
is initialized, they are locked.
However, when one looks at the DECnet initialization block (IBBLK), it
only contains a field for buffer size (IBBSZ), nothing about segment
size.? Further, the NODE% JSYS' set DECnet initialization parameters
function (.NDPRM) only contains a sub-function for buffer size (.NDBSZ)
and SETSPD will only parse for DECNET BUFFER-SIZE.? I'm hopeful to test
that this weekend after I've looked further through the error log.
The receive code in the low level NI driver (PHYKNI) only checks to see
whether was was received will fit into the buffer specified.? It returns
a length error (UNLER%) to DNADLL, but not the actual difference.
I have yet to puzzle out how the segment size is derived, but it is
apparently set on a line basis.
------------------------------------------------------------------------
On 1/11/21 8:24 PM, Johnny Billquist 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
>
9:29 p.m.
The DECnet segment size has to be the same "network wide".
If I remember right DECnet looks at the two end nodes and uses the smalles segment size,
so if there is any transit node in the path with a small segment size things will not work
as
it will drop packets bigger than it''s size.
The only SW/HW combination I knew of that has other than 576 is MRC/Stu DECnet for
Tops20 4.x on DEC2020.
-P
From: "tommytimesharing"
<tommytimesharing at gmail.com>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Monday, January 11, 2021 11:58:56 PM
Subject: Re: [HECnet] Thousands of DECnet errors on Tops-20
Yes, I had seen this and had wondered about it after I
had reflected on the
output of a SHOW EXECUTOR CHARACTERISTICS command(clipped)
> Executor Node = 2.520 (TOMMYT)
> Identification = Tommy Timesharing
> Management Version = 4.0.0
> CPU = DECSYSTEM1020
> Software Identification = Tops-20 7.1 PANDA
>>> .
>>> .
>>> .
> Buffer Size = 576
> Segment Buffer Size = 576
So it would appear that the 20's implementation of
NICE knows of this
differentiation. I can parse for both SET EXECUTOR SEGMENT BUFFER SIZE and SET
EXECUTOR BUFFER SIZE . Both fail, of course; again, once DECnet is initialized,
they are locked.
However, when one looks at the DECnet initialization
block ( IBBLK ), it only
contains a field for buffer size ( IBBSZ ), nothing about segment size.
Further, the NODE% JSYS ' set DECnet initialization parameters function (
.NDPRM ) only contains a sub-function for buffer size ( .NDBSZ ) and SETSPD
will only parse for DECNET BUFFER-SIZE . I'm hopeful to test that this weekend
after I've looked further through the error log.
The receive code in the low level NI driver ( PHYKNI )
only checks to see
whether was was received will fit into the buffer specified. It returns a
length error ( UNLER% ) to DNADLL , but not the actual difference.
I have yet to puzzle out how the segment size is
derived, but it is apparently
set on a line basis.
> On 1/11/21 8:24 PM, Johnny Billquist 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 [ mailto:tommytimesharing at gmail.com
>>>> | <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
10:21 p.m.
That's certainly sufficient but the precise rule is somewhat more lenient.
Segment buffer size controls the largest packet NSP will generate. Buffer size specifies
the largest packet the routing layer can forward. The requirement for two nodes to be
able to communicate is that the Buffer Size value for each of the routers on the path
between the two must be >= the smaller of the two segment buffer size values at the NSP
end points.
For sanity, this translates into: all routers must have a Buffer Size >= the value of
any Segment Buffer Size. But it's perfectly legal for the segment buffer size to be
smaller, or inconsistent. Also, it's perfectly legal for an end node to have a small
Buffer Size, and some small systems indeed do this. The reason is that end nodes
don't forward, so the messages they are dealing with can only ever be as large as
their segment buffer size, since that's exchanged during NSP connection
establishment.
Reading carefully in the various DECnet specs I think I got the buffer size parameter
wrong for Ethernet circuits. It looks like I should limit the routing packets to the
Buffer Size (the common parameter, i.e., 576) rather than using a larger value on
Ethernet. That should cure the issue Thomas discovered.
paul
On Jan 12, 2021, at 3:29 PM, Peter Lothberg <roll
at stupi.com> wrote:
The DECnet segment size has to be the same "network wide".
If I remember right DECnet looks at the two end nodes and uses the smalles segment size,
so if there is any transit node in the path with a small segment size things will not
work as
it will drop packets bigger than it''s size.
The only SW/HW combination I knew of that has other than 576 is MRC/Stu DECnet for
Tops20 4.x on DEC2020.
-P
From: "tommytimesharing" <tommytimesharing at gmail.com>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Monday, January 11, 2021 11:58:56 PM
Subject: Re: [HECnet] Thousands of DECnet errors on Tops-20
Yes, I had seen this and had wondered about it after I had reflected on the output of a
SHOW EXECUTOR CHARACTERISTICS command(clipped)
Executor Node = 2.520 (TOMMYT)
Identification = Tommy Timesharing
Management Version = 4.0.0
CPU = DECSYSTEM1020
Software Identification = Tops-20 7.1 PANDA
.
.
.
Buffer Size = 576
Segment Buffer Size = 576
So it would appear that the 20's implementation of NICE knows of this
differentiation. I can parse for both SET EXECUTOR SEGMENT BUFFER SIZE and SET EXECUTOR
BUFFER SIZE. Both fail, of course; again, once DECnet is initialized, they are locked.
However, when one looks at the DECnet initialization block (IBBLK), it only contains a
field for buffer size (IBBSZ), nothing about segment size. Further, the NODE% JSYS'
set DECnet initialization parameters function (.NDPRM) only contains a sub-function for
buffer size (.NDBSZ) and SETSPD will only parse for DECNET BUFFER-SIZE. I'm hopeful
to test that this weekend after I've looked further through the error log.
The receive code in the low level NI driver (PHYKNI) only checks to see whether was was
received will fit into the buffer specified. It returns a length error (UNLER%) to
DNADLL, but not the actual difference.
I have yet to puzzle out how the segment size is derived, but it is apparently set on a
line basis.
On 1/11/21 8:24 PM, Johnny Billquist 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
11:49 p.m.
Before you fix that (if you do), would you might my testing some changes
I made, first?
On 1/12/21 4:21 PM, Paul Koning wrote:
That's certainly sufficient but the precise rule
is somewhat more lenient.
Segment buffer size controls the largest packet NSP will generate. Buffer size specifies
the largest packet the routing layer can forward. The requirement for two nodes to be
able to communicate is that the Buffer Size value for each of the routers on the path
between the two must be >= the smaller of the two segment buffer size values at the NSP
end points.
For sanity, this translates into: all routers must have a Buffer Size >= the value of
any Segment Buffer Size. But it's perfectly legal for the segment buffer size to be
smaller, or inconsistent. Also, it's perfectly legal for an end node to have a small
Buffer Size, and some small systems indeed do this. The reason is that end nodes
don't forward, so the messages they are dealing with can only ever be as large as
their segment buffer size, since that's exchanged during NSP connection
establishment.
Reading carefully in the various DECnet specs I think I got the buffer size parameter
wrong for Ethernet circuits. It looks like I should limit the routing packets to the
Buffer Size (the common parameter, i.e., 576) rather than using a larger value on
Ethernet. That should cure the issue Thomas discovered.
paul
> On Jan 12, 2021, at 3:29 PM, Peter Lothberg <roll at stupi.com> wrote:
>
> The DECnet segment size has to be the same "network wide".
>
> If I remember right DECnet looks at the two end nodes and uses the smalles segment
size,
> so if there is any transit node in the path with a small segment size things will not
work as
> it will drop packets bigger than it''s size.
>
> The only SW/HW combination I knew of that has other than 576 is MRC/Stu DECnet for
> Tops20 4.x on DEC2020.
>
> -P
>
> From: "tommytimesharing" <tommytimesharing at gmail.com>
> To: "hecnet" <hecnet at Update.UU.SE>
> Sent: Monday, January 11, 2021 11:58:56 PM
> Subject: Re: [HECnet] Thousands of DECnet errors on Tops-20
> Yes, I had seen this and had wondered about it after I had reflected on the output of
a SHOW EXECUTOR CHARACTERISTICS command(clipped)
>
> Executor Node = 2.520 (TOMMYT)
>
> Identification = Tommy Timesharing
> Management Version = 4.0.0
> CPU = DECSYSTEM1020
> Software Identification = Tops-20 7.1 PANDA
>
> .
> .
> .
> Buffer Size = 576
> Segment Buffer Size = 576
>
> So it would appear that the 20's implementation of NICE knows of this
differentiation. I can parse for both SET EXECUTOR SEGMENT BUFFER SIZE and SET EXECUTOR
BUFFER SIZE. Both fail, of course; again, once DECnet is initialized, they are locked.
>
> However, when one looks at the DECnet initialization block (IBBLK), it only contains
a field for buffer size (IBBSZ), nothing about segment size. Further, the NODE% JSYS'
set DECnet initialization parameters function (.NDPRM) only contains a sub-function for
buffer size (.NDBSZ) and SETSPD will only parse for DECNET BUFFER-SIZE. I'm hopeful
to test that this weekend after I've looked further through the error log.
>
> The receive code in the low level NI driver (PHYKNI) only checks to see whether was
was received will fit into the buffer specified. It returns a length error (UNLER%) to
DNADLL, but not the actual difference.
>
> I have yet to puzzle out how the segment size is derived, but it is apparently set on
a line basis.
>
> On 1/11/21 8:24 PM, Johnny Billquist 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
>
>
>
13 Jan
13 Jan
2:51 a.m.
By all means go ahead. I think for me to change what I did is the right thing, but
I'll hold off until you're finished with what you want to test.
paul
On Jan 12, 2021, at 5:49 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
Before you fix that (if you do), would you might my testing some changes I made, first?
On 1/12/21 4:21 PM, Paul Koning wrote:
> That's certainly sufficient but the precise rule is somewhat more lenient.
>
> Segment buffer size controls the largest packet NSP will generate. Buffer size
specifies the largest packet the routing layer can forward. The requirement for two nodes
to be able to communicate is that the Buffer Size value for each of the routers on the
path between the two must be >= the smaller of the two segment buffer size values at
the NSP end points.
>
> For sanity, this translates into: all routers must have a Buffer Size >= the value
of any Segment Buffer Size. But it's perfectly legal for the segment buffer size to
be smaller, or inconsistent. Also, it's perfectly legal for an end node to have a
small Buffer Size, and some small systems indeed do this. The reason is that end nodes
don't forward, so the messages they are dealing with can only ever be as large as
their segment buffer size, since that's exchanged during NSP connection
establishment.
>
> Reading carefully in the various DECnet specs I think I got the buffer size parameter
wrong for Ethernet circuits. It looks like I should limit the routing packets to the
Buffer Size (the common parameter, i.e., 576) rather than using a larger value on
Ethernet. That should cure the issue Thomas discovered.
>
> paul
>
>
>> On Jan 12, 2021, at 3:29 PM, Peter Lothberg <roll at stupi.com> wrote:
>>
>> The DECnet segment size has to be the same "network wide".
>>
>> If I remember right DECnet looks at the two end nodes and uses the smalles
segment size,
>> so if there is any transit node in the path with a small segment size things will
not work as
>> it will drop packets bigger than it''s size.
>>
>> The only SW/HW combination I knew of that has other than 576 is MRC/Stu DECnet
for
>> Tops20 4.x on DEC2020.
>>
>> -P
>>
>> From: "tommytimesharing" <tommytimesharing at gmail.com>
>> To: "hecnet" <hecnet at Update.UU.SE>
>> Sent: Monday, January 11, 2021 11:58:56 PM
>> Subject: Re: [HECnet] Thousands of DECnet errors on Tops-20
>> Yes, I had seen this and had wondered about it after I had reflected on the
output of a SHOW EXECUTOR CHARACTERISTICS command(clipped)
>>
>> Executor Node = 2.520 (TOMMYT)
>>
>> Identification = Tommy Timesharing
>> Management Version = 4.0.0
>> CPU = DECSYSTEM1020
>> Software Identification = Tops-20 7.1 PANDA
>>
>> .
>> .
>> .
>> Buffer Size = 576
>> Segment Buffer Size = 576
>>
>> So it would appear that the 20's implementation of NICE knows of this
differentiation. I can parse for both SET EXECUTOR SEGMENT BUFFER SIZE and SET EXECUTOR
BUFFER SIZE. Both fail, of course; again, once DECnet is initialized, they are locked.
>>
>> However, when one looks at the DECnet initialization block (IBBLK), it only
contains a field for buffer size (IBBSZ), nothing about segment size. Further, the NODE%
JSYS' set DECnet initialization parameters function (.NDPRM) only contains a
sub-function for buffer size (.NDBSZ) and SETSPD will only parse for DECNET BUFFER-SIZE.
I'm hopeful to test that this weekend after I've looked further through the error
log.
>>
>> The receive code in the low level NI driver (PHYKNI) only checks to see whether
was was received will fit into the buffer specified. It returns a length error (UNLER%)
to DNADLL, but not the actual difference.
>>
>> I have yet to puzzle out how the segment size is derived, but it is apparently
set on a line basis.
>>
>> On 1/11/21 8:24 PM, Johnny Billquist 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
>>
>>
>>
6:04 p.m.
Thanks!? If I'm understanding your interpretation of the DECnet
specifications, I think you may be right; so this is definitely
something /To Do/.
A couple of things are bothering me about Tops-20's handling of the
situation.? Many of the changes that we (universities) made over the
years were either to enable the system to better handle problems or to
better signal them.? The lore is that the access control job was a
Columbia suggestion, but MIT and Stanford had plenty others.? Two that
DEC did would be routing BUG alerts through Galaxy so more people would
see them and generalizing error capturing with Dump-on-Bug.
/Nothing/ came up on the operator consoles about this, even though the
error file was increasing by pages a day, eventually swelling to
gargantuan size.? It's the kind of thing that could make the system
effectively unusable to somebody who wasn't paying attention.? I had
noted the disk usage increase, but had naively attributed this to the
large amount of data I was accumulating, downloaded updated sources, Etc.
I think some better introductory documentation might be written as to
how to configure DECnet with cautions, provisos and examples.? So I had
some notes and I guess I'll tidy those up.
Meanwhile, the frame length error reporting code needs to be enhanced in
two ways:
1. In addition to the Ethernet mac addresses, it ought to report the
differences in frame and buffer sizes
2. It ought to have some throttling:
* After 'X' time, do a BUGINF
* After 'X' time, stop logging the same frame error
Since I've shut off logging of the error (by stomping NIEVTB+4 to -1),
my log files aren't increasing as drastically.? I'm getting a number of
node-offline-online events, but I'm not sure if I caused those with some
other things I was doing.
------------------------------------------------------------------------
On 1/12/21 8:51 PM, Paul Koning wrote:
By all means go ahead. I think for me to change what I did is the right thing, but
I'll hold off until you're finished with what you want to test.
paul
> ------------------------------------------------------------------------
> On Jan 12, 2021, at 5:49 PM, Thomas DeBellis <tommytimesharing at gmail.com>
wrote:
>
> Before you fix that (if you do), would you might my testing some changes I made,
first?
>> ------------------------------------------------------------------------
>> On 1/12/21 4:21 PM, Paul Koning wrote:
>> That's certainly sufficient but the precise rule is somewhat more lenient.
>>
>> Segment buffer size controls the largest packet NSP will generate. Buffer size
specifies the largest packet the routing layer can forward. The requirement for two nodes
to be able to communicate is that the Buffer Size value for each of the routers on the
path between the two must be >= the smaller of the two segment buffer size values at
the NSP end points.
>>
>> For sanity, this translates into: all routers must have a Buffer Size >= the
value of any Segment Buffer Size. But it's perfectly legal for the segment buffer
size to be smaller, or inconsistent. Also, it's perfectly legal for an end node to
have a small Buffer Size, and some small systems indeed do this. The reason is that end
nodes don't forward, so the messages they are dealing with can only ever be as large
as their segment buffer size, since that's exchanged during NSP connection
establishment.
>>
>> Reading carefully in the various DECnet specs I think I got the buffer size
parameter wrong for Ethernet circuits. It looks like I should limit the routing packets
to the Buffer Size (the common parameter, i.e., 576) rather than using a larger value on
Ethernet. That should cure the issue Thomas discovered.
>>
>> paul
>>> ------------------------------------------------------------------------
>>> On Jan 12, 2021, at 3:29 PM, Peter Lothberg <roll at stupi.com> wrote:
>>>
>>> The DECnet segment size has to be the same "network wide".
>>>
>>> If I remember right DECnet looks at the two end nodes and uses the smalles
segment size,
>>> so if there is any transit node in the path with a small segment size things
will not work as
>>> it will drop packets bigger than it''s size.
>>>
>>> The only SW/HW combination I knew of that has other than 576 is MRC/Stu
DECnet for
>>> Tops20 4.x on DEC2020.
>>>
>>> -P
>>>> ------------------------------------------------------------------------
>>>> *From*: "tommytimesharing" <tommytimesharing at
gmail.com>
>>>> *To*: "hecnet" <hecnet at Update.UU.SE>
>>>> *Sent*: Monday, January 11, 2021 11:58:56 PM
>>>> *Subject*: Re: [HECnet] Thousands of DECnet errors on Tops-20
>>>>
>>>> Yes, I had seen this and had wondered about it after I had reflected on
the output of a SHOW EXECUTOR CHARACTERISTICS command(clipped)
>>>>
>>>> Executor Node = 2.520 (TOMMYT)
>>>>
>>>> Identification = Tommy Timesharing
>>>> Management Version = 4.0.0
>>>> CPU = DECSYSTEM1020
>>>> Software Identification = Tops-20 7.1 PANDA
>>>>
>>>> .
>>>> .
>>>> .
>>>> Buffer Size = 576
>>>> Segment Buffer Size = 576
>>>>
>>>> So it would appear that the 20's implementation of NICE knows of this
differentiation. I can parse for both SET EXECUTOR SEGMENT BUFFER SIZE and SET EXECUTOR
BUFFER SIZE. Both fail, of course; again, once DECnet is initialized, they are locked.
>>>>
>>>> However, when one looks at the DECnet initialization block (IBBLK), it
only contains a field for buffer size (IBBSZ), nothing about segment size. Further, the
NODE% JSYS' set DECnet initialization parameters function (.NDPRM) only contains a
sub-function for buffer size (.NDBSZ) and SETSPD will only parse for DECNET BUFFER-SIZE.
I'm hopeful to test that this weekend after I've looked further through the error
log.
>>>>
>>>> The receive code in the low level NI driver (PHYKNI) only checks to see
whether was was received will fit into the buffer specified. It returns a length error
(UNLER%) to DNADLL, but not the actual difference.
>>>>
>>>> I have yet to puzzle out how the segment size is derived, but it is
apparently set on a line basis.
>>>>
>>>> On 1/11/21 8:24 PM, Johnny Billquist 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
>>>>>
>>>>>
>>>>>
>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
12 Jan
12 Jan
11:29 p.m.
Right. DECnet segment size is picky. I would really recommend people to
just leave it at 576 everywhere. Of course, with end nodes, other values
(especially smaller ones) will not hurt. But it's best to usually not
play around with it.
But then we have this buffer size, which is separate, and which caused
the problems towards VMS that I found out at Stupi. But it seems it
might also play tricks in Tops-20 then...
Johnny
On 2021-01-12 21:29, Peter Lothberg wrote:
The DECnet segment size has to be the same
"network wide".
If I remember right DECnet looks at the two end nodes and uses the
smalles segment size,
so if there is any transit node in the path with a small segment size
things will not work as
it will drop packets bigger than it''s size.
The only SW/HW combination I knew of that has other than 576 is MRC/Stu
DECnet for
Tops20 4.x on DEC2020.
-P
------------------------------------------------------------------------
*From: *"tommytimesharing" <tommytimesharing at gmail.com>
*To: *"hecnet" <hecnet at Update.UU.SE>
*Sent: *Monday, January 11, 2021 11:58:56 PM
*Subject: *Re: [HECnet] Thousands of DECnet errors on Tops-20
Yes, I had seen this and had wondered about it after I had reflected
on the output of a SHOW EXECUTOR CHARACTERISTICS command(clipped)
Executor Node = 2.520 (TOMMYT)
? Identification = Tommy Timesharing
? Management Version = 4.0.0
? CPU = DECSYSTEM1020
? Software Identification = Tops-20 7.1 PANDA
.
.
.
Buffer Size = *576*
? Segment Buffer Size = *576*
So it would appear that the 20's implementation of NICE knows of
this differentiation.? I can parse for both SET EXECUTOR SEGMENT
BUFFER SIZE and SET EXECUTOR BUFFER SIZE.? Both fail, of course;
again, once DECnet is initialized, they are locked.
However, when one looks at the DECnet initialization block (IBBLK),
it only contains a field for buffer size (IBBSZ), nothing about
segment size.? Further, the NODE% JSYS' set DECnet initialization
parameters function (.NDPRM) only contains a sub-function for buffer
size (.NDBSZ) and SETSPD will only parse for DECNET BUFFER-SIZE.
I'm hopeful to test that this weekend after I've looked further
through the error log.
The receive code in the low level NI driver (PHYKNI) only checks to
see whether was was received will fit into the buffer specified.? It
returns a length error (UNLER%) to DNADLL, but not the actual
difference.
I have yet to puzzle out how the segment size is derived, but it is
apparently set on a line basis.
------------------------------------------------------------------------
On 1/11/21 8:24 PM, Johnny Billquist 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>
<mailto: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 || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
15 Jan
15 Jan
9:59 p.m.
Was this maybe that magical version 5 of Tops-20 that MRC put together
for the 2020?? I sure would love to see the sources for that!? I'm not
sure if this is relevant, but the following macro in D36COM is of interest:
DEFINE KNMMCS,<
;????????????? Symbol,Name,Cost, Maximum receive block size
??????? KNMMAC LD.TST,TST,? 1,? 0 ;TST DEVICE
??????? KNMMAC LD.DTE,DTE,? 3, <^D576>???????????????? ;DTE DEVICE
??????? KNMMAC LD.KDP,KDP,? 4, <^D576>???????????????? ;KDP DEVICE
??????? KNMMAC LD.DDP,DDP,? 5, <^D576>???????????????? ;DDP DEVICE
??????? KNMMAC LD.CIP,CI,?? 2, <^D576>???????????????? ;CI DEVICE
??????? KNMMAC LD.NI ,NI,?? 1, <^D1504-%RTEHS>???????? ;NI DEVICE
??????? KNMMAC LD.DMR,DMR,? 2, <^D576>???????????????? ;DMR DEVICE
;END OF KNMMCS
What can be seen is that the maximum block size is 576 in _all_ cases
except the NI, which is 1476 bytes.? I don't know if any of these
devices are relevant to the 2020; one assumes that the DTE, CI and NI
are not.
------------------------------------------------------------------------
On 1/12/21 3:29 PM, Peter Lothberg wrote:
The DECnet segment size has to be the same "network wide".
If I remember right DECnet looks at the two end nodes and uses the
smalles segment size,
so if there is any transit node in the path with a small segment size
things will not work as
it will drop packets bigger than it''s size.
The only SW/HW combination I knew of that has other than 576 is
MRC/Stu DECnet for
Tops20 4.x on DEC2020.
-P
------------------------------------------------------------------------
*From: *"tommytimesharing" <tommytimesharing at gmail.com>
*To: *"hecnet" <hecnet at Update.UU.SE>
*Sent: *Monday, January 11, 2021 11:58:56 PM
*Subject: *Re: [HECnet] Thousands of DECnet errors on Tops-20
Yes, I had seen this and had wondered about it after I had
reflected on the output of a SHOW EXECUTOR CHARACTERISTICS
command(clipped)
Executor Node = 2.520 (TOMMYT)
? Identification = Tommy Timesharing
? Management Version = 4.0.0
? CPU = DECSYSTEM1020
? Software Identification = Tops-20 7.1 PANDA
.
.
.
Buffer Size = *576*
? Segment Buffer Size = *576*
So it would appear that the 20's implementation of NICE knows of
this differentiation.? I can parse for both SET EXECUTOR SEGMENT
BUFFER SIZE and SET EXECUTOR BUFFER SIZE. Both fail, of course;
again, once DECnet is initialized, they are locked.
However, when one looks at the DECnet initialization block
(IBBLK), it only contains a field for buffer size (IBBSZ), nothing
about segment size.? Further, the NODE% JSYS' set DECnet
initialization parameters function (.NDPRM) only contains a
sub-function for buffer size (.NDBSZ) and SETSPD will only parse
for DECNET BUFFER-SIZE. I'm hopeful to test that this weekend
after I've looked further through the error log.
The receive code in the low level NI driver (PHYKNI) only checks
to see whether was was received will fit into the buffer
specified.? It returns a length error (UNLER%) to DNADLL, but not
the actual difference.
I have yet to puzzle out how the segment size is derived, but it
is apparently set on a line basis.
------------------------------------------------------------------------
On 1/11/21 8:24 PM, Johnny Billquist 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>
<mailto: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
10:21 p.m.
Well, MRC was receiving "suggestions" from Stu Grossman on how to do it, but
if my memory does not fail me the block size was 312, due to lack of buffer space
in the already crammed single section 512KW 2020. I'm afraid my tape and disk-pack
are in Seattle. I knew it was not 576 as it had two DUP-11's and using it for transit
failed...
Quiz, do you knew what a DDP is?
-P
From: "tommytimesharing"
<tommytimesharing at gmail.com>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Friday, January 15, 2021 3:59:25 PM
Subject: Re: [HECnet] Thousands of DECnet errors on Tops-20
Was this maybe that magical version 5 of Tops-20 that
MRC put together for the
2020? I sure would love to see the sources for that! I'm not sure if this is
relevant, but the following macro in D36COM is of interest:
> DEFINE KNMMCS,<
> ; Symbol,Name,Cost, Maximum receive block size
> KNMMAC LD.TST,TST, 1, 0 ;TST DEVICE
> KNMMAC LD.DTE,DTE, 3, <^D576> ;DTE DEVICE
> KNMMAC LD.KDP,KDP, 4, <^D576> ;KDP DEVICE
> KNMMAC LD.DDP,DDP, 5, <^D576> ;DDP DEVICE
> KNMMAC LD.CIP,CI, 2, <^D576> ;CI DEVICE
> KNMMAC LD.NI ,NI, 1, <^D1504-%RTEHS> ;NI DEVICE
> KNMMAC LD.DMR,DMR, 2, <^D576> ;DMR DEVICE
> >;END OF KNMMCS
What can be seen is that the maximum block size is 576
in all cases except the
NI, which is 1476 bytes. I don't know if any of these devices are relevant to
the 2020; one assumes that the DTE, CI and NI are not.
> On 1/12/21 3:29 PM, Peter Lothberg wrote:
> The DECnet segment size has to be the same
"network wide".
> If I remember right DECnet looks at the two end
nodes and uses the smalles
> segment size,
> so if there is any transit node in the path with a small segment size things
> will not work as
> it will drop packets bigger than it''s size.
> The only SW/HW combination I knew of that has
other than 576 is MRC/Stu DECnet
> for
> Tops20 4.x on DEC2020.
> -P
10:24 p.m.
DDP?? I thought it was DUP-11.
------------------------------------------------------------------------
On 1/15/21 4:21 PM, Peter Lothberg wrote:
Well, MRC was receiving "suggestions" from Stu Grossman on how to do
it, but
if my memory does not fail me the block size was 312, due to lack of
buffer space
in the already crammed single section 512KW 2020. I'm afraid my tape
and disk-pack
are in Seattle. I knew it was not 576 as it had two DUP-11's and using
it for transit failed...
Quiz, do you knew what a DDP is?
-P
------------------------------------------------------------------------
*From: *"tommytimesharing" <tommytimesharing at gmail.com>
*To: *"hecnet" <hecnet at Update.UU.SE>
*Sent: *Friday, January 15, 2021 3:59:25 PM
*Subject: *Re: [HECnet] Thousands of DECnet errors on Tops-20
Was this maybe that magical version 5 of Tops-20 that MRC put
together for the 2020?? I sure would love to see the sources for
that!? I'm not sure if this is relevant, but the following macro
in D36COM is of interest:
DEFINE KNMMCS,<
;????????????? Symbol,Name,Cost, Maximum receive block size
??????? KNMMAC LD.TST,TST,? 1, 0?????????????????????? ;TST DEVICE
??????? KNMMAC LD.DTE,DTE,? 3, <^D576>???????????????? ;DTE DEVICE
??????? KNMMAC LD.KDP,KDP,? 4, <^D576>???????????????? ;KDP DEVICE
??????? KNMMAC LD.DDP,DDP,? 5, <^D576>???????????????? ;DDP DEVICE
??????? KNMMAC LD.CIP,CI,?? 2, <^D576>???????????????? ;CI DEVICE
??????? KNMMAC LD.NI ,NI,?? 1, <^D1504-%RTEHS>???????? ;NI DEVICE
??????? KNMMAC LD.DMR,DMR,? 2, <^D576>???????????????? ;DMR DEVICE
;END OF KNMMCS
What can be seen is that the maximum block size is 576 in _all_
cases except the NI, which is 1476 bytes.? I don't know if any of
these devices are relevant to the 2020; one assumes that the DTE,
CI and NI are not.
------------------------------------------------------------------------
On 1/12/21 3:29 PM, Peter Lothberg wrote:
The DECnet segment size has to be the same "network wide".
If I remember right DECnet looks at the two end nodes and uses
the smalles segment size,
so if there is any transit node in the path with a small
segment size things will not work as
it will drop packets bigger than it''s size.
The only SW/HW combination I knew of that has other than 576
is MRC/Stu DECnet for
Tops20 4.x on DEC2020.
-P
10:53 p.m.
The 2020 has a KMC11 and up to 2 DUP11, and those are the interfaces
the "MRC T20 DECnet thing supports.
On the list of devices/sizes you posted is a "DDP" device and I wounder
if you knew what that is?
--P
From: "tommytimesharing"
<tommytimesharing at gmail.com>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Friday, January 15, 2021 4:24:07 PM
Subject: Re: [HECnet] Thousands of DECnet errors on Tops-20
DDP? I thought it was DUP-11.
> On 1/15/21 4:21 PM, Peter Lothberg wrote:
> Well, MRC was receiving "suggestions"
from Stu Grossman on how to do it, but
> if my memory does not fail me the block size was 312, due to lack of buffer
> space
> in the already crammed single section 512KW 2020. I'm afraid my tape and
> disk-pack
> are in Seattle. I knew it was not 576 as it had two DUP-11's and using it for
> transit failed...
> Quiz, do you knew what a DDP is?
> -P
16 Jan
16 Jan
5:58 a.m.
I saw that and wondered as well.
I was thinking maybe it could be for DDCMP devices without more
specifically defining what it would be, since DDCMP could be run over
any serial line?
Johnny
On 2021-01-15 22:53, Peter Lothberg wrote:
The 2020 has a KMC11 and up to 2 DUP11, and those are
the interfaces
the "MRC T20 DECnet thing supports.
On the list of devices/sizes you posted is? a "DDP" device and I wounder
if you knew what that is?
--P
------------------------------------------------------------------------
*From: *"tommytimesharing" <tommytimesharing at gmail.com>
*To: *"hecnet" <hecnet at Update.UU.SE>
*Sent: *Friday, January 15, 2021 4:24:07 PM
*Subject: *Re: [HECnet] Thousands of DECnet errors on Tops-20
DDP?? I thought it was DUP-11.
------------------------------------------------------------------------
On 1/15/21 4:21 PM, Peter Lothberg wrote:
Well, MRC was receiving "suggestions" from Stu Grossman on how
to do it, but
if my memory does not fail me the block size was 312, due to
lack of buffer space
in the already crammed single section 512KW 2020. I'm afraid my
tape and disk-pack
are in Seattle. I knew it was not 576 as it had two DUP-11's and
using it for transit failed...
Quiz, do you knew what a DDP is?
-P
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
17 Jan
17 Jan
11:10 p.m.
The only serial lines that I saw DECnet running on were synchronous
connections.? The local connections between CU's 20's (before we got the
CI's and NI's) were 56K baud synchronous lines running on KMC11's, which
we thought were pretty hot stuff ...until...? Non-data center
connections (our chemistry VAX, CMU & CWR 20's) were asynchronous lines
running 9.6K baud (on DUP11's, I think).
The PANDA monitor's Multinet code implements serial IP (SLIP), which it
will run over an ordinary DL or DH based asynchronous lines.? I didn't
immediately see anything similar for DECnet, but it is doubtful that MRC
would have put that it in; the code was supposed to run on a 2020, which
has different IO drivers.? If his 2020 5.0 changes ever do surface, it
may be conceivable that some of them might be retrofitted into 7.1
(depends on what's applicable).
It is now possible that I will eventually figure out what this
mysterious DDP device is.? I reconfigured both 20's to have the largest
buffer possible (DECNET BUFFER-SIZE 1476 in SYSTEM:7-1-CONFIG.CMD, which
I checked in the running monitor), rebooted /and/ ... I'm still getting
the same frame too long error, viz:
***********************************************
DECNET ENTRY
?LOGGED ON 16-Jan-2021 01:29:38-EST????? MONITOR UPTIME WAS 0
day(s) 0:16:8
??????? DETECTED ON SYSTEM # 3691.
??????? RECORD SEQUENCE NUMBER: 35752.
***********************************************
DECNET Event type 5.15, Receive failed
From node 2.522 (VENTI2), occurred 16-JAN-2021 01:29:11
? Line NI-0-0
? Failure reason = Frame too long
? Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 08 0A
***********************************************
DECNET ENTRY
?LOGGED ON 16-Jan-2021 01:29:38-EST????? MONITOR UPTIME WAS 0
day(s) 0:16:8
??????? DETECTED ON SYSTEM # 3691.
??????? RECORD SEQUENCE NUMBER: 35753.
***********************************************
DECNET Event type 5.15, Receive failed
From node 2.522 (VENTI2), occurred 16-JAN-2021 01:29:28
? Line NI-0-0
? Failure reason = Frame too long
? Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 FF 0B
************************************************************************
Darn it??? So now I've got some modifications to actually make to the
monitor to give some better error information (like the number of bytes
overrun, if I can extract it).? So maybe I'll stumble over whatever DDP
does.? It's odd; I can't think of any device that a pack of KL's could
share except something like a dual ported disk or magnetic tape drive
and that's only two KL's.
Meanwhile, I'll also do a tcpdump so I can try to correlate what Tops-20
is silently whining about with what's coming over the bridge.
Finally, something to beware of if you are running the KLH10
micro-engine and have a very large file that you're backing up (you're
all running regular backups, /right/?)? The amount of disk activity will
somehow prevent KLH10's front end timer from popping so, unless you are
running my changes to DTESRV, you're going to /hang/ with a DTEKPA
BUGINF.? A quick hack is to deposit a -1 into FEDBSW, which will keep
the 20 from trying to reboot the front end (which KLH10 absolutely does
not know how to handle).
So the quarterly full backups worked fine on the development machine
(VENTI2) which has the patch, but not on the production machine (TOMMYT)
which does not.? Pity, I had been up over 32 weeks and was only a little
short of 3,000 hours uptime.
------------------------------------------------------------------------
On 1/15/21 11:58 PM, Johnny Billquist wrote:
I saw that and wondered as well.
I was thinking maybe it could be for DDCMP devices without more
specifically defining what it would be, since DDCMP could be run over
any serial line?
? Johnny
> ------------------------------------------------------------------------
> On 2021-01-15 22:53, Peter Lothberg wrote:
>
> The 2020 has a KMC11 and up to 2 DUP11, and those are the interfaces
> the "MRC T20 DECnet thing supports.
>
> On the list of devices/sizes you posted is? a "DDP" device and I
> wounder if you knew what that is?
>
> --P
>> ------------------------------------------------------------------------
>> *From*: "tommytimesharing" <tommytimesharing at gmail.com>
>> *To*: "hecnet" <hecnet at Update.UU.SE>
>> *Sent*: *Friday, January 15, 2021 4:24:07 PM
>> *Subject*: *Re: [HECnet] Thousands of DECnet errors on Tops-20
>>
>> ??? DDP?? I thought it was DUP-11.
>>> ------------------------------------------------------------------------
>>>
>>> On 1/15/21 4:21 PM, Peter Lothberg wrote:
>>>
>>> Well, MRC was receiving "suggestions" from Stu Grossman on how to
>>> do it, but if my memory does not fail me the block size was 312,
>>> due to lack of buffer space in the already crammed single section
>>> 512KW 2020.? I'm afraid my tape and disk-pack are in Seattle.? I
>>> knew it was not 576 as it had two DUP-11's and using it for transit
>>> failed...
>>>
>>> Quiz, do you knew what a DDP is?
>>>
>>> -P
11:28 p.m.
A DDP device is a "DDCMP speaker on a ANF10 front end".
It's basically a 576 byte card punch/reader on the front end with corresponding
device on the T10 side. We used it on the KI to talk both DECnet-IV and IP (to
a BSD 4.3 vaxen with a DMR-11.) It was done as a hack by Robert Hauk, who
also put in ANF10 over Ethernet. (remmember the DECnet frontend for the DTE
was only phase 3).
Dept of useless knowledge..
-P
From: "tommytimesharing"
<tommytimesharing at gmail.com>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Sunday, January 17, 2021 5:10:08 PM
Subject: Re: [HECnet] Thousands of DECnet errors on Tops-20
The only serial lines that I saw DECnet running on
were synchronous connections.
The local connections between CU's 20's (before we got the CI's and NI's)
were
56K baud synchronous lines running on KMC11's, which we thought were pretty hot
stuff ...until... Non-data center connections (our chemistry VAX, CMU & CWR
20's) were asynchronous lines running 9.6K baud (on DUP11's, I think).
The PANDA monitor's Multinet code implements
serial IP (SLIP), which it will run
over an ordinary DL or DH based asynchronous lines. I didn't immediately see
anything similar for DECnet, but it is doubtful that MRC would have put that it
in; the code was supposed to run on a 2020, which has different IO drivers. If
his 2020 5.0 changes ever do surface, it may be conceivable that some of them
might be retrofitted into 7.1 (depends on what's applicable).
It is now possible that I will eventually figure out
what this mysterious DDP
device is. I reconfigured both 20's to have the largest buffer possible (
DECNET BUFFER-SIZE 1476 in SYSTEM:7-1-CONFIG.CMD , which I checked in the
running monitor), rebooted and ... I'm still getting the same frame too long
error, viz:
> ***********************************************
> DECNET ENTRY
> LOGGED ON 16-Jan-2021 01:29:38-EST MONITOR UPTIME WAS 0 day(s) 0:16:8
> DETECTED ON SYSTEM # 3691.
> RECORD SEQUENCE NUMBER: 35752.
> ***********************************************
> DECNET Event type 5.15, Receive failed
> From node 2.522 (VENTI2), occurred 16-JAN-2021 01:29:11
> Line NI-0-0
> Failure reason = Frame too long
> Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 08 0A
> ***********************************************
> DECNET ENTRY
> LOGGED ON 16-Jan-2021 01:29:38-EST MONITOR UPTIME WAS 0 day(s) 0:16:8
> DETECTED ON SYSTEM # 3691.
> RECORD SEQUENCE NUMBER: 35753.
> ***********************************************
> DECNET Event type 5.15, Receive failed
> From node 2.522 (VENTI2), occurred 16-JAN-2021 01:29:28
> Line NI-0-0
> Failure reason = Frame too long
> Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 FF 0B
************************************************************************
Darn it??
So now I've got some modifications to actually make to the monitor to
give some better error information (like the number of bytes overrun, if I can
extract it). So maybe I'll stumble over whatever DDP does. It's odd; I can't
think of any device that a pack of KL's could share except something like a
dual ported disk or magnetic tape drive and that's only two KL's. Meanwhile, I'll also do a tcpdump so I can try to
correlate what Tops-20 is
silently whining about with what's coming over the bridge.
Finally, something to beware of if you are running the
KLH10 micro-engine and
have a very large file that you're backing up (you're all running regular
backups, right ?) The amount of disk activity will somehow prevent KLH10's
front end timer from popping so, unless you are running my changes to DTESRV,
you're going to hang with a DTEKPA BUGINF . A quick hack is to deposit a -1
into FEDBSW , which will keep the 20 from trying to reboot the front end (which
KLH10 absolutely does not know how to handle).
So the quarterly full backups worked fine on the development machine (VENTI2)
which has the patch, but not on the production machine (TOMMYT) which does not.
Pity, I had been up over 32 weeks and was only a little short of 3,000 hours
uptime.
> On 1/15/21 11:58 PM, Johnny Billquist wrote:
> I saw that and wondered as well.
> I was thinking maybe it could be for DDCMP devices without more specifically
> defining what it would be, since DDCMP could be run over any serial line?
> Johnny
>> On 2021-01-15 22:53, Peter Lothberg wrote:
>> The 2020 has a KMC11 and up to 2 DUP11, and
those are the interfaces
>> the "MRC T20 DECnet thing supports.
>> On the list of devices/sizes you posted is a
"DDP" device and I wounder if you
>> knew what that is?
>> --P
>>> From : "tommytimesharing" [
mailto:tommytimesharing at gmail.com |
>>> <tommytimesharing at gmail.com> ]
>>> To : "hecnet" [ mailto:hecnet at Update.UU.SE | <hecnet at
Update.UU.SE> ]
>>> Sent : *Friday, January 15, 2021 4:24:07 PM
>>> Subject : *Re: [HECnet] Thousands of DECnet errors on Tops-20
>>> DDP? I thought it was DUP-11.
>>>> On 1/15/21 4:21 PM, Peter Lothberg
wrote:
>>>> Well, MRC was receiving
"suggestions" from Stu Grossman on how to do it, but if
>>>> my memory does not fail me the block size was 312, due to lack of buffer
space
>>>> in the already crammed single section 512KW 2020. I'm afraid my tape
and
>>>> disk-pack are in Seattle. I knew it was not 576 as it had two
DUP-11's and
>>>> using it for transit failed...
>>>> Quiz, do you knew what a DDP is?
>>>> -P
11:34 p.m.
On 2021-01-17 23:10, Thomas DeBellis wrote:
The only serial lines that I saw DECnet running on
were synchronous
connections.? The local connections between CU's 20's (before we got the
CI's and NI's) were 56K baud synchronous lines running on KMC11's, which
we thought were pretty hot stuff ...until...? Non-data center
connections (our chemistry VAX, CMU & CWR 20's) were asynchronous lines
running 9.6K baud (on DUP11's, I think).
Well, as noted, DDCMP exists both over synchronous and asynchronous
serial lines. And DDCMP did run over some other stuff as well.
The PANDA monitor's Multinet code implements
serial IP (SLIP), which it
will run over an ordinary DL or DH based asynchronous lines.? I didn't
immediately see anything similar for DECnet, but it is doubtful that MRC
would have put that it in; the code was supposed to run on a 2020, which
has different IO drivers.? If his 2020 5.0 changes ever do surface, it
may be conceivable that some of them might be retrofitted into 7.1
(depends on what's applicable).
Ok. Yeah my thinking was the equivalent of SLIP. It exists primarily in
VMS, where you can (if I remember right) even turn on DDCMP on a line
where you just logged in, which would be the thing on a dial up line.
RSX is a little more static in that serial lines using DDCMP have to be
configured in advance, and then cannot be used for normal terminal action.
It is now possible that I will eventually figure out
what this
mysterious DDP device is.? I reconfigured both 20's to have the largest
buffer possible (DECNET BUFFER-SIZE 1476 in SYSTEM:7-1-CONFIG.CMD, which
I checked in the running monitor), rebooted /and/ ... I'm still getting
the same frame too long error, viz:
***********************************************
DECNET ENTRY
?LOGGED ON 16-Jan-2021 01:29:38-EST????? MONITOR UPTIME WAS 0
day(s) 0:16:8
??????? DETECTED ON SYSTEM # 3691.
??????? RECORD SEQUENCE NUMBER: 35752.
***********************************************
DECNET Event type 5.15, Receive failed
From node 2.522 (VENTI2), occurred 16-JAN-2021 01:29:11
? Line NI-0-0
? Failure reason = Frame too long
? Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 08 0A
***********************************************
DECNET ENTRY
?LOGGED ON 16-Jan-2021 01:29:38-EST????? MONITOR UPTIME WAS 0
day(s) 0:16:8
??????? DETECTED ON SYSTEM # 3691.
??????? RECORD SEQUENCE NUMBER: 35753.
***********************************************
DECNET Event type 5.15, Receive failed
From node 2.522 (VENTI2), occurred 16-JAN-2021 01:29:28
? Line NI-0-0
? Failure reason = Frame too long
? Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 FF 0B
************************************************************************
Darn it??? So now I've got some modifications to actually make to the
monitor to give some better error information (like the number of bytes
overrun, if I can extract it).? So maybe I'll stumble over whatever DDP
does.? It's odd; I can't think of any device that a pack of KL's could
share except something like a dual ported disk or magnetic tape drive
and that's only two KL's.
Definitely interested in what size we are talking about here, but I am
sortof suspecting you are getting 1500 byte frames, and it sounded like
the code you looked at suggested the maximum frame size to be slightly
short of this.
As for DDP, it's totally unrelated to this, so how about playing with
that another day?
Also not sure why you think it would be shared from a hardware perspective.
Meanwhile, I'll also do a tcpdump so I can try to
correlate what Tops-20
is silently whining about with what's coming over the bridge.
Would be a bit interesting, yes.
Finally, something to beware of if you are running the
KLH10
micro-engine and have a very large file that you're backing up (you're
all running regular backups, /right/?)? The amount of disk activity will
somehow prevent KLH10's front end timer from popping so, unless you are
running my changes to DTESRV, you're going to /hang/ with a DTEKPA
BUGINF.? A quick hack is to deposit a -1 into FEDBSW, which will keep
the 20 from trying to reboot the front end (which KLH10 absolutely does
not know how to handle).
So the quarterly full backups worked fine on the development machine
(VENTI2) which has the patch, but not on the production machine (TOMMYT)
which does not.? Pity, I had been up over 32 weeks and was only a little
short of 3,000 hours uptime.
Ouch. :-(
Johnny
>
------------------------------------------------------------------------
> On 1/15/21 11:58 PM, Johnny Billquist wrote:
>
> I saw that and wondered as well.
> I was thinking maybe it could be for DDCMP devices without more
> specifically defining what it would be, since DDCMP could be run over
> any serial line?
>
> ? Johnny
>> ------------------------------------------------------------------------
>> On 2021-01-15 22:53, Peter Lothberg wrote:
>>
>> The 2020 has a KMC11 and up to 2 DUP11, and those are the interfaces
>> the "MRC T20 DECnet thing supports.
>>
>> On the list of devices/sizes you posted is? a "DDP" device and I
>> wounder if you knew what that is?
>>
>> --P
>>> ------------------------------------------------------------------------
>>> *From*: "tommytimesharing" <tommytimesharing at gmail.com>
>>> *To*: "hecnet" <hecnet at Update.UU.SE>
>>> *Sent*: *Friday, January 15, 2021 4:24:07 PM
>>> *Subject*: *Re: [HECnet] Thousands of DECnet errors on Tops-20
>>>
>>> ??? DDP?? I thought it was DUP-11.
>>>> ------------------------------------------------------------------------
>>>>
>>>> On 1/15/21 4:21 PM, Peter Lothberg wrote:
>>>>
>>>> Well, MRC was receiving "suggestions" from Stu Grossman on how
to
>>>> do it, but if my memory does not fail me the block size was 312,
>>>> due to lack of buffer space in the already crammed single section
>>>> 512KW 2020.? I'm afraid my tape and disk-pack are in Seattle.? I
>>>> knew it was not 576 as it had two DUP-11's and using it for transit
>>>> failed...
>>>>
>>>> Quiz, do you knew what a DDP is?
>>>>
>>>> -P
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
18 Jan
18 Jan
12:17 a.m.
Well, the frames certainly won't be larger than 1,500 bytes, right?? So
I'm guessing they'll be the maximum.? Problem is, all of that stuff is
hidden under several layers of drivers, so I'm not sure how I'm going to
get the overage passed back.? And I also need to put in some BUGINF
logic to alert if I get more of these than whatever I decide the
interval to be.
About DDP 'sharing'; it is not quite like that.? Late in the product
cycle, DEC updated Tops-10 to handle symmetric multi-processing where
all processors could do I/O.? Previous versions of Tops-10 had a single
master processor, which handled processing and _all_ of the I/O and
slave processors (I think up to five) which would just handle
computation.? If you had to do I/O you had to wait to run on the master.
Aside from excessively loading the master processor, you could only buy
as many peripherals as a single-KL could handle.? With SMP, you can plug
the peripheral in pretty much anywhere and it will work no matter what
processor is doing I/O.? The decision is straightforward; if you're
doing I/O and the processor you are running has the device (dual ported
or not), then you proceed.? If the processor can not access the device
on the I/O, bus then the request is queued for the processor that does.
Except...
In ROUTER.MAC under the Tops-10 conditional at CALKON+2, one finds the
following
LOAD T4,LIDEV,+RC.LID(RC) ;GET THE DEVICE TYPE
CAIN T4,LD.DDP??????????? ;IS IT NOT CPU-DEPENDANT?
JRST CALKO5?????????????? ; NOT CPU DEPENDANT, GO AHEAD AND DO IT.
LOAD T4,LIKON,+RC.LID(RC) ;GET THE CPU NUMBER OF THE CIRCUIT
CAMN T4,.CPCPN??????????? ;ARE WE ON THAT CPU NOW?
JRST CALKO5?????????????? ; YES
If you are a DDP (LD.DDP), then you are not CPU dependent and you go
ahead always, otherwise, you have to be on the CPU that owns the device
(.CPCPN) So I'm not sure if it makes any difference, but DDP is not CPU
dependent; not sure if that is a synonym for 'shared'.? If I stumble
over something more, I'll report it.
I'll find out about tcpdump later tonight.
------------------------------------------------------------------------
On 1/17/21 5:34 PM, Johnny Billquist wrote:
------------------------------------------------------------------------
On 2021-01-17 23:10, Thomas DeBellis wrote:
Darn it??? So now I've got some modifications to actually make to the
monitor to give some better error information (like the number of
bytes overrun, if I can extract it).? So maybe I'll stumble over
whatever DDP does.? It's odd; I can't think of any device that a pack
of KL's could share except something like a dual ported disk or
magnetic tape drive and that's only two KL's.
Definitely interested in what size we are talking about here, but I am
sort of suspecting you are getting 1500 byte frames, and it sounded
like the code you looked at suggested the maximum frame size to be
slightly short of this.
As for DDP, it's totally unrelated to this, so how about playing with
that another day?
Also not sure why you think it would be shared from a hardware
perspective.
Meanwhile, I'll also do a tcpdump so I can
try to correlate what
Tops-20 is silently whining about with what's coming over the bridge.
Would be a bit interesting, yes.
1:39 a.m.
On 2021-01-18 00:17, Thomas DeBellis wrote:
Well, the frames certainly won't be larger than
1,500 bytes, right?? So
I'm guessing they'll be the maximum.? Problem is, all of that stuff is
hidden under several layers of drivers, so I'm not sure how I'm going to
get the overage passed back.? And I also need to put in some BUGINF
logic to alert if I get more of these than whatever I decide the
interval to be.
That depends on what they count. Like I said - ethernet payload is 1500.
Then you have the ethernet headers which is 14 bytes, plus the crc
trailer, which is 4 bytes. If you count them, you end up at 1518 bytes.
Depends on the hardware I guess.
I have no idea what the NIA-20 expose.
About DDP 'sharing'; it is not quite like
that.? Late in the product
cycle, DEC updated Tops-10 to handle symmetric multi-processing where
all processors could do I/O.? Previous versions of Tops-10 had a single
master processor, which handled processing and _all_ of the I/O and
slave processors (I think up to five) which would just handle
computation.? If you had to do I/O you had to wait to run on the master.
Aside from excessively loading the master processor, you could only buy
as many peripherals as a single-KL could handle.? With SMP, you can plug
the peripheral in pretty much anywhere and it will work no matter what
processor is doing I/O.? The decision is straightforward; if you're
doing I/O and the processor you are running has the device (dual ported
or not), then you proceed.? If the processor can not access the device
on the I/O, bus then the request is queued for the processor that does.
Right. Pretty much how it works on any system. Even ASMP is like that,
except you cannot (are not allowed) to hook any peripherals to the slave
processors.
Except...
In ROUTER.MAC under the Tops-10 conditional at CALKON+2, one finds the
following
LOAD T4,LIDEV,+RC.LID(RC) ;GET THE DEVICE TYPE
CAIN T4,LD.DDP??????????? ;IS IT NOT CPU-DEPENDANT?
JRST CALKO5?????????????? ; NOT CPU DEPENDANT, GO AHEAD AND DO IT.
LOAD T4,LIKON,+RC.LID(RC) ;GET THE CPU NUMBER OF THE CIRCUIT
CAMN T4,.CPCPN??????????? ;ARE WE ON THAT CPU NOW?
JRST CALKO5?????????????? ; YES
If you are a DDP (LD.DDP), then you are not CPU dependent and you go
ahead always, otherwise, you have to be on the CPU that owns the device
(.CPCPN) So I'm not sure if it makes any difference, but DDP is not CPU
dependent; not sure if that is a synonym for 'shared'.? If I stumble
over something more, I'll report it.
Oh. I think that is sortof clear. DDCMP is not hardware in the first
place, so the processing can happen on any CPU. It's only when the bytes
actually need to go in or out that you then need to route it to a
processor that actually have the serial port.
It's actually the same in RSX. The DDCMP layer is sortof between the
hardware driver and the higher level protocols, and it's not tied to any
specific CPU.
But that code would suggest that LD.DDP is just an indication of whether
something is CPU dependent or not, and would have anything to do with DDCMP.
I'll find out about tcpdump later tonight.
Great.
Johnny
> ------------------------------------------------------------------------
> On 1/17/21 5:34 PM, Johnny Billquist wrote:
>> ------------------------------------------------------------------------
>> On 2021-01-17 23:10, Thomas DeBellis wrote:
>>
>> Darn it??? So now I've got some modifications to actually make to the
>> monitor to give some better error information (like the number of
>> bytes overrun, if I can extract it).? So maybe I'll stumble over
>> whatever DDP does.? It's odd; I can't think of any device that a pack
>> of KL's could share except something like a dual ported disk or
>> magnetic tape drive and that's only two KL's.
>
> Definitely interested in what size we are talking about here, but I am
> sort of suspecting you are getting 1500 byte frames, and it sounded
> like the code you looked at suggested the maximum frame size to be
> slightly short of this.
>
> As for DDP, it's totally unrelated to this, so how about playing with
> that another day?
>
> Also not sure why you think it would be shared from a hardware
> perspective.
>> Meanwhile, I'll also do a tcpdump so I can try to correlate what
>> Tops-20 is silently whining about with what's coming over the bridge.
>
> Would be a bit interesting, yes.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
4:45 a.m.
I think I may have finally gotten to the bottom of this.? It's a level 1
routing message that I'm getting from 2.1023 (A2RTR) that does not
appear to be respecting lengths, viz:
*22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN
(0x6003), length *1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0 hops 0
This is two (2) bytes over the maximum that Tops-20 can accept.
NCP>*SHOW LINE NI-0 CHARACTERISTICS *
NCP>
22:16:04 ??? NCP
Request # 23; Show Line Characteristics Completed
Line = NI-0
? Receive Buffers = 6
? Controller = Normal
? Protocol = Ethernet
? Hardware Address = 00 1F 16 EC CE 47
? Receive buffer size = *1476*
It would appear that the 20's are advertising this length in their layer
1 hello messages:
22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.522
blksize *1476* pri 5 hello 15
22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.520
blksize *1476* pri 5 hello 15
About two seconds after the message comes in from A2RTR, the following
appears in the error log:
***********************************************
DECNET ENTRY
?LOGGED ON 17-Jan-2021 *22:04:32*-EST MONITOR UPTIME WAS 1 day(s)
1:17:54
??????? DETECTED ON SYSTEM # 3691.
??????? RECORD SEQUENCE NUMBER: 70952.
***********************************************
DECNET Event type 5.15, Receive failed
From node 2.520 (TOMMYT), occurred 17-JAN-2021 22:04:08
? Line NI-0-0
? Failure reason = Frame too long
? Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 0A 0A
So... no way I can get around this without some /serious/ hacking of
DNADLL and ROUTER (see below), which would probably take me a few months
to learn and debug.? Of course, then maybe I could put level 2 routing
into Tops-20, which I been daydreaming about...
Paul, what does this suggest to you?
From looking at the routing code, seems LD.DDP is used when
something
is getting handed to the NSP to play with, I guess that would be goig
through some kind of layering.
------------------------------------------------------------------------
On 1/17/21 7:39 PM, Johnny Billquist wrote:
I meant the maximum frame size; I suspect this is 1500 for the NI, but I
don't actually know.? My speculation is that DECnet is using part of the
buffer to piggy back node and and other information into it instead of
holding this meta-data, separately.? I don't know what Multinet does,
but there you can configure the NI to have a packet size of 1500.
------------------------------------------------------------------------
On 2021-01-18 00:17, Thomas DeBellis wrote:
Well, the frames certainly won't be larger than 1,500 bytes, right??
So I'm guessing they'll be the maximum.? Problem is, all of that
stuff is hidden under several layers of drivers, so I'm not sure how
I'm going to get the overage passed back.? And I also need to put in
some BUGINF logic to alert if I get more of these than whatever I
decide the interval to be.
That depends on what they count. Like I said - ethernet
payload is
1500. Then you have the ethernet headers which is 14 bytes, plus the
crc trailer, which is 4 bytes. If you count them, you end up at 1518
bytes.
Depends on the hardware I guess.?? I have no idea what the NIA-20 expose. If you are a
DDP (LD.DDP), then you are not CPU dependent and you go
ahead always, otherwise, you have to be on the CPU that owns the
device (.CPCPN) So I'm not sure if it makes any difference, but DDP
is not CPU dependent; not sure if that is a synonym for 'shared'.? If
I stumble over something more, I'll report it.
It's actually the same in
RSX. The DDCMP layer is sort of between the
hardware driver and the higher level protocols, and it's not tied to
any specific CPU.
But that code would suggest that LD.DDP is just an indication of
whether something is CPU dependent or not, and would have anything to
do with DDCMP.
7:54 a.m.
Thomas, this is pretty much exactly what I expected (and I suspect Paul
expected as well).
The level 1 routing messages are (as we said) the ones that can grow
big. And the advertised length are not used by the other side to limit
what they send. It essentially hints how large messages you send.
And Paul also noted that on ethernet the Python code is using larger
buffer size (essentially the size an ethernet frame can be) instead of
putting any lower limit on it. While this is perfectly legal from a
protocol point of view, both TOPS-20 and VMS, it would seem, can't
really control the size of the low layer buffer, and therefore fails if
you use large packets without also having a large DECnet segment buffer
size.
So Paul's PyDECnet works the same as I have managed to have RSX work
here. And you get the same problem towards some OSes.
The obvious, and easy fix is to just lower the buffer size used over
ethernet to more closely match what the DECnet segment buffer size is.
The sad thing with that is that, at least for RSX, it means you run the
risk of hanging the ethernet when running TCP/IP. The best would be if
all OSes could separate the two buffer sizes properly.
But I just realized that I might just hack RSX DECnet here, to not use
the large buffer size for the link messages... Hmm... Gotta look into this.
Meanwhile, the fix that Paul already mentioned that he has prepared and
ready should fix this for you.
Alternatively, if you change that 1504-%RTEHS to instead actually say
something like 1500, or 1504, you should probably also be good. (My
guess would be 1500.)
Johnny
On 2021-01-18 04:45, Thomas DeBellis wrote:
I think I may have finally gotten to the bottom of
this.? It's a level 1
routing message that I'm getting from 2.1023 (A2RTR) that does not
appear to be respecting lengths, viz:
*22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN
(0x6003), length *1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0 hops 0
This is two (2) bytes over the maximum that Tops-20 can accept.
NCP>*SHOW LINE NI-0 CHARACTERISTICS *
NCP>
22:16:04 ??? NCP
Request # 23; Show Line Characteristics Completed
Line = NI-0
? Receive Buffers = 6
? Controller = Normal
? Protocol = Ethernet
? Hardware Address = 00 1F 16 EC CE 47
? Receive buffer size = *1476*
It would appear that the 20's are advertising this length in their layer
1 hello messages:
22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.522
blksize *1476* pri 5 hello 15
22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.520
blksize *1476* pri 5 hello 15
About two seconds after the message comes in from A2RTR, the following
appears in the error log:
***********************************************
DECNET ENTRY
?LOGGED ON 17-Jan-2021 *22:04:32*-EST MONITOR UPTIME WAS 1 day(s)
1:17:54
??????? DETECTED ON SYSTEM # 3691.
??????? RECORD SEQUENCE NUMBER: 70952.
***********************************************
DECNET Event type 5.15, Receive failed
From node 2.520 (TOMMYT), occurred 17-JAN-2021 22:04:08
? Line NI-0-0
? Failure reason = Frame too long
? Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 0A 0A
So... no way I can get around this without some /serious/ hacking of
DNADLL and ROUTER (see below), which would probably take me a few months
to learn and debug.? Of course, then maybe I could put level 2 routing
into Tops-20, which I been daydreaming about...
Paul, what does this suggest to you?
From looking at the routing code, seems LD.DDP is used when
something
is getting handed to the NSP to play with, I guess that would be goig
through some kind of layering.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
------------------------------------------------------------------------
On 1/17/21 7:39 PM, Johnny Billquist wrote:
I meant the maximum frame size; I suspect this is 1500 for the NI, but I
don't actually know.? My speculation is that DECnet is using part of the
buffer to piggy back node and and other information into it instead of
holding this meta-data, separately.? I don't know what Multinet does,
but there you can configure the NI to have a packet size of 1500.
------------------------------------------------------------------------
On 2021-01-18 00:17, Thomas DeBellis wrote:
Well, the frames certainly won't be larger than 1,500 bytes, right?
So I'm guessing they'll be the maximum.? Problem is, all of that
stuff is hidden under several layers of drivers, so I'm not sure how
I'm going to get the overage passed back.? And I also need to put in
some BUGINF logic to alert if I get more of these than whatever I
decide the interval to be.
That depends on what they count. Like I said - ethernet
payload is
1500. Then you have the ethernet headers which is 14 bytes, plus the
crc trailer, which is 4 bytes. If you count them, you end up at 1518
bytes.
Depends on the hardware I guess.?? I have no idea what the NIA-20 expose. If you
are a DDP (LD.DDP), then you are not CPU dependent and you go
ahead always, otherwise, you have to be on the CPU that owns the
device (.CPCPN) So I'm not sure if it makes any difference, but DDP
is not CPU dependent; not sure if that is a synonym for 'shared'.? If
I stumble over something more, I'll report it.
It's actually the same in
RSX. The DDCMP layer is sort of between the
hardware driver and the higher level protocols, and it's not tied to
any specific CPU.
But that code would suggest that LD.DDP is just an indication of
whether something is CPU dependent or not, and would have anything to
do with DDCMP.
6:39 p.m.
No, 1478 doesn't make any sense.
Looking at my code, I use a local buffer size on Ethernet of 591. But then I track what
buffer sizes are reported by the router neighbors in their hello messages, and limit the
routing message size to the smallest of all these numbers.
Then I noticed I subtract 16 from that when calculating the size of the update messages.
Why that is I don't remember.
So in any case, 1478 should never be a routing protocol message size coming out of
PyDECnet.
I'd like to see messages traces. A trace level log from A2RTR would do the job.
Somthing is very strange here.
paul
On Jan 18, 2021, at 1:54 AM, Johnny Billquist <bqt
at softjar.se> wrote:
Thomas, this is pretty much exactly what I expected (and I suspect Paul expected as
well).
The level 1 routing messages are (as we said) the ones that can grow big. And the
advertised length are not used by the other side to limit what they send. It essentially
hints how large messages you send.
And Paul also noted that on ethernet the Python code is using larger buffer size
(essentially the size an ethernet frame can be) instead of putting any lower limit on it.
While this is perfectly legal from a protocol point of view, both TOPS-20 and VMS, it
would seem, can't really control the size of the low layer buffer, and therefore fails
if you use large packets without also having a large DECnet segment buffer size.
So Paul's PyDECnet works the same as I have managed to have RSX work here. And you
get the same problem towards some OSes.
The obvious, and easy fix is to just lower the buffer size used over ethernet to more
closely match what the DECnet segment buffer size is.
The sad thing with that is that, at least for RSX, it means you run the risk of hanging
the ethernet when running TCP/IP. The best would be if all OSes could separate the two
buffer sizes properly.
But I just realized that I might just hack RSX DECnet here, to not use the large buffer
size for the link messages... Hmm... Gotta look into this.
Meanwhile, the fix that Paul already mentioned that he has prepared and ready should fix
this for you.
Alternatively, if you change that 1504-%RTEHS to instead actually say something like
1500, or 1504, you should probably also be good. (My guess would be 1500.)
Johnny
On 2021-01-18 04:45, Thomas DeBellis wrote:
I think I may have finally gotten to the bottom
of this. It's a level 1 routing message that I'm getting from 2.1023 (A2RTR) that
does not appear to be respecting lengths, viz:
*22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN (0x6003), length
*1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0 hops 0
This is two (2) bytes over the maximum that Tops-20 can accept.
NCP>*SHOW LINE NI-0 CHARACTERISTICS *
NCP>
22:16:04 NCP
Request # 23; Show Line Characteristics Completed
Line = NI-0
Receive Buffers = 6
Controller = Normal
Protocol = Ethernet
Hardware Address = 00 1F 16 EC CE 47
Receive buffer size = *1476*
It would appear that the 20's are advertising this length in their layer 1 hello
messages:
22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN (0x6003), length
60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.522 blksize *1476* pri 5 hello 15
22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN (0x6003), length
60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.520 blksize *1476* pri 5 hello 15
About two seconds after the message comes in from A2RTR, the following appears in the
error log:
***********************************************
DECNET ENTRY
LOGGED ON 17-Jan-2021 *22:04:32*-EST MONITOR UPTIME WAS 1 day(s)
1:17:54
DETECTED ON SYSTEM # 3691.
RECORD SEQUENCE NUMBER: 70952.
***********************************************
DECNET Event type 5.15, Receive failed
From node 2.520 (TOMMYT), occurred 17-JAN-2021 22:04:08
Line NI-0-0
Failure reason = Frame too long
Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 0A 0A
So... no way I can get around this without some /serious/ hacking of DNADLL and ROUTER
(see below), which would probably take me a few months to learn and debug. Of course,
then maybe I could put level 2 routing into Tops-20, which I been daydreaming about...
Paul, what does this suggest to you?
From looking at the
routing code, seems LD.DDP is used when something is getting handed to the NSP to play
with, I guess that would be goig through some kind of layering.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
------------------------------------------------------------------------
On 1/17/21 7:39 PM, Johnny Billquist wrote:
I meant
the maximum frame size; I suspect this is 1500 for the NI, but I don't actually know.
My speculation is that DECnet is using part of the buffer to piggy back node and and other
information into it instead of holding this meta-data, separately. I don't know what
Multinet does, but there you can configure the NI to have a packet size of 1500.
------------------------------------------------------------------------
On 2021-01-18 00:17, Thomas DeBellis wrote:
Well, the frames certainly won't be larger than 1,500 bytes, right? So I'm
guessing they'll be the maximum. Problem is, all of that stuff is hidden under
several layers of drivers, so I'm not sure how I'm going to get the overage passed
back. And I also need to put in some BUGINF logic to alert if I get more of these than
whatever I decide the interval to be.
That depends on what they count. Like I said
- ethernet payload is 1500. Then you have the ethernet headers which is 14 bytes, plus the
crc trailer, which is 4 bytes. If you count them, you end up at 1518 bytes.
Depends on the hardware I guess. I have no idea what the NIA-20 expose. If you
are a DDP (LD.DDP), then you are not CPU dependent and you go ahead always, otherwise, you
have to be on the CPU that owns the device (.CPCPN) So I'm not sure if it makes any
difference, but DDP is not CPU dependent; not sure if that is a synonym for
'shared'. If I stumble over something more, I'll report it.
It's
actually the same in RSX. The DDCMP layer is sort of between the hardware driver and the
higher level protocols, and it's not tied to any specific CPU.
But that code would suggest that LD.DDP is just an indication of whether something is CPU
dependent or not, and would have anything to do with DDCMP.
8:26 p.m.
16 bytes??? Some kind of internal header?? I'm not sure I fully
understand what Tops-20 is doing with the buffer; I'll have to
investigate further to see whether my suspicion about the use of
meta-data at the beginning.
Would it help to see more of the messages that I grabbed with tcpdump??
I did a tcpdump -e -i en0 --immediate-mode -n decnet and have about 92K
of traffic that I could send off-list.? I'll let Bob get you traces.
When fixing this, could you put in some kind of configuration command to
change the fixed behavior back to the current?? I might need this when
chasing down my suspicion, above.
This is probably happening to _all_ 20's on HECnet that are getting
messages from PyDECnet.? I'm checking further into my logs, which has
been tedious.? Beyond the DTEKPA crashes, the size of the error log can
cause SPEAR to trigger a problem with PA1050; you get an Illegal
reference to address 301000 at user 547217. And the extracts are so huge
that not even the Tops-20 gnuemacs can hold them.? You have to transfer
them to some other system. If you're not running my Extended mode FTP
server, that will take days.
I only have access to one (TWENEX::), but when I checked, its
SERR:ERROR.SYS file was over 70K pages, which is what you'd expect.? I
didn't have time yesterday to run SPEAR to actually pull and now I can't
seem to get to it. TWENEX::'s DECnet configuration does not appear to be
up to date.? When I looked at available DECnet nodes, it didn't know
any.? It also didn't know what node my CTERM was coming in on.
Does anybody have a Tops-20 node that is talking to PyDECnet that can
either check or give me a guest account?? It would be instructive to
double check.
------------------------------------------------------------------------
On 1/18/21 12:39 PM, Paul Koning wrote:
No, 1478 doesn't make any sense.
Looking at my code, I use a local buffer size on Ethernet of 591. But then I track what
buffer sizes are reported by the router neighbors in their hello messages, and limit the
routing message size to the smallest of all these numbers.
Then I noticed I subtract 16 from that when calculating the size of the update messages.
Why that is I don't remember.
So in any case, 1478 should never be a routing protocol message size coming out of
PyDECnet.
I'd like to see messages traces. A trace level log from A2RTR would do the job.
Somthing is very strange here.
paul
> ------------------------------------------------------------------------
> On Jan 18, 2021, at 1:54 AM, Johnny Billquist <bqt at softjar.se> wrote:
>
> Thomas, this is pretty much exactly what I expected (and I suspect Paul expected as
well).
>
> The level 1 routing messages are (as we said) the ones that can grow big. And the
advertised length are not used by the other side to limit what they send. It essentially
hints how large messages you send.
>
> And Paul also noted that on ethernet the Python code is using larger buffer size
(essentially the size an ethernet frame can be) instead of putting any lower limit on it.
While this is perfectly legal from a protocol point of view, both TOPS-20 and VMS, it
would seem, can't really control the size of the low layer buffer, and therefore fails
if you use large packets without also having a large DECnet segment buffer size.
>
> So Paul's PyDECnet works the same as I have managed to have RSX work here. And
you get the same problem towards some OSes.
>
> The obvious, and easy fix is to just lower the buffer size used over ethernet to more
closely match what the DECnet segment buffer size is.
>
> The sad thing with that is that, at least for RSX, it means you run the risk of
hanging the ethernet when running TCP/IP. The best would be if all OSes could separate the
two buffer sizes properly.
> But I just realized that I might just hack RSX DECnet here, to not use the large
buffer size for the link messages... Hmm... Gotta look into this.
>
> Meanwhile, the fix that Paul already mentioned that he has prepared and ready should
fix this for you.
>
> Alternatively, if you change that 1504-%RTEHS to instead actually say something like
1500, or 1504, you should probably also be good. (My guess would be 1500.)
>
> Johnny
>
> ------------------------------------------------------------------------
> On 2021-01-18 04:45, Thomas DeBellis wrote:
>> I think I may have finally gotten to the bottom of this. It's a level 1
routing message that I'm getting from 2.1023 (A2RTR) that does not appear to be
respecting lengths, viz:
>> *22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN
(0x6003), length *1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0 hops 0
>> This is two (2) bytes over the maximum that Tops-20 can accept.
>> NCP>*SHOW LINE NI-0 CHARACTERISTICS *
>> NCP>
>> 22:16:04 NCP
>> Request # 23; Show Line Characteristics Completed
>> Line = NI-0
>> Receive Buffers = 6
>> Controller = Normal
>> Protocol = Ethernet
>> Hardware Address = 00 1F 16 EC CE 47
>> Receive buffer size = *1476*
>> It would appear that the 20's are advertising this length in their layer 1
hello messages:
>> 22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN (0x6003),
length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.522 blksize *1476* pri 5 hello
15
>> 22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN (0x6003),
length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.520 blksize *1476* pri 5 hello
15
>> About two seconds after the message comes in from A2RTR, the following appears in
the error log:
>> ***********************************************
>> DECNET ENTRY
>> LOGGED ON 17-Jan-2021 *22:04:32*-EST MONITOR UPTIME WAS 1 day(s)
>> 1:17:54
>> DETECTED ON SYSTEM # 3691.
>> RECORD SEQUENCE NUMBER: 70952.
>> ***********************************************
>> DECNET Event type 5.15, Receive failed
>> From node 2.520 (TOMMYT), occurred 17-JAN-2021 22:04:08
>> Line NI-0-0
>> Failure reason = Frame too long
>> Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 0A 0A
>> So... no way I can get around this without some /serious/ hacking of DNADLL and
ROUTER (see below), which would probably take me a few months to learn and debug. Of
course, then maybe I could put level 2 routing into Tops-20, which I been daydreaming
about...
>> Paul, what does this suggest to you?
>>> ------------------------------------------------------------------------
>>> On 1/17/21 7:39 PM, Johnny Billquist wrote:
>>>> ------------------------------------------------------------------------
>>>> On 2021-01-18 00:17, Thomas DeBellis wrote:
>>>>
>>>> Well, the frames certainly won't be larger than 1,500 bytes, right?
So I'm guessing they'll be the maximum. Problem is, all of that stuff is hidden
under several layers of drivers, so I'm not sure how I'm going to get the overage
passed back. And I also need to put in some BUGINF logic to alert if I get more of these
than whatever I decide the interval to be.
>>> That depends on what they count. Like I said - ethernet payload is 1500. Then
you have the ethernet headers which is 14 bytes, plus the crc trailer, which is 4 bytes.
If you count them, you end up at 1518 bytes.
>>> Depends on the hardware I guess. I have no idea what the NIA-20 expose.
>> I meant the maximum frame size; I suspect this is 1500 for the NI, but I
don't actually know. My speculation is that DECnet is using part of the buffer to
piggy back node and and other information into it instead of holding this meta-data,
separately. I don't know what Multinet does, but there you can configure the NI to
have a packet size of 1500.
>>>> If you are a DDP (LD.DDP), then you are not CPU dependent and you go
ahead always, otherwise, you have to be on the CPU that owns the device (.CPCPN) So
I'm not sure if it makes any difference, but DDP is not CPU dependent; not sure if
that is a synonym for 'shared'. If I stumble over something more, I'll report
it.
>>> It's actually the same in RSX. The DDCMP layer is sort of between the
hardware driver and the higher level protocols, and it's not tied to any specific
CPU.
>>>
>>> But that code would suggest that LD.DDP is just an indication of whether
something is CPU dependent or not, and would have anything to do with DDCMP.
>> From looking at the routing code, seems LD.DDP is used when something is getting
handed to the NSP to play with, I guess that would be goig through some kind of layering.
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt at softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
10:11 p.m.
Hmm. The 1478 in itself I didn't think about. That's another interesting
question here. How come PyDECnet sends packets of that size to start with...
Well, you know that code better than anyone else Paul. I think this
might be interesting. :-)
Just a small observation: A2RTR do have a connection to MIM, and MIM is
using 1500 byte buffer size, which means even over Multinet links.
But of course, no packets will ever have that size, since there won't be
any L1 Hello packets there.
But it's a size passed over. Just in case that might matter...
Johnny
On 2021-01-18 18:39, Paul Koning wrote:
No, 1478 doesn't make any sense.
Looking at my code, I use a local buffer size on Ethernet of 591. But then I track what
buffer sizes are reported by the router neighbors in their hello messages, and limit the
routing message size to the smallest of all these numbers.
Then I noticed I subtract 16 from that when calculating the size of the update messages.
Why that is I don't remember.
So in any case, 1478 should never be a routing protocol message size coming out of
PyDECnet.
I'd like to see messages traces. A trace level log from A2RTR would do the job.
Somthing is very strange here.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 18, 2021, at 1:54 AM, Johnny Billquist
<bqt at softjar.se> wrote:
Thomas, this is pretty much exactly what I expected (and I suspect Paul expected as
well).
The level 1 routing messages are (as we said) the ones that can grow big. And the
advertised length are not used by the other side to limit what they send. It essentially
hints how large messages you send.
And Paul also noted that on ethernet the Python code is using larger buffer size
(essentially the size an ethernet frame can be) instead of putting any lower limit on it.
While this is perfectly legal from a protocol point of view, both TOPS-20 and VMS, it
would seem, can't really control the size of the low layer buffer, and therefore fails
if you use large packets without also having a large DECnet segment buffer size.
So Paul's PyDECnet works the same as I have managed to have RSX work here. And you
get the same problem towards some OSes.
The obvious, and easy fix is to just lower the buffer size used over ethernet to more
closely match what the DECnet segment buffer size is.
The sad thing with that is that, at least for RSX, it means you run the risk of hanging
the ethernet when running TCP/IP. The best would be if all OSes could separate the two
buffer sizes properly.
But I just realized that I might just hack RSX DECnet here, to not use the large buffer
size for the link messages... Hmm... Gotta look into this.
Meanwhile, the fix that Paul already mentioned that he has prepared and ready should fix
this for you.
Alternatively, if you change that 1504-%RTEHS to instead actually say something like
1500, or 1504, you should probably also be good. (My guess would be 1500.)
Johnny
On 2021-01-18 04:45, Thomas DeBellis wrote:
I think I may have finally gotten to the bottom
of this. It's a level 1 routing message that I'm getting from 2.1023 (A2RTR) that
does not appear to be respecting lengths, viz:
*22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN (0x6003), length
*1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0 hops 0
This is two (2) bytes over the maximum that Tops-20 can accept.
NCP>*SHOW LINE NI-0 CHARACTERISTICS *
NCP>
22:16:04 NCP
Request # 23; Show Line Characteristics Completed
Line = NI-0
Receive Buffers = 6
Controller = Normal
Protocol = Ethernet
Hardware Address = 00 1F 16 EC CE 47
Receive buffer size = *1476*
It would appear that the 20's are advertising this length in their layer 1 hello
messages:
22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN (0x6003), length
60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.522 blksize *1476* pri 5 hello 15
22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN (0x6003), length
60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.520 blksize *1476* pri 5 hello 15
About two seconds after the message comes in from A2RTR, the following appears in the
error log:
***********************************************
DECNET ENTRY
LOGGED ON 17-Jan-2021 *22:04:32*-EST MONITOR UPTIME WAS 1 day(s)
1:17:54
DETECTED ON SYSTEM # 3691.
RECORD SEQUENCE NUMBER: 70952.
***********************************************
DECNET Event type 5.15, Receive failed
From node 2.520 (TOMMYT), occurred 17-JAN-2021 22:04:08
Line NI-0-0
Failure reason = Frame too long
Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 0A 0A
So... no way I can get around this without some /serious/ hacking of DNADLL and ROUTER
(see below), which would probably take me a few months to learn and debug. Of course,
then maybe I could put level 2 routing into Tops-20, which I been daydreaming about...
Paul, what does this suggest to you?
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
------------------------------------------------------------------------
On 1/17/21 7:39 PM, Johnny Billquist wrote:
> ------------------------------------------------------------------------
> On 2021-01-18 00:17, Thomas DeBellis wrote:
>
> Well, the frames certainly won't be larger than 1,500 bytes, right? So I'm
guessing they'll be the maximum. Problem is, all of that stuff is hidden under
several layers of drivers, so I'm not sure how I'm going to get the overage passed
back. And I also need to put in some BUGINF logic to alert if I get more of these than
whatever I decide the interval to be.
That depends on what they count. Like I said - ethernet payload is 1500. Then you have
the ethernet headers which is 14 bytes, plus the crc trailer, which is 4 bytes. If you
count them, you end up at 1518 bytes.
Depends on the hardware I guess. I have no idea what the NIA-20 expose.
I meant
the maximum frame size; I suspect this is 1500 for the NI, but I don't actually know.
My speculation is that DECnet is using part of the buffer to piggy back node and and other
information into it instead of holding this meta-data, separately. I don't know what
Multinet does, but there you can configure the NI to have a packet size of 1500.
> If you are a DDP (LD.DDP), then you are not
CPU dependent and you go ahead always, otherwise, you have to be on the CPU that owns the
device (.CPCPN) So I'm not sure if it makes any difference, but DDP is not CPU
dependent; not sure if that is a synonym for 'shared'. If I stumble over
something more, I'll report it.
It's actually the same in RSX. The DDCMP layer is sort of between the hardware driver
and the higher level protocols, and it's not tied to any specific CPU.
But that code would suggest that LD.DDP is just an indication of whether something is CPU
dependent or not, and would have anything to do with DDCMP.
From looking at the
routing code, seems LD.DDP is used when something is getting handed to the NSP to play
with, I guess that would be goig through some kind of layering.
20 Jan
20 Jan
9:06 p.m.
On Jan 17, 2021, at 10:45 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
I think I may have finally gotten to the bottom of this. It's a level 1 routing
message that I'm getting from 2.1023 (A2RTR) that does not appear to be respecting
lengths, viz:
22:04:30.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN (0x6003), length
1478: lev-1-routing src 2.1023 {ids 0-726 cost 0 hops 0
This is two (2) bytes over the maximum that Tops-20 can accept.
NCP>SHOW LINE NI-0 CHARACTERISTICS
NCP>
22:16:04 NCP
Request # 23; Show Line Characteristics Completed
Line = NI-0
Receive Buffers = 6
Controller = Normal
Protocol = Ethernet
Hardware Address = 00 1F 16 EC CE 47
Receive buffer size = 1476
It would appear that the 20's are advertising this length in their layer 1 hello
messages:
22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN (0x6003), length
60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.522 blksize 1476 pri 5 hello 15
22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN (0x6003), length
60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.520 blksize 1476 pri 5 hello 15
The buffer size in the routing message and in the NCP characteristics (1476) is defined as
the size of the routing layer message; it does NOT include the data link layer overhead.
So the 14 byte Ethernet header is not part of that count; neither is the 2 byte DEC
Ethernet length field -- which DNA considers a data link field.
I assume the tcpdump report includes everything after the Ethernet header in the reported
length, so 1478 is correct, given that it includes the Ethernet length field. If TOPS is
not expecting that, this would be a bug on its part.
That said, I didn't really intend to send packets that big. The code was supposed to
use the minimum of the neighbor buffer sizes or my own, but in one of the two places where
the calculation was done the part "my own" was missing. Fixed in rev 577, so
with that you should be seeing 590 byte messages.
You should still look at why TOPS-20 is apparently getting the buffer length rules wrong.
paul
11:54 p.m.
Hey, speaking of this...
I decided to go and check how RSX actually works. And that have led to
some interesting observations on my side.
1. RSX actually do respect the maximum data layer block size the other
end sends in its init message. So even if I have a large size defined in
RSX, it should be working correct against another end with a smaller
block size.
2. With a block size of 576 (either local or remote), the actual packets
being sent are 578 bytes. Seems there is a 2 byte checksum that is in
addition to the actual payload. I found this a bit surprising, but it
seems this might be very intentional. So I'm trying to see if this also
is true for other systems. If someone else can do some checking that
would also be interesting.
3. VMS V5.4 seem to not be happy at all if the other end declares a
largee maximum data layer block size that the local one. This is the
problem I had when talking to a VAX at Peter, which is running V5.4. I
have no idea if that problems is still there in V7...
It would be really interesting to have a Multinet VMS machine setup in
the same area as me, with a link to RSX, so I could do some more testing...
Johnny
On 2021-01-20 21:06, Paul Koning wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 17, 2021, at 10:45 PM, Thomas DeBellis
<tommytimesharing at gmail.com <mailto:tommytimesharing at gmail.com>>
wrote:
I think I may have finally gotten to the bottom of this.? It's a level
1 routing message that I'm getting from 2.1023 (A2RTR) that does not
appear to be respecting lengths, viz:
*22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN
(0x6003), length *1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0 hops 0
This is two (2) bytes over the maximum that Tops-20 can accept.
NCP>*SHOW LINE NI-0 CHARACTERISTICS *
NCP>
22:16:04 ??? NCP
Request # 23; Show Line Characteristics Completed
Line = NI-0
? Receive Buffers = 6
? Controller = Normal
? Protocol = Ethernet
? Hardware Address = 00 1F 16 EC CE 47
? Receive buffer size = *1476*
It would appear that the 20's are advertising this length in their
layer 1 hello messages:
22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.522
blksize *1476* pri 5 hello 15
22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.520
blksize *1476* pri 5 hello 15
The buffer size in the routing message and in the NCP characteristics
(1476) is defined as the size of the routing layer message; it does NOT
include the data link layer overhead. ?So the 14 byte Ethernet header is
not part of that count; neither is the 2 byte DEC Ethernet length field
-- which DNA considers a data link field.
I assume the tcpdump report includes everything after the Ethernet
header in the reported length, so 1478 is correct, given that it
includes the Ethernet length field. ?If TOPS is not expecting that, this
would be a bug on its part.
That said, I didn't really intend to send packets that big. ?The code
was supposed to use the minimum of the neighbor buffer sizes or my own,
but in one of the two places where the calculation was done the part "my
own" was missing. ?Fixed in rev 577, so with that you should be seeing
590 byte messages.
You should still look at why TOPS-20 is apparently getting the buffer
length rules wrong.
paul
21 Jan
21 Jan
12:11 a.m.
Another interesting observation:
All systems I can observe over ethernet (various modern VMS, Ultrix,
whatever) seem to like to give a maximum data layer block size of 1498.
I suspect that this might be related to the two additional bytes I see
added in actual communication. Which leads to total packet size of 1500.
I'm going to change my systems to use 1498 based on this.
Johnny
On 2021-01-20 23:54, Johnny Billquist wrote:
Hey, speaking of this...
I decided to go and check how RSX actually works. And that have led to
some interesting observations on my side.
1. RSX actually do respect the maximum data layer block size the other
end sends in its init message. So even if I have a large size defined in
RSX, it should be working correct against another end with a smaller
block size.
2. With a block size of 576 (either local or remote), the actual packets
being sent are 578 bytes. Seems there is a 2 byte checksum that is in
addition to the actual payload. I found this a bit surprising, but it
seems this might be very intentional. So I'm trying to see if this also
is true for other systems. If someone else can do some checking that
would also be interesting.
3. VMS V5.4 seem to not be happy at all if the other end declares a
largee maximum data layer block size that the local one. This is the
problem I had when talking to a VAX at Peter, which is running V5.4. I
have no idea if that problems is still there in V7...
It would be really interesting to have a Multinet VMS machine setup in
the same area as me, with a link to RSX, so I could do some more testing...
? Johnny
On 2021-01-20 21:06, Paul Koning wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 17, 2021, at 10:45 PM, Thomas DeBellis
<tommytimesharing at gmail.com <mailto:tommytimesharing at gmail.com>>
wrote:
I think I may have finally gotten to the bottom of this.? It's a
level 1 routing message that I'm getting from 2.1023 (A2RTR) that
does not appear to be respecting lengths, viz:
*22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN
(0x6003), length *1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0
hops 0
This is two (2) bytes over the maximum that Tops-20 can accept.
??? NCP>*SHOW LINE NI-0 CHARACTERISTICS *
??? NCP>
??? 22:16:04 ??? NCP
??? Request # 23; Show Line Characteristics Completed
??? Line = NI-0
??? ? Receive Buffers = 6
??? ? Controller = Normal
??? ? Protocol = Ethernet
??? ? Hardware Address = 00 1F 16 EC CE 47
??? ? Receive buffer size = *1476*
It would appear that the 20's are advertising this length in their
layer 1 hello messages:
22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src
2.522 blksize *1476* pri 5 hello 15
22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src
2.520 blksize *1476* pri 5 hello 15
The buffer size in the routing message and in the NCP characteristics
(1476) is defined as the size of the routing layer message; it does
NOT include the data link layer overhead. ?So the 14 byte Ethernet
header is not part of that count; neither is the 2 byte DEC Ethernet
length field -- which DNA considers a data link field.
I assume the tcpdump report includes everything after the Ethernet
header in the reported length, so 1478 is correct, given that it
includes the Ethernet length field. ?If TOPS is not expecting that,
this would be a bug on its part.
That said, I didn't really intend to send packets that big. ?The code
was supposed to use the minimum of the neighbor buffer sizes or my
own, but in one of the two places where the calculation was done the
part "my own" was missing. ?Fixed in rev 577, so with that you should
be seeing 590 byte messages.
You should still look at why TOPS-20 is apparently getting the buffer
length rules wrong.
paul
1:36 a.m.
Remember that DEC protocols (at least DECnet and MOP, I don't remember what LAT does)
all have a length field following the protocol type field, and the payload comes after
that. As far as the DECnet architecture is concerned, that length field is part of the
data link layer, it is how it offers a service of sending packets without a minimum
length. So rather than supporting a DSDU size of 46 to 1500 bytes, the DEC Ethernet
datalink supports a DSDU size of 1 to 1498 bytes. This is why you see 1498 and not 1500
as the max packet size, and why it appears in buffer sizes.
Non-DEC observers normally don't think of that length field as a datalink layer
element so from that point of view this is all a bit confusing. But if you read the DNA
Ethernet data link layer spec it's all spelled out clearly and is perfectly
consistent.
Given that an Ethernet can potentially carry non-DECnet traffic (certainly does, nowadays)
a data link buffer size capable of receiving any size packet that might be thrown at you
makes perfect sense. What doesn't necessarily follow is that this larger buffer size
should show up in DECnet protocol messages or protocol behaviors.
paul
On Jan 20, 2021, at 6:11 PM, Johnny Billquist <bqt
at softjar.se> wrote:
Another interesting observation:
All systems I can observe over ethernet (various modern VMS, Ultrix, whatever) seem to
like to give a maximum data layer block size of 1498.
I suspect that this might be related to the two additional bytes I see added in actual
communication. Which leads to total packet size of 1500.
I'm going to change my systems to use 1498 based on this.
Johnny
On 2021-01-20 23:54, Johnny Billquist wrote:
Hey, speaking of this...
I decided to go and check how RSX actually works. And that have led to some interesting
observations on my side.
1. RSX actually do respect the maximum data layer block size the other end sends in its
init message. So even if I have a large size defined in RSX, it should be working correct
against another end with a smaller block size.
2. With a block size of 576 (either local or remote), the actual packets being sent are
578 bytes. Seems there is a 2 byte checksum that is in addition to the actual payload. I
found this a bit surprising, but it seems this might be very intentional. So I'm
trying to see if this also is true for other systems. If someone else can do some checking
that would also be interesting.
3. VMS V5.4 seem to not be happy at all if the other end declares a largee maximum data
layer block size that the local one. This is the problem I had when talking to a VAX at
Peter, which is running V5.4. I have no idea if that problems is still there in V7...
It would be really interesting to have a Multinet VMS machine setup in the same area as
me, with a link to RSX, so I could do some more testing...
Johnny
On 2021-01-20 21:06, Paul Koning wrote:
>
>
>> On Jan 17, 2021, at 10:45 PM, Thomas DeBellis <tommytimesharing at gmail.com
<mailto:tommytimesharing at gmail.com>> wrote:
>>
>> I think I may have finally gotten to the bottom of this. It's a level 1
routing message that I'm getting from 2.1023 (A2RTR) that does not appear to be
respecting lengths, viz:
>>
>> *22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN
(0x6003), length *1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0 hops 0
>>
>> This is two (2) bytes over the maximum that Tops-20 can accept.
>>
>> NCP>*SHOW LINE NI-0 CHARACTERISTICS *
>> NCP>
>> 22:16:04 NCP
>>
>> Request # 23; Show Line Characteristics Completed
>>
>> Line = NI-0
>>
>> Receive Buffers = 6
>> Controller = Normal
>> Protocol = Ethernet
>> Hardware Address = 00 1F 16 EC CE 47
>> Receive buffer size = *1476*
>>
>> It would appear that the 20's are advertising this length in their layer 1
hello messages:
>>
>> 22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN (0x6003),
length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.522 blksize *1476* pri 5 hello
15
>> 22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN (0x6003),
length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.520 blksize *1476* pri 5 hello
15
>>
> The buffer size in the routing message and in the NCP characteristics (1476) is
defined as the size of the routing layer message; it does NOT include the data link layer
overhead. So the 14 byte Ethernet header is not part of that count; neither is the 2 byte
DEC Ethernet length field -- which DNA considers a data link field.
>
> I assume the tcpdump report includes everything after the Ethernet header in the
reported length, so 1478 is correct, given that it includes the Ethernet length field. If
TOPS is not expecting that, this would be a bug on its part.
>
> That said, I didn't really intend to send packets that big. The code was
supposed to use the minimum of the neighbor buffer sizes or my own, but in one of the two
places where the calculation was done the part "my own" was missing. Fixed in
rev 577, so with that you should be seeing 590 byte messages.
>
> You should still look at why TOPS-20 is apparently getting the buffer length rules
wrong.
>
> paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
3:23 a.m.
On 2021-01-21 01:36, Paul Koning wrote:
Remember that DEC protocols (at least DECnet and MOP,
I don't remember what LAT does) all have a length field following the protocol type
field, and the payload comes after that. As far as the DECnet architecture is concerned,
that length field is part of the data link layer, it is how it offers a service of sending
packets without a minimum length. So rather than supporting a DSDU size of 46 to 1500
bytes, the DEC Ethernet datalink supports a DSDU size of 1 to 1498 bytes. This is why you
see 1498 and not 1500 as the max packet size, and why it appears in buffer sizes.
Yeah, I am aware of the size field they like to throw into the start.
I thought I saw that it didn't look like it was that which caused the
extra two bytes i the RSX DECnet code, but I should recheck. I might be
misremembering.
Ah. After checking - no I wasn't misremembering, but I was
misunderstanding the code. It also plays around with a checksum, but for
that it does make space within the available space for the packet.
Non-DEC observers normally don't think of that
length field as a datalink layer element so from that point of view this is all a bit
confusing. But if you read the DNA Ethernet data link layer spec it's all spelled out
clearly and is perfectly consistent.
Well. I obviously also know that there is no length field in the
ethernet spec itself, so obviously it's not part of the link layer in
the pure sense of the term. The fact that DEC has it in the payload area
don't truly make it a part of the ethernet datalink layer. :-)
But for some DEC protocols, it is...
Given that an Ethernet can potentially carry
non-DECnet traffic (certainly does, nowadays) a data link buffer size capable of receiving
any size packet that might be thrown at you makes perfect sense. What doesn't
necessarily follow is that this larger buffer size should show up in DECnet protocol
messages or protocol behaviors.
Agreed. Within DECnet, things just should be consistent with everything
else in there.
MIM and MAGICA now say 1498.
Johnny
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 20, 2021, at 6:11 PM, Johnny Billquist
<bqt at softjar.se> wrote:
Another interesting observation:
All systems I can observe over ethernet (various modern VMS, Ultrix, whatever) seem to
like to give a maximum data layer block size of 1498.
I suspect that this might be related to the two additional bytes I see added in actual
communication. Which leads to total packet size of 1500.
I'm going to change my systems to use 1498 based on this.
Johnny
On 2021-01-20 23:54, Johnny Billquist wrote:
Hey, speaking of this...
I decided to go and check how RSX actually works. And that have led to some interesting
observations on my side.
1. RSX actually do respect the maximum data layer block size the other end sends in its
init message. So even if I have a large size defined in RSX, it should be working correct
against another end with a smaller block size.
2. With a block size of 576 (either local or remote), the actual packets being sent are
578 bytes. Seems there is a 2 byte checksum that is in addition to the actual payload. I
found this a bit surprising, but it seems this might be very intentional. So I'm
trying to see if this also is true for other systems. If someone else can do some checking
that would also be interesting.
3. VMS V5.4 seem to not be happy at all if the other end declares a largee maximum data
layer block size that the local one. This is the problem I had when talking to a VAX at
Peter, which is running V5.4. I have no idea if that problems is still there in V7...
It would be really interesting to have a Multinet VMS machine setup in the same area as
me, with a link to RSX, so I could do some more testing...
Johnny
On 2021-01-20 21:06, Paul Koning wrote:
>
>
>> On Jan 17, 2021, at 10:45 PM, Thomas DeBellis <tommytimesharing at gmail.com
<mailto:tommytimesharing at gmail.com>> wrote:
>>
>> I think I may have finally gotten to the bottom of this. It's a level 1
routing message that I'm getting from 2.1023 (A2RTR) that does not appear to be
respecting lengths, viz:
>>
>> *22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN
(0x6003), length *1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0 hops 0
>>
>> This is two (2) bytes over the maximum that Tops-20 can accept.
>>
>> NCP>*SHOW LINE NI-0 CHARACTERISTICS *
>> NCP>
>> 22:16:04 NCP
>>
>> Request # 23; Show Line Characteristics Completed
>>
>> Line = NI-0
>>
>> Receive Buffers = 6
>> Controller = Normal
>> Protocol = Ethernet
>> Hardware Address = 00 1F 16 EC CE 47
>> Receive buffer size = *1476*
>>
>> It would appear that the 20's are advertising this length in their layer 1
hello messages:
>>
>> 22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN (0x6003),
length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.522 blksize *1476* pri 5 hello
15
>> 22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN (0x6003),
length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.520 blksize *1476* pri 5 hello
15
>>
> The buffer size in the routing message and in the NCP characteristics (1476) is
defined as the size of the routing layer message; it does NOT include the data link layer
overhead. So the 14 byte Ethernet header is not part of that count; neither is the 2 byte
DEC Ethernet length field -- which DNA considers a data link field.
>
> I assume the tcpdump report includes everything after the Ethernet header in the
reported length, so 1478 is correct, given that it includes the Ethernet length field. If
TOPS is not expecting that, this would be a bug on its part.
>
> That said, I didn't really intend to send packets that big. The code was
supposed to use the minimum of the neighbor buffer sizes or my own, but in one of the two
places where the calculation was done the part "my own" was missing. Fixed in
rev 577, so with that you should be seeing 590 byte messages.
>
> You should still look at why TOPS-20 is apparently getting the buffer length rules
wrong.
>
> paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
2:37 a.m.
On Jan 20, 2021, at 5:54 PM, Johnny Billquist <bqt
at softjar.se> wrote:
Hey, speaking of this...
I decided to go and check how RSX actually works. And that have led to some interesting
observations on my side.
1. RSX actually do respect the maximum data layer block size the other end sends in its
init message. So even if I have a large size defined in RSX, it should be working correct
against another end with a smaller block size.
Yes, and that behavior is exactly what the spec intended.
2. With a block size of 576 (either local or remote),
the actual packets being sent are 578 bytes. Seems there is a 2 byte checksum that is in
addition to the actual payload. I found this a bit surprising, but it seems this might be
very intentional. So I'm trying to see if this also is true for other systems. If
someone else can do some checking that would also be interesting.
You mean the routing messages? Yes, they end in a 2 byte checksum, but that is part of
the message and is required to be included in the size limit. If an implementation is
told block size 576 and it sends 578 byte routing messages, that's a bug. Apparently
one it gets away with, but it's not supposed to do that.
Is this on Multinet? I would expect this sort of thing to be caught on DDCMP. For
example, DECnet/E allocates DMC buffers of the precise size you ask for, so if you were to
send it a routing message 2 bytes longer than expected, DDCMP would reject it as an
oversized packet and the link would go down due to excessive retransmits.
3. VMS V5.4 seem to not be happy at all if the other
end declares a largee maximum data layer block size that the local one. This is the
problem I had when talking to a VAX at Peter, which is running V5.4. I have no idea if
that problems is still there in V7...
That's ugly and a definite bug.
It would be really interesting to have a Multinet VMS
machine setup in the same area as me, with a link to RSX, so I could do some more
testing...
paul
3:30 a.m.
On 2021-01-21 02:37, Paul Koning wrote:
Right. All good. I previously was wondering if RSX might just use the
own buffer size, which would then be the reason it fails to talk to that
VMS V5.4 node, but this is not the case...
Yeah. Got it sorted now. I misunderstood the code the first time.
I agree. I would really like to investigate things more here.
I struggled a lot with this, and only when I put RSX to use 576 byte
buffer size did I finally manage to establish a link up.
But looking at the packets, everything seems to be just as expected even
when I set RSX to use 1500 bytes, but VMS just refuse to accept the link
then. And the only difference is just that one field in the init message
that declares the buffer size of the node.
I tried a lot of different values between 576 and 1500. Nothing above
576 works.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 20, 2021, at 5:54 PM, Johnny Billquist
<bqt at softjar.se> wrote:
Hey, speaking of this...
I decided to go and check how RSX actually works. And that have led to some interesting
observations on my side.
1. RSX actually do respect the maximum data layer block size the other end sends in its
init message. So even if I have a large size defined in RSX, it should be working correct
against another end with a smaller block size.
Yes, and that behavior is exactly what the spec intended. 2. With a
block size of 576 (either local or remote), the actual packets being sent are 578 bytes.
Seems there is a 2 byte checksum that is in addition to the actual payload. I found this a
bit surprising, but it seems this might be very intentional. So I'm trying to see if
this also is true for other systems. If someone else can do some checking that would also
be interesting.
You mean the routing messages? Yes, they end in a 2 byte checksum, but that is part of
the message and is required to be included in the size limit. If an implementation is
told block size 576 and it sends 578 byte routing messages, that's a bug. Apparently
one it gets away with, but it's not supposed to do that. Is this on Multinet? I would expect this sort of
thing to be caught on DDCMP. For example, DECnet/E allocates DMC buffers of the precise
size you ask for, so if you were to send it a routing message 2 bytes longer than
expected, DDCMP would reject it as an oversized packet and the link would go down due to
excessive retransmits.
Well, now we need to clarify what we mean by 576 or 578 byte messages.
The 576 is what is reported in the init message, and is what the each
node knows the other accept. 578 is the number of bytes in the payload
on the wire.
And in this case, the wire is ethernet. So essentially what tcpdump reports.
So, in the DECnet sense, it's still 576 bytes. But then you have those
two extra bytes at the start, making it 578.
And of course, any ethernet driver actually need to read 578 bytes, in
order to get the 576 bytes at the DECnet link layer.
3. VMS V5.4
seem to not be happy at all if the other end declares a largee maximum data layer block
size that the local one. This is the problem I had when talking to a VAX at Peter, which
is running V5.4. I have no idea if that problems is still there in V7...
That's ugly and a definite bug.
11:58 a.m.
On 2021-01-20 21:06, Paul Koning wrote:
No. tcpdump length information is just the payload length.
Which here is consistent with the receive buffer size.
The receive buffer size is 1476. DECnet adds the two bytes for length
information, which leads to a total payload of 1478, which is also the
size of the packet that tcpdump reports.
The ethernet headers are not included here.
On Jan 17, 2021, at 10:45 PM, Thomas DeBellis
<tommytimesharing at gmail.com <mailto:tommytimesharing at gmail.com>>
wrote:
I think I may have finally gotten to the bottom of this.? It's a level
1 routing message that I'm getting from 2.1023 (A2RTR) that does not
appear to be respecting lengths, viz:
*22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN
(0x6003), length *1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0 hops 0
This is two (2) bytes over the maximum that Tops-20 can accept.
NCP>*SHOW LINE NI-0 CHARACTERISTICS *
NCP>
22:16:04 ??? NCP
Request # 23; Show Line Characteristics Completed
Line = NI-0
? Receive Buffers = 6
? Controller = Normal
? Protocol = Ethernet
? Hardware Address = 00 1F 16 EC CE 47
? Receive buffer size = *1476*
It would appear that the 20's are advertising this length in their
layer 1 hello messages:
22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.522
blksize *1476* pri 5 hello 15
22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.520
blksize *1476* pri 5 hello 15
The buffer size in the routing message and in the NCP characteristics
(1476) is defined as the size of the routing layer message; it does NOT
include the data link layer overhead. ?So the 14 byte Ethernet header is
not part of that count; neither is the 2 byte DEC Ethernet length field
-- which DNA considers a data link field.
I assume the tcpdump report includes everything after the Ethernet
header in the reported length, so 1478 is correct, given that it
includes the Ethernet length field. ?If TOPS is not expecting that, this
would be a bug on its part. That said, I didn't really intend to send packets
that big. ?The code
was supposed to use the minimum of the neighbor buffer sizes or my own,
but in one of the two places where the calculation was done the part "my
own" was missing. ?Fixed in rev 577, so with that you should be seeing
590 byte messages.
My understanding was that even the "broken" code would not be sending
anything close to 1500 bytes. Did I get that wrong?
You should still look at why TOPS-20 is apparently
getting the buffer
length rules wrong.
I would be more interested in why TOPS-20 wants 1476, while most other
things goes for 1498, if we're not going for the 576. Not sure TOPS-20
actually does anything wrong in any other way...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
12:06 p.m.
Oh, right...
And TOPS-20 do seem to be getting something wrong.
If they announce a receive buffer size of 1476, the actual payload they
need to be able to receive is 1478, on the ethernet level.
This appears to be totally according to spec.
Thomas might need to go and dig really deep into the TOPS-20 DECnet code
here. Because announcing a blksize of 1476 means that you really should
expect and accept 1478 byte packets (payload). The first two bytes being
a length field for the rest, and thus does not count to the actual
DECnet packet.
RSX announces whatever you configure. The actual receive buffers set up
on the ethernet controller will have 36 additional bytes added, to cover
for potential overhead (which means the ethernet overhead of 16 bytes,
plus the 2 for the length field). Why 36 then, you might ask. Well, just
because there is a standard overhead allocation factor independent of
the link layer, so it's the same everywhere. It should be big enough to
cover the overhead of any link technology. It's just that for ethernet,
the actual overhead is just 18 bytes. But it does mean that it can deal
with packets that are even slightly larger than what has been announced
as acceptable.
Johnny
On 2021-01-21 11:58, Johnny Billquist wrote:
On 2021-01-20 21:06, Paul Koning wrote:
No. tcpdump length information is just the payload length.
Which here is consistent with the receive buffer size.
The receive buffer size is 1476. DECnet adds the two bytes for length
information, which leads to a total payload of 1478, which is also the
size of the packet that tcpdump reports.
The ethernet headers are not included here.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 17, 2021, at 10:45 PM, Thomas DeBellis
<tommytimesharing at gmail.com <mailto:tommytimesharing at gmail.com>>
wrote:
I think I may have finally gotten to the bottom of this.? It's a
level 1 routing message that I'm getting from 2.1023 (A2RTR) that
does not appear to be respecting lengths, viz:
*22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN
(0x6003), length *1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0
hops 0
This is two (2) bytes over the maximum that Tops-20 can accept.
??? NCP>*SHOW LINE NI-0 CHARACTERISTICS *
??? NCP>
??? 22:16:04 ??? NCP
??? Request # 23; Show Line Characteristics Completed
??? Line = NI-0
??? ? Receive Buffers = 6
??? ? Controller = Normal
??? ? Protocol = Ethernet
??? ? Hardware Address = 00 1F 16 EC CE 47
??? ? Receive buffer size = *1476*
It would appear that the 20's are advertising this length in their
layer 1 hello messages:
22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src
2.522 blksize *1476* pri 5 hello 15
22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src
2.520 blksize *1476* pri 5 hello 15
The buffer size in the routing message and in the NCP characteristics
(1476) is defined as the size of the routing layer message; it does
NOT include the data link layer overhead. ?So the 14 byte Ethernet
header is not part of that count; neither is the 2 byte DEC Ethernet
length field -- which DNA considers a data link field.
I assume the tcpdump report includes everything after the Ethernet
header in the reported length, so 1478 is correct, given that it
includes the Ethernet length field. ?If TOPS is not expecting that,
this would be a bug on its part. That said, I didn't really intend to send
packets that big. ?The code
was supposed to use the minimum of the neighbor buffer sizes or my
own, but in one of the two places where the calculation was done the
part "my own" was missing. ?Fixed in rev 577, so with that you should
be seeing 590 byte messages.
My understanding was that even the "broken" code would not be sending
anything close to 1500 bytes. Did I get that wrong?
You should still look at why TOPS-20 is
apparently getting the buffer
length rules wrong.
I would be more interested in why TOPS-20 wants 1476, while most other
things goes for 1498, if we're not going for the 576. Not sure TOPS-20
actually does anything wrong in any other way...
? Johnny
16 Jan
16 Jan
6:18 a.m.
Unfortunately, in all the monitor sources, I only see the abbreviation
'DDP', no spelling out of what it is or what it does.? I didn't
immediately find an obvious driver.
Under the Tops-10 SMP conditional, checking is done as to whether a
particular device can be used, depending on what physical processor it
is actually connected to. If the processor doesn't own the circuit, then
the request is queued up for the processor that does.? The sole case is
a DDP, which is apparently not CPU dependent.
I have no idea what that could be.
------------------------------------------------------------------------
On 1/15/21 4:53 PM, Peter Lothberg wrote:
The 2020 has a KMC11 and up to 2 DUP11, and those are the interfaces
the "MRC T20 DECnet thing supports.
On the list of devices/sizes you posted is? a "DDP" device and I wounder
if you knew what that is?
--P
------------------------------------------------------------------------
*From: *"tommytimesharing" <tommytimesharing at gmail.com>
*To: *"hecnet" <hecnet at Update.UU.SE>
*Sent: *Friday, January 15, 2021 4:24:07 PM
*Subject: *Re: [HECnet] Thousands of DECnet errors on Tops-20
DDP?? I thought it was DUP-11.
------------------------------------------------------------------------
On 1/15/21 4:21 PM, Peter Lothberg wrote:
Well, MRC was receiving "suggestions" from Stu Grossman on how
to do it, but
if my memory does not fail me the block size was 312, due to
lack of buffer space
in the already crammed single section 512KW 2020. I'm afraid
my tape and disk-pack
are in Seattle. I knew it was not 576 as it had two DUP-11's
and using it for transit failed...
Quiz, do you knew what a DDP is?
-P
5:49 a.m.
Hum. 1504-%RTEHS seems like a weird expression. And then it would mean
RTEHS is 28? Any idea what RTEHS represents?
Anyway, the actual maximum payload on ethernet is 1500 bytes. Then you
have src and dst mac (6 bytes each), protocol (2 bytes) and crc (4
bytes). So if we're talking full size plus overhead, it should say 1518.
I could guess that the 1504 would be payload plus crc, but then why is
28 additional bytes taken away? That's twice what the overhead for the
rest is... And that it's exactly twice is also intriguing...
And yeah, I would definitely assume that DTE, CI and NI are not relevant
for a 2020. But I do know of one person who at least partially got a
DELUA to work on a 2020, so maybe it could have been possible to get
ethernet on it.
Johnny
On 2021-01-15 21:59, Thomas DeBellis wrote:
Was this maybe that magical version 5 of Tops-20 that
MRC put together
for the 2020?? I sure would love to see the sources for that!? I'm not
sure if this is relevant, but the following macro in D36COM is of interest:
DEFINE KNMMCS,<
;????????????? Symbol,Name,Cost, Maximum receive block size
??????? KNMMAC LD.TST,TST,? 1,? 0 ;TST DEVICE
??????? KNMMAC LD.DTE,DTE,? 3, <^D576>???????????????? ;DTE DEVICE
??????? KNMMAC LD.KDP,KDP,? 4, <^D576>???????????????? ;KDP DEVICE
??????? KNMMAC LD.DDP,DDP,? 5, <^D576>???????????????? ;DDP DEVICE
??????? KNMMAC LD.CIP,CI,?? 2, <^D576>???????????????? ;CI DEVICE
??????? KNMMAC LD.NI ,NI,?? 1, <^D1504-%RTEHS>???????? ;NI DEVICE
??????? KNMMAC LD.DMR,DMR,? 2, <^D576>???????????????? ;DMR DEVICE
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
;END OF KNMMCS
What can be seen is that the maximum block size is 576 in _all_ cases
except the NI, which is 1476 bytes.? I don't know if any of these
devices are relevant to the 2020; one assumes that the DTE, CI and NI
are not.
> ------------------------------------------------------------------------
> On 1/12/21 3:29 PM, Peter Lothberg wrote:
>
> The DECnet segment size has to be the same "network wide".
>
> If I remember right DECnet looks at the two end nodes and uses the
> smalles segment size,
> so if there is any transit node in the path with a small segment size
> things will not work as
> it will drop packets bigger than it''s size.
>
> The only SW/HW combination I knew of that has other than 576 is
> MRC/Stu DECnet for
> Tops20 4.x on DEC2020.
>
> -P
>
> ------------------------------------------------------------------------
>
> *From: *"tommytimesharing" <tommytimesharing at gmail.com>
> *To: *"hecnet" <hecnet at Update.UU.SE>
> *Sent: *Monday, January 11, 2021 11:58:56 PM
> *Subject: *Re: [HECnet] Thousands of DECnet errors on Tops-20
>
> Yes, I had seen this and had wondered about it after I had
> reflected on the output of a SHOW EXECUTOR CHARACTERISTICS
> command(clipped)
>
> Executor Node = 2.520 (TOMMYT)
>
> ? Identification = Tommy Timesharing
> ? Management Version = 4.0.0
> ? CPU = DECSYSTEM1020
> ? Software Identification = Tops-20 7.1 PANDA
>
> .
> .
> .
>
> Buffer Size = *576*
> ? Segment Buffer Size = *576*
>
> So it would appear that the 20's implementation of NICE knows of
> this differentiation.? I can parse for both SET EXECUTOR SEGMENT
> BUFFER SIZE and SET EXECUTOR BUFFER SIZE. Both fail, of course;
> again, once DECnet is initialized, they are locked.
>
> However, when one looks at the DECnet initialization block
> (IBBLK), it only contains a field for buffer size (IBBSZ), nothing
> about segment size.? Further, the NODE% JSYS' set DECnet
> initialization parameters function (.NDPRM) only contains a
> sub-function for buffer size (.NDBSZ) and SETSPD will only parse
> for DECNET BUFFER-SIZE. I'm hopeful to test that this weekend
> after I've looked further through the error log.
>
> The receive code in the low level NI driver (PHYKNI) only checks
> to see whether was was received will fit into the buffer
> specified.? It returns a length error (UNLER%) to DNADLL, but not
> the actual difference.
>
> I have yet to puzzle out how the segment size is derived, but it
> is apparently set on a line basis.
>
> ------------------------------------------------------------------------
> On 1/11/21 8:24 PM, Johnny Billquist 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>
> <mailto: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
>
>
>
6:30 a.m.
Yes, it is peculiar, isn't it?? It for a header.? I chased it down when
I saw it:
?????? MP %RTEHS,<2+7-6+21+4> ;Ethernet header size, composed of:
??????????????????????????????? ;+2 Ethernet padding bytes
??????????????????????????????? ;+7 Router Phase-IV pad bytes
??????????????????????????????? ;-6 corrects for assumed Phase III header
??????????????????????????????? ;+21 allows for full P-IV NI header
??????????????????????????????? ;+4 allows for 4 KLNIA CRC bytes (input)
??????????????????????????????? ;?? & for byte misalignment after BLT
(output)
The 1504 is to handle a rounding condition when converting from bytes to
words.
It comes out to 1476 bytes maximum data buffer size, which is what I am
re-configuring for when I reboot later this weekend.
------------------------------------------------------------------------
On 1/15/21 11:49 PM, Johnny Billquist wrote:
Hum. 1504-%RTEHS seems like a weird expression. And then it would mean
RTEHS is 28? Any idea what RTEHS represents?
Anyway, the actual maximum payload on ethernet is 1500 bytes. Then you
have src and dst mac (6 bytes each), protocol (2 bytes) and crc (4
bytes). So if we're talking full size plus overhead, it should say
1518. I could guess that the 1504 would be payload plus crc, but then
why is 28 additional bytes taken away? That's twice what the overhead
for the rest is... And that it's exactly twice is also intriguing...
And yeah, I would definitely assume that DTE, CI and NI are not
relevant for a 2020. But I do know of one person who at least
partially got a DELUA to work on a 2020, so maybe it could have been
possible to get ethernet on it.
? Johnny
------------------------------------------------------------------------
On 2021-01-15 21:59, Thomas DeBellis wrote:
Was this maybe that magical version 5 of Tops-20 that MRC put
together for the 2020?? I sure would love to see the sources for
that!? I'm not sure if this is relevant, but the following macro in
D36COM is of interest:
??? DEFINE KNMMCS,<
??? ;????????????? Symbol,Name,Cost, Maximum receive block size
???? ??????? KNMMAC LD.TST,TST,? 1,? 0 ;TST DEVICE
???? ??????? KNMMAC LD.DTE,DTE,? 3, <^D576>???????????????? ;DTE DEVICE
???? ??????? KNMMAC LD.KDP,KDP,? 4, <^D576>???????????????? ;KDP DEVICE
???? ??????? KNMMAC LD.DDP,DDP,? 5, <^D576>???????????????? ;DDP DEVICE
???? ??????? KNMMAC LD.CIP,CI,?? 2, <^D576>???????????????? ;CI DEVICE
???? ??????? KNMMAC LD.NI ,NI,?? 1, <^D1504-%RTEHS>???????? ;NI DEVICE
???? ??????? KNMMAC LD.DMR,DMR,? 2, <^D576>???????????????? ;DMR DEVICE
???? >;END OF KNMMCS
What can be seen is that the maximum block size is 576 in _all_ cases
except the NI, which is 1476 bytes.? I don't know if any of these
devices are relevant to the 2020; one assumes that the DTE, CI and NI
are not.
> ------------------------------------------------------------------------
> On 1/12/21 3:29 PM, Peter Lothberg wrote:
>
> The DECnet segment size has to be the same "network wide".
>
> If I remember right DECnet looks at the two end nodes and uses the
> smalles segment size,
> so if there is any transit node in the path with a small segment
> size things will not work as
> it will drop packets bigger than it''s size.
>
> The only SW/HW combination I knew of that has other than 576 is
> MRC/Stu DECnet for
> Tops20 4.x on DEC2020.
>
> -P
>
> ------------------------------------------------------------------------
>
>
> ??? *From: *"tommytimesharing" <tommytimesharing at gmail.com>
> ??? *To: *"hecnet" <hecnet at Update.UU.SE>
> ??? *Sent: *Monday, January 11, 2021 11:58:56 PM
> ??? *Subject: *Re: [HECnet] Thousands of DECnet errors on Tops-20
>
> ??? Yes, I had seen this and had wondered about it after I had
> ??? reflected on the output of a SHOW EXECUTOR CHARACTERISTICS
> ??? command(clipped)
>
> ??????? Executor Node = 2.520 (TOMMYT)
>
> ??????? ? Identification = Tommy Timesharing
> ??????? ? Management Version = 4.0.0
> ??????? ? CPU = DECSYSTEM1020
> ??????? ? Software Identification = Tops-20 7.1 PANDA
>
> ??????????????? .
> ??????????????? .
> ??????????????? .
>
> ??????? Buffer Size = *576*
> ??????? ? Segment Buffer Size = *576*
>
> ??? So it would appear that the 20's implementation of NICE knows of
> ??? this differentiation.? I can parse for both SET EXECUTOR SEGMENT
> ??? BUFFER SIZE and SET EXECUTOR BUFFER SIZE. Both fail, of course;
> ??? again, once DECnet is initialized, they are locked.
>
> ??? However, when one looks at the DECnet initialization block
> ??? (IBBLK), it only contains a field for buffer size (IBBSZ), nothing
> ??? about segment size.? Further, the NODE% JSYS' set DECnet
> ??? initialization parameters function (.NDPRM) only contains a
> ??? sub-function for buffer size (.NDBSZ) and SETSPD will only parse
> ??? for DECNET BUFFER-SIZE. I'm hopeful to test that this weekend
> ??? after I've looked further through the error log.
>
> ??? The receive code in the low level NI driver (PHYKNI) only checks
> ??? to see whether was was received will fit into the buffer
> ??? specified.? It returns a length error (UNLER%) to DNADLL, but not
> ??? the actual difference.
>
> ??? I have yet to puzzle out how the segment size is derived, but it
> ??? is apparently set on a line basis.
>
> ------------------------------------------------------------------------
>
> ??????? On 1/11/21 8:24 PM, Johnny Billquist 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>
> ??????????????????? <mailto: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
>
>
>
12 Jan
12 Jan
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
>
1431
days inactive
1441
days old
42 comments
5 participants
participants (5)
-
bqt＠softjar.se -
paulkoning＠comcast.net -
robert.jarratt＠ntlworld.com -
roll＠stupi.com -
tommytimesharing＠gmail.com