12 Dec
2021
12 Dec
'21
1:41 a.m.
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion
somewhat earlier, where I stated it was not supported per the specifications
in Simh comments and Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test
set, used for specific Decnet testing for Phase-I to IV. These triple nodes
were setup for using every possible device for Decnet communications,
amongst them the native (non-kdp) Dup. This one in multipoint mode is
character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would
establish sufficient proof for a well-functioning character based
synchronous line.
When the Dup line is interfaced to a Dmc line, the test reveals flapping
line behaviour: line up - circuit fault - line down; when trying to
transfer data an immediate circuit fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so
basically it should be able to work. However, although there are no problems
with the lower length (8) signaling packets, the moment 22 char packets are
transferred, the receiver complains about bad header as well as bad data crc
checksums, so the packets are somewhat mangled. It prohibits to start
Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01
40 02 02 00 .........(.. at ...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp:
0, HDRCRC: BAD, DATACRC: BAD
DBG(10561955696)> DUP PKT: Line0: >>> XMT Packet len: 8
DBG(10561955696)> DUP PKT: Control: Type: 2 (NAK) Reason: 1 (HCRC), Flags:
SQ, Resp: 0
DBG(10561955696)> DUP XMT: Line:0 0000 05 02 C1 00 00 01 85 A9
........
DBG(10561955696)> DUP XMT: rxnexttime=10561953465 (-541 usecs)
DBG(10561955696)> DUP PKT: dup_svc(dup=0) - 8 byte packet transmission
complete
Per Mark P's comment that some kind of filtering takes place in non-kdp dup
mode, that might indicate that the source of the problems could be located
in that corner.
That behaviour needs to be examined.
So it looks that basically character mode Dup is (was meant to be)
supported, but that it needs to be tuned; this functional mode was probably
not tested in the past as the accent was on Ddcmp processing within Simh
for Dmc/Dmr and Kdp/Dup device setups.
Reindert
12 Dec
12 Dec
7:29 p.m.
On Dec 11, 2021, at 7:41 PM, R. Voorhorst
<R.Voorhorst at swabhawat.com> wrote:
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion somewhat
earlier, where I stated it was not supported per the specifications in Simh comments and
Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test set, used for
specific Decnet testing for Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the native (non-kdp) Dup. This one
in multipoint mode is character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would establish
sufficient proof for a well-functioning character based synchronous line.
Yes, if you use TCP mode. It's not likely to work in UDP mode because then the DMC
emulation expects to get a full DDCMP frame in a single UDP packet. But in TCP mode it
just picks apart the byte stream.
When the Dup line is interfaced to a Dmc line, the
test reveals flapping line behaviour: line up - circuit fault ? line down; when trying to
transfer data an immediate circuit fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so basically it
should be able to work. However, although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are transferred, the receiver complains
about bad header as well as bad data crc checksums, so the packets are somewhat mangled.
It prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01 40 02 02 00
.........(.. at ...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp: 0,
HDRCRC: BAD, DATACRC: BAD
...
Per Mark P?s comment that some kind of filtering takes
place in non-kdp dup mode, that might indicate that the source of the problems could be
located in that corner.
That behaviour needs to be examined.
I wonder what kind of filtering that might be. The header looks completely normal for a
DDCMP data frame, it indicates a data length of 12 bytes which matches what you see in
that packet. 12 would be the expected length of a Routing Init message, normally the
first data packet sent after DDCMP startup is complete. Then again, its contents make no
sense as an Init message. Sending node 1.40, does that seem right? But the
"tiiinfo" (node type etc.) is 0x40 which isn't valid. Nor is the routing
version (0.0.15) or the hello timer value (0).
Could it be that one side is set in TELNET mode while the other is not? The settings must
match or 0xff bytes are mishandled.
paul
7:37 p.m.
The functioning DUP simulation only sends packets. If the connection is TCP, then a 2
byte packet size is stuffed ahead of the packet data on transmit and the receiving side
strips this from the data presented to the simulated system. In UDP mode, the UDP packet
size is stuffed into the beginning of the packet buffer and that size is then also
stripped just like the TCP case.
The problems that Reindert is seeing are probably related to timing of byte delivery into
the simulation or timing of successive packets being delivered which may possibly overrun
buffer space in the simulated OS.
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of Paul
Koning
Sent: Sunday, December 12, 2021 10:29 AM
To: hecnet at update.uu.se
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
On Dec 11, 2021, at 7:41 PM, R. Voorhorst <R.Voorhorst at
swabhawat.com<mailto:R.Voorhorst at swabhawat.com>> wrote:
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion somewhat
earlier, where I stated it was not supported per the specifications in Simh comments and
Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test set, used for
specific Decnet testing for Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the native (non-kdp) Dup. This one
in multipoint mode is character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would establish
sufficient proof for a well-functioning character based synchronous line.
Yes, if you use TCP mode. It's not likely to work in UDP mode because then the DMC
emulation expects to get a full DDCMP frame in a single UDP packet. But in TCP mode it
just picks apart the byte stream.
When the Dup line is interfaced to a Dmc line, the test reveals flapping line behaviour:
line up - circuit fault ? line down; when trying to transfer data an immediate circuit
fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so basically it should
be able to work. However, although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are transferred, the receiver complains
about bad header as well as bad data crc checksums, so the packets are somewhat mangled.
It prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01 40 02 02 00
.........(..@<mailto:..@>...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp: 0, HDRCRC:
BAD, DATACRC: BAD
...
Per Mark P?s comment that some kind of filtering takes place in non-kdp dup mode, that
might indicate that the source of the problems could be located in that corner.
That behaviour needs to be examined.
I wonder what kind of filtering that might be. The header looks completely normal for a
DDCMP data frame, it indicates a data length of 12 bytes which matches what you see in
that packet. 12 would be the expected length of a Routing Init message, normally the
first data packet sent after DDCMP startup is complete. Then again, its contents make no
sense as an Init message. Sending node 1.40, does that seem right? But the
"tiiinfo" (node type etc.) is 0x40 which isn't valid. Nor is the routing
version (0.0.15) or the hello timer value (0).
Could it be that one side is set in TELNET mode while the other is not? The settings must
match or 0xff bytes are mishandled.
paul
7:41 p.m.
You mean DUP-alone? KMC-DUP is compatible with DMC, right? And that sends (in TCP mode)
the frames as-is, no byte count since none is needed.
paul
On Dec 12, 2021, at 1:37 PM, Mark Pizzolato - Info
Comm <Mark at infocomm.com> wrote:
The functioning DUP simulation only sends packets. If the connection is TCP, then a 2
byte packet size is stuffed ahead of the packet data on transmit and the receiving side
strips this from the data presented to the simulated system. In UDP mode, the UDP packet
size is stuffed into the beginning of the packet buffer and that size is then also
stripped just like the TCP case.
The problems that Reindert is seeing are probably related to timing of byte delivery into
the simulation or timing of successive packets being delivered which may possibly overrun
buffer space in the simulated OS.
From: owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>> On Behalf
Of Paul Koning
Sent: Sunday, December 12, 2021 10:29 AM
To: hecnet at update.uu.se <mailto:hecnet at update.uu.se>
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
On Dec 11, 2021, at 7:41 PM, R. Voorhorst <R.Voorhorst at swabhawat.com
<mailto:R.Voorhorst at swabhawat.com>> wrote:
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion somewhat
earlier, where I stated it was not supported per the specifications in Simh comments and
Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test set, used for
specific Decnet testing for Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the native (non-kdp) Dup. This one
in multipoint mode is character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would establish
sufficient proof for a well-functioning character based synchronous line.
Yes, if you use TCP mode. It's not likely to work in UDP mode because then the DMC
emulation expects to get a full DDCMP frame in a single UDP packet. But in TCP mode it
just picks apart the byte stream.
When the Dup line is interfaced to a Dmc line, the test reveals flapping line behaviour:
line up - circuit fault ? line down; when trying to transfer data an immediate circuit
fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so basically it
should be able to work. However, although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are transferred, the receiver complains
about bad header as well as bad data crc checksums, so the packets are somewhat mangled.
It prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01 40 02 02 00
.........(..@ <mailto:..@>...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp: 0,
HDRCRC: BAD, DATACRC: BAD
...
Per Mark P?s comment that some kind of filtering takes place in non-kdp dup mode, that
might indicate that the source of the problems could be located in that corner.
That behaviour needs to be examined.
I wonder what kind of filtering that might be. The header looks completely normal for a
DDCMP data frame, it indicates a data length of 12 bytes which matches what you see in
that packet. 12 would be the expected length of a Routing Init message, normally the
first data packet sent after DDCMP startup is complete. Then again, its contents make no
sense as an Init message. Sending node 1.40, does that seem right? But the
"tiiinfo" (node type etc.) is 0x40 which isn't valid. Nor is the routing
version (0.0.15) or the hello timer value (0).
Could it be that one side is set in TELNET mode while the other is not? The settings
must match or 0xff bytes are mishandled.
paul
7:46 p.m.
The byte count is absolutely needed in TCP mode since the byte count describes the packet
boundaries on the wire. UDP mode is already packets hence the insertion of the packet
length preceding the data so the next layer doesn?t (in the device simulation) doesn?t
have to be aware of TCP or UDP.
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of Paul
Koning
Sent: Sunday, December 12, 2021 10:42 AM
To: hecnet at update.uu.se
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
You mean DUP-alone? KMC-DUP is compatible with DMC, right? And that sends (in TCP mode)
the frames as-is, no byte count since none is needed.
paul
On Dec 12, 2021, at 1:37 PM, Mark Pizzolato - Info Comm <Mark at
infocomm.com<mailto:Mark at infocomm.com>> wrote:
The functioning DUP simulation only sends packets. If the connection is TCP, then a 2
byte packet size is stuffed ahead of the packet data on transmit and the receiving side
strips this from the data presented to the simulated system. In UDP mode, the UDP packet
size is stuffed into the beginning of the packet buffer and that size is then also
stripped just like the TCP case.
The problems that Reindert is seeing are probably related to timing of byte delivery into
the simulation or timing of successive packets being delivered which may possibly overrun
buffer space in the simulated OS.
From: owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>> On Behalf
Of Paul Koning
Sent: Sunday, December 12, 2021 10:29 AM
To: hecnet at update.uu.se<mailto:hecnet at update.uu.se>
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
On Dec 11, 2021, at 7:41 PM, R. Voorhorst <R.Voorhorst at
swabhawat.com<mailto:R.Voorhorst at swabhawat.com>> wrote:
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion somewhat
earlier, where I stated it was not supported per the specifications in Simh comments and
Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test set, used for
specific Decnet testing for Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the native (non-kdp) Dup. This one
in multipoint mode is character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would establish
sufficient proof for a well-functioning character based synchronous line.
Yes, if you use TCP mode. It's not likely to work in UDP mode because then the DMC
emulation expects to get a full DDCMP frame in a single UDP packet. But in TCP mode it
just picks apart the byte stream.
When the Dup line is interfaced to a Dmc line, the test reveals flapping line behaviour:
line up - circuit fault ? line down; when trying to transfer data an immediate circuit
fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so basically it should
be able to work. However, although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are transferred, the receiver complains
about bad header as well as bad data crc checksums, so the packets are somewhat mangled.
It prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01 40 02 02 00
.........(..@<mailto:..@>...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp: 0, HDRCRC:
BAD, DATACRC: BAD
...
Per Mark P?s comment that some kind of filtering takes place in non-kdp dup mode, that
might indicate that the source of the problems could be located in that corner.
That behaviour needs to be examined.
I wonder what kind of filtering that might be. The header looks completely normal for a
DDCMP data frame, it indicates a data length of 12 bytes which matches what you see in
that packet. 12 would be the expected length of a Routing Init message, normally the
first data packet sent after DDCMP startup is complete. Then again, its contents make no
sense as an Init message. Sending node 1.40, does that seem right? But the
"tiiinfo" (node type etc.) is 0x40 which isn't valid. Nor is the routing
version (0.0.15) or the hello timer value (0).
Could it be that one side is set in TELNET mode while the other is not? The settings must
match or 0xff bytes are mishandled.
paul
8:02 p.m.
Yes, for general sync emulation. But DDCMP over TCP is carried without frame sizes
because DDCMP does its own packet framing using the header start bytes and header CRC
checks. So if DUP-only mode is inserting frame size fields, that would be a problem when
talking to KMC-DUP or DMC, because those don't so they neither expect nor send those
fields.
The solution might be a way to suppress the size field when the intent is to use the DUP
to carry DDCMP.
paul
On Dec 12, 2021, at 1:46 PM, Mark Pizzolato - Info
Comm <Mark at infocomm.com> wrote:
The byte count is absolutely needed in TCP mode since the byte count describes the packet
boundaries on the wire. UDP mode is already packets hence the insertion of the packet
length preceding the data so the next layer doesn?t (in the device simulation) doesn?t
have to be aware of TCP or UDP.
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of Paul
Koning
Sent: Sunday, December 12, 2021 10:42 AM
To: hecnet at update.uu.se
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
You mean DUP-alone? KMC-DUP is compatible with DMC, right? And that sends (in TCP mode)
the frames as-is, no byte count since none is needed.
paul
On Dec 12, 2021, at 1:37 PM, Mark Pizzolato - Info Comm <Mark at infocomm.com
<mailto:Mark at infocomm.com>> wrote:
The functioning DUP simulation only sends packets. If the connection is TCP, then a 2
byte packet size is stuffed ahead of the packet data on transmit and the receiving side
strips this from the data presented to the simulated system. In UDP mode, the UDP packet
size is stuffed into the beginning of the packet buffer and that size is then also
stripped just like the TCP case.
The problems that Reindert is seeing are probably related to timing of byte delivery into
the simulation or timing of successive packets being delivered which may possibly overrun
buffer space in the simulated OS.
From: owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>> On Behalf
Of Paul Koning
Sent: Sunday, December 12, 2021 10:29 AM
To: hecnet at update.uu.se <mailto:hecnet at update.uu.se>
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
On Dec 11, 2021, at 7:41 PM, R. Voorhorst <R.Voorhorst at swabhawat.com
<mailto:R.Voorhorst at swabhawat.com>> wrote:
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion somewhat
earlier, where I stated it was not supported per the specifications in Simh comments and
Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test set, used for
specific Decnet testing for Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the native (non-kdp) Dup. This one
in multipoint mode is character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would establish
sufficient proof for a well-functioning character based synchronous line.
Yes, if you use TCP mode. It's not likely to work in UDP mode because then the DMC
emulation expects to get a full DDCMP frame in a single UDP packet. But in TCP mode it
just picks apart the byte stream.
When the Dup line is interfaced to a Dmc line, the test reveals flapping line behaviour:
line up - circuit fault ? line down; when trying to transfer data an immediate circuit
fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so basically it
should be able to work. However, although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are transferred, the receiver complains
about bad header as well as bad data crc checksums, so the packets are somewhat mangled.
It prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01 40 02 02 00
.........(..@ <mailto:..@>...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp: 0,
HDRCRC: BAD, DATACRC: BAD
...
Per Mark P?s comment that some kind of filtering takes place in non-kdp dup mode, that
might indicate that the source of the problems could be located in that corner.
That behaviour needs to be examined.
I wonder what kind of filtering that might be. The header looks completely normal for a
DDCMP data frame, it indicates a data length of 12 bytes which matches what you see in
that packet. 12 would be the expected length of a Routing Init message, normally the
first data packet sent after DDCMP startup is complete. Then again, its contents make no
sense as an Init message. Sending node 1.40, does that seem right? But the
"tiiinfo" (node type etc.) is 0x40 which isn't valid. Nor is the routing
version (0.0.15) or the hello timer value (0).
Could it be that one side is set in TELNET mode while the other is not? The settings
must match or 0xff bytes are mishandled.
paul
8:11 p.m.
The TMXR layer (which is providing the TCP and UDP transports) doesn?t know anything about
DDCMP BUT in this context it is providing packet delivery services. If packets which
happen to also have separate frame size information are part of what is transported, that
won?t matter one way or another.
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of Paul
Koning
Sent: Sunday, December 12, 2021 11:02 AM
To: hecnet at update.uu.se
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
Yes, for general sync emulation. But DDCMP over TCP is carried without frame sizes
because DDCMP does its own packet framing using the header start bytes and header CRC
checks. So if DUP-only mode is inserting frame size fields, that would be a problem when
talking to KMC-DUP or DMC, because those don't so they neither expect nor send those
fields.
The solution might be a way to suppress the size field when the intent is to use the DUP
to carry DDCMP.
paul
On Dec 12, 2021, at 1:46 PM, Mark Pizzolato - Info Comm <Mark at
infocomm.com<mailto:Mark at infocomm.com>> wrote:
The byte count is absolutely needed in TCP mode since the byte count describes the packet
boundaries on the wire. UDP mode is already packets hence the insertion of the packet
length preceding the data so the next layer doesn?t (in the device simulation) doesn?t
have to be aware of TCP or UDP.
From: owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>> On Behalf
Of Paul Koning
Sent: Sunday, December 12, 2021 10:42 AM
To: hecnet at update.uu.se<mailto:hecnet at update.uu.se>
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
You mean DUP-alone? KMC-DUP is compatible with DMC, right? And that sends (in TCP mode)
the frames as-is, no byte count since none is needed.
paul
On Dec 12, 2021, at 1:37 PM, Mark Pizzolato - Info Comm <Mark at
infocomm.com<mailto:Mark at infocomm.com>> wrote:
The functioning DUP simulation only sends packets. If the connection is TCP, then a 2
byte packet size is stuffed ahead of the packet data on transmit and the receiving side
strips this from the data presented to the simulated system. In UDP mode, the UDP packet
size is stuffed into the beginning of the packet buffer and that size is then also
stripped just like the TCP case.
The problems that Reindert is seeing are probably related to timing of byte delivery into
the simulation or timing of successive packets being delivered which may possibly overrun
buffer space in the simulated OS.
From: owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>> On Behalf
Of Paul Koning
Sent: Sunday, December 12, 2021 10:29 AM
To: hecnet at update.uu.se<mailto:hecnet at update.uu.se>
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
On Dec 11, 2021, at 7:41 PM, R. Voorhorst <R.Voorhorst at
swabhawat.com<mailto:R.Voorhorst at swabhawat.com>> wrote:
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion somewhat
earlier, where I stated it was not supported per the specifications in Simh comments and
Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test set, used for
specific Decnet testing for Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the native (non-kdp) Dup. This one
in multipoint mode is character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would establish
sufficient proof for a well-functioning character based synchronous line.
Yes, if you use TCP mode. It's not likely to work in UDP mode because then the DMC
emulation expects to get a full DDCMP frame in a single UDP packet. But in TCP mode it
just picks apart the byte stream.
When the Dup line is interfaced to a Dmc line, the test reveals flapping line behaviour:
line up - circuit fault ? line down; when trying to transfer data an immediate circuit
fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so basically it should
be able to work. However, although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are transferred, the receiver complains
about bad header as well as bad data crc checksums, so the packets are somewhat mangled.
It prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01 40 02 02 00
.........(..@<mailto:..@>...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp: 0, HDRCRC:
BAD, DATACRC: BAD
...
Per Mark P?s comment that some kind of filtering takes place in non-kdp dup mode, that
might indicate that the source of the problems could be located in that corner.
That behaviour needs to be examined.
I wonder what kind of filtering that might be. The header looks completely normal for a
DDCMP data frame, it indicates a data length of 12 bytes which matches what you see in
that packet. 12 would be the expected length of a Routing Init message, normally the
first data packet sent after DDCMP startup is complete. Then again, its contents make no
sense as an Init message. Sending node 1.40, does that seem right? But the
"tiiinfo" (node type etc.) is 0x40 which isn't valid. Nor is the routing
version (0.0.15) or the hello timer value (0).
Could it be that one side is set in TELNET mode while the other is not? The settings must
match or 0xff bytes are mishandled.
paul
8:17 p.m.
Ok, but DMC emulation uses TMXR, and whatever mode it's using does not insert any
extra count fields.
paul
On Dec 12, 2021, at 2:11 PM, Mark Pizzolato - Info
Comm <Mark at infocomm.com> wrote:
The TMXR layer (which is providing the TCP and UDP transports) doesn?t know anything
about DDCMP BUT in this context it is providing packet delivery services. If packets
which happen to also have separate frame size information are part of what is transported,
that won?t matter one way or another.
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of Paul
Koning
Sent: Sunday, December 12, 2021 11:02 AM
To: hecnet at update.uu.se
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
Yes, for general sync emulation. But DDCMP over TCP is carried without frame sizes
because DDCMP does its own packet framing using the header start bytes and header CRC
checks. So if DUP-only mode is inserting frame size fields, that would be a problem when
talking to KMC-DUP or DMC, because those don't so they neither expect nor send those
fields.
The solution might be a way to suppress the size field when the intent is to use the DUP
to carry DDCMP.
paul
On Dec 12, 2021, at 1:46 PM, Mark Pizzolato - Info Comm <Mark at infocomm.com
<mailto:Mark at infocomm.com>> wrote:
The byte count is absolutely needed in TCP mode since the byte count describes the packet
boundaries on the wire. UDP mode is already packets hence the insertion of the packet
length preceding the data so the next layer doesn?t (in the device simulation) doesn?t
have to be aware of TCP or UDP.
From: owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>> On Behalf
Of Paul Koning
Sent: Sunday, December 12, 2021 10:42 AM
To: hecnet at update.uu.se <mailto:hecnet at update.uu.se>
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
You mean DUP-alone? KMC-DUP is compatible with DMC, right? And that sends (in TCP mode)
the frames as-is, no byte count since none is needed.
paul
On Dec 12, 2021, at 1:37 PM, Mark Pizzolato - Info Comm <Mark at infocomm.com
<mailto:Mark at infocomm.com>> wrote:
The functioning DUP simulation only sends packets. If the connection is TCP, then a 2
byte packet size is stuffed ahead of the packet data on transmit and the receiving side
strips this from the data presented to the simulated system. In UDP mode, the UDP packet
size is stuffed into the beginning of the packet buffer and that size is then also
stripped just like the TCP case.
The problems that Reindert is seeing are probably related to timing of byte delivery into
the simulation or timing of successive packets being delivered which may possibly overrun
buffer space in the simulated OS.
From: owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>> On Behalf
Of Paul Koning
Sent: Sunday, December 12, 2021 10:29 AM
To: hecnet at update.uu.se <mailto:hecnet at update.uu.se>
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
On Dec 11, 2021, at 7:41 PM, R. Voorhorst <R.Voorhorst at swabhawat.com
<mailto:R.Voorhorst at swabhawat.com>> wrote:
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion somewhat
earlier, where I stated it was not supported per the specifications in Simh comments and
Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test set, used for
specific Decnet testing for Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the native (non-kdp) Dup. This one
in multipoint mode is character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would establish
sufficient proof for a well-functioning character based synchronous line.
Yes, if you use TCP mode. It's not likely to work in UDP mode because then the DMC
emulation expects to get a full DDCMP frame in a single UDP packet. But in TCP mode it
just picks apart the byte stream.
When the Dup line is interfaced to a Dmc line, the test reveals flapping line behaviour:
line up - circuit fault ? line down; when trying to transfer data an immediate circuit
fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so basically it
should be able to work. However, although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are transferred, the receiver complains
about bad header as well as bad data crc checksums, so the packets are somewhat mangled.
It prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01 40 02 02 00
.........(..@ <mailto:..@>...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp: 0,
HDRCRC: BAD, DATACRC: BAD
...
Per Mark P?s comment that some kind of filtering takes place in non-kdp dup mode, that
might indicate that the source of the problems could be located in that corner.
That behaviour needs to be examined.
I wonder what kind of filtering that might be. The header looks completely normal for a
DDCMP data frame, it indicates a data length of 12 bytes which matches what you see in
that packet. 12 would be the expected length of a Routing Init message, normally the
first data packet sent after DDCMP startup is complete. Then again, its contents make no
sense as an Init message. Sending node 1.40, does that seem right? But the
"tiiinfo" (node type etc.) is 0x40 which isn't valid. Nor is the routing
version (0.0.15) or the hello timer value (0).
Could it be that one side is set in TELNET mode while the other is not? The settings
must match or 0xff bytes are mishandled.
paul
10:27 p.m.
So... if DUP-only mode using TMXR framed transmission which throws in a size field on TCP,
that would imply UDP mode should be used instead. Right?
paul
On Dec 12, 2021, at 1:46 PM, Mark Pizzolato - Info
Comm <Mark at infocomm.com> wrote:
The byte count is absolutely needed in TCP mode since the byte count describes the packet
boundaries on the wire. UDP mode is already packets hence the insertion of the packet
length preceding the data so the next layer doesn?t (in the device simulation) doesn?t
have to be aware of TCP or UDP.
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of Paul
Koning
Sent: Sunday, December 12, 2021 10:42 AM
To: hecnet at update.uu.se
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
You mean DUP-alone? KMC-DUP is compatible with DMC, right? And that sends (in TCP mode)
the frames as-is, no byte count since none is needed.
paul
On Dec 12, 2021, at 1:37 PM, Mark Pizzolato - Info Comm <Mark at infocomm.com
<mailto:Mark at infocomm.com>> wrote:
The functioning DUP simulation only sends packets. If the connection is TCP, then a 2
byte packet size is stuffed ahead of the packet data on transmit and the receiving side
strips this from the data presented to the simulated system. In UDP mode, the UDP packet
size is stuffed into the beginning of the packet buffer and that size is then also
stripped just like the TCP case.
The problems that Reindert is seeing are probably related to timing of byte delivery into
the simulation or timing of successive packets being delivered which may possibly overrun
buffer space in the simulated OS.
From: owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>> On Behalf
Of Paul Koning
Sent: Sunday, December 12, 2021 10:29 AM
To: hecnet at update.uu.se <mailto:hecnet at update.uu.se>
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
On Dec 11, 2021, at 7:41 PM, R. Voorhorst <R.Voorhorst at swabhawat.com
<mailto:R.Voorhorst at swabhawat.com>> wrote:
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion somewhat
earlier, where I stated it was not supported per the specifications in Simh comments and
Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test set, used for
specific Decnet testing for Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the native (non-kdp) Dup. This one
in multipoint mode is character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would establish
sufficient proof for a well-functioning character based synchronous line.
Yes, if you use TCP mode. It's not likely to work in UDP mode because then the DMC
emulation expects to get a full DDCMP frame in a single UDP packet. But in TCP mode it
just picks apart the byte stream.
When the Dup line is interfaced to a Dmc line, the test reveals flapping line behaviour:
line up - circuit fault ? line down; when trying to transfer data an immediate circuit
fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so basically it
should be able to work. However, although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are transferred, the receiver complains
about bad header as well as bad data crc checksums, so the packets are somewhat mangled.
It prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01 40 02 02 00
.........(..@ <mailto:..@>...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp: 0,
HDRCRC: BAD, DATACRC: BAD
...
Per Mark P?s comment that some kind of filtering takes place in non-kdp dup mode, that
might indicate that the source of the problems could be located in that corner.
That behaviour needs to be examined.
I wonder what kind of filtering that might be. The header looks completely normal for a
DDCMP data frame, it indicates a data length of 12 bytes which matches what you see in
that packet. 12 would be the expected length of a Routing Init message, normally the
first data packet sent after DDCMP startup is complete. Then again, its contents make no
sense as an Init message. Sending node 1.40, does that seem right? But the
"tiiinfo" (node type etc.) is 0x40 which isn't valid. Nor is the routing
version (0.0.15) or the hello timer value (0).
Could it be that one side is set in TELNET mode while the other is not? The settings
must match or 0xff bytes are mishandled.
paul
13 Dec
13 Dec
12:25 a.m.
I don't get it at all.
A DUP is a synchronous serial interface.
That means it sends and receives bytes. Nothing more, nothing less.
If you want to simulate it, you should be sending bytes verbatim, and
receive them verbatim. Any framing or other trickery should not be done,
because a DUP does not do that.
DDCMP does framing, which is well documented. Which means if you
simulate a KMC-DUP combo, you should just run DDCMP on the stream of
bytes. Your DDCMP implementation will catch and do the framing as expected.
And if you connect that with a DUP that just do DDCMP in software, it
will be getting the same stream of bytes, and will manage the framing in
software.
Using TCP for this should be extremely simple and straight forward.
Using UDP is not something I would ever recommend here. But if you
insist, maybe you could just pretend the data is a chunk of bytes to be
fed in and processed the same as if it had been TCP.
And it's the same story if you have a DZ or KMC-DZ.
Johnny
On 2021-12-12 22:27, Paul Koning wrote:
So... if DUP-only mode using TMXR framed transmission
which throws in a
size field on TCP, that would imply UDP mode should be used instead. ?Right?
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 Dec 12, 2021, at 1:46 PM, Mark Pizzolato -
Info Comm
<Mark at infocomm.com <mailto:Mark at infocomm.com>> wrote:
The byte count is absolutely needed in TCP mode since the byte count
describes the packet boundaries on the wire.? UDP mode is already
packets hence the insertion of the packet length preceding the data so
the next layer doesn?t (in the device simulation) doesn?t have to be
aware of TCP or UDP.
*From:*owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>>*On
Behalf Of*Paul Koning
*Sent:*Sunday, December 12, 2021 10:42 AM
*To:*hecnet at update.uu.se <mailto:hecnet at update.uu.se>
*Subject:*Re: [HECnet] native Dup sync line revisited --> preliminary
tests reveals problems
You mean DUP-alone? ?KMC-DUP is compatible with DMC, right? ?And that
sends (in TCP mode) the frames as-is, no byte count since none is needed.
paul
On Dec 12, 2021, at 1:37 PM, Mark Pizzolato - Info Comm
<Mark at infocomm.com <mailto:Mark at infocomm.com>> wrote:
The functioning DUP simulation only sends packets.? If the
connection is TCP, then a 2 byte packet size is stuffed ahead of
the packet data on transmit and the receiving side strips this
from the data presented to the simulated system.? In UDP mode, the
UDP packet size is stuffed into the beginning of the packet buffer
and that size is then also stripped just like the TCP case.
The problems that Reindert is seeing are probably related to
timing of byte delivery into the simulation or timing of
successive packets being delivered which may possibly overrun
buffer space in the simulated OS.
*From:*owner-hecnet at Update.UU.SE
<mailto:owner-hecnet at Update.UU.SE><owner-hecnet at Update.UU.SE
<mailto:owner-hecnet at Update.UU.SE>>*On Behalf Of*Paul Koning
*Sent:*Sunday, December 12, 2021 10:29 AM
*To:*hecnet at update.uu.se <mailto:hecnet at update.uu.se>
*Subject:*Re: [HECnet] native Dup sync line revisited -->
preliminary tests reveals problems
On Dec 11, 2021, at 7:41 PM, R. Voorhorst
<R.Voorhorst at swabhawat.com <mailto:R.Voorhorst at swabhawat.com>>
wrote:
L.S.
This is the follow-up from the Dup-without-Kdp in character
mode discussion somewhat earlier, where I stated it was not
supported per the specifications in Simh comments and Mark P
had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node
Rsx-11M+ test set, used for specific Decnet testing for
Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the
native (non-kdp) Dup. This one in multipoint mode is character
based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode,
this would establish sufficient proof for a well-functioning
character based synchronous line.
Yes, if you use TCP mode. ?It's not likely to work in UDP mode
because then the DMC emulation expects to get a full DDCMP frame
in a single UDP packet. ?But in TCP mode it just picks apart the
byte stream.
When the Dup line is interfaced to a Dmc line, the test
reveals flapping line behaviour: line up -? circuit fault ?
line down; when trying to transfer data an immediate circuit
fault appears.
When the Dup is interfaced to another Dup, there is packet
exchange so basically it should be able to work. However,
although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are transferred,
the receiver complains about bad header as well as bad data
crc checksums, so the packets are somewhat mangled. ?It
prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF
01 28 04 01 40 02 02 00 .........(..@ <mailto:..@>...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D
46?????????????????????????????? .....F
DBG(10561953465)> DUP RCV:? rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet? len: 22
DBG(10561953465)> DUP PKT:*Data Message, Count: 12, Num: 1,
Flags: SQ, Resp: 0,_HDRCRC: BAD, DATACRC: BAD_*
...
Per Mark P?s comment that some kind of filtering takes place
in non-kdp dup mode, that might indicate that the source of
the problems could be located in that corner.
That behaviour needs to be examined.
I wonder what kind of filtering that might be. ?The header ?looks
completely normal for a DDCMP data frame, it indicates a data
length of 12 bytes which matches what you see in that packet. ?12
would be the expected length of a Routing Init message, normally
the first data packet sent after DDCMP startup is complete. ? Then
again, its contents make no sense as an Init message. ? Sending
node 1.40, does that seem right? ?But the "tiiinfo" (node type
etc.) is 0x40 which isn't valid. ?Nor is the routing version
(0.0.15) or the hello timer value (0).
Could it be that one side is set in TELNET mode while the other is
not? ?The settings must match or 0xff bytes are mishandled.
paul
12:28 a.m.
Err.. Well I stand corrected. The logic I was referring to was for generic pack
transmission through TMXR connected lines. The APIs which provide that packet delivery
functionality aren?t used for DDCMP connected circuits (I forgot this since it was 8 or 9
years ago). Instead, as you said, the packet data itself contains the needed length
information. The APIs I was referring to are tmxr_get_packet_ln_ex()and
tmxr_put_packet_ln_ex(). The DDCMP circuits have framing logic code located in
pdp11_ddcmp.h and they use ddcmp_tmxr_get_packet_ln() and ddcmp_tmxr_put_packet_ln().
Another protocol which had imbedded framing logic and packet sizes could implement its own
{protocol}.h which handled that particular protocol framing and length details and yet
still use the TMXR layer for connectivity and transport.
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of Paul
Koning
Sent: Sunday, December 12, 2021 1:27 PM
To: hecnet at update.uu.se
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
So... if DUP-only mode using TMXR framed transmission which throws in a size field on TCP,
that would imply UDP mode should be used instead. Right?
paul
On Dec 12, 2021, at 1:46 PM, Mark Pizzolato - Info Comm <Mark at
infocomm.com<mailto:Mark at infocomm.com>> wrote:
The byte count is absolutely needed in TCP mode since the byte count describes the packet
boundaries on the wire. UDP mode is already packets hence the insertion of the packet
length preceding the data so the next layer doesn?t (in the device simulation) doesn?t
have to be aware of TCP or UDP.
From: owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>> On Behalf
Of Paul Koning
Sent: Sunday, December 12, 2021 10:42 AM
To: hecnet at update.uu.se<mailto:hecnet at update.uu.se>
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
You mean DUP-alone? KMC-DUP is compatible with DMC, right? And that sends (in TCP mode)
the frames as-is, no byte count since none is needed.
paul
On Dec 12, 2021, at 1:37 PM, Mark Pizzolato - Info Comm <Mark at
infocomm.com<mailto:Mark at infocomm.com>> wrote:
The functioning DUP simulation only sends packets. If the connection is TCP, then a 2
byte packet size is stuffed ahead of the packet data on transmit and the receiving side
strips this from the data presented to the simulated system. In UDP mode, the UDP packet
size is stuffed into the beginning of the packet buffer and that size is then also
stripped just like the TCP case.
The problems that Reindert is seeing are probably related to timing of byte delivery into
the simulation or timing of successive packets being delivered which may possibly overrun
buffer space in the simulated OS.
From: owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE>> On Behalf
Of Paul Koning
Sent: Sunday, December 12, 2021 10:29 AM
To: hecnet at update.uu.se<mailto:hecnet at update.uu.se>
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals
problems
On Dec 11, 2021, at 7:41 PM, R. Voorhorst <R.Voorhorst at
swabhawat.com<mailto:R.Voorhorst at swabhawat.com>> wrote:
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion somewhat
earlier, where I stated it was not supported per the specifications in Simh comments and
Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test set, used for
specific Decnet testing for Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the native (non-kdp) Dup. This one
in multipoint mode is character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would establish
sufficient proof for a well-functioning character based synchronous line.
Yes, if you use TCP mode. It's not likely to work in UDP mode because then the DMC
emulation expects to get a full DDCMP frame in a single UDP packet. But in TCP mode it
just picks apart the byte stream.
When the Dup line is interfaced to a Dmc line, the test reveals flapping line behaviour:
line up - circuit fault ? line down; when trying to transfer data an immediate circuit
fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so basically it should
be able to work. However, although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are transferred, the receiver complains
about bad header as well as bad data crc checksums, so the packets are somewhat mangled.
It prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01 40 02 02 00
.........(..@<mailto:..@>...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp: 0, HDRCRC:
BAD, DATACRC: BAD
...
Per Mark P?s comment that some kind of filtering takes place in non-kdp dup mode, that
might indicate that the source of the problems could be located in that corner.
That behaviour needs to be examined.
I wonder what kind of filtering that might be. The header looks completely normal for a
DDCMP data frame, it indicates a data length of 12 bytes which matches what you see in
that packet. 12 would be the expected length of a Routing Init message, normally the
first data packet sent after DDCMP startup is complete. Then again, its contents make no
sense as an Init message. Sending node 1.40, does that seem right? But the
"tiiinfo" (node type etc.) is 0x40 which isn't valid. Nor is the routing
version (0.0.15) or the hello timer value (0).
Could it be that one side is set in TELNET mode while the other is not? The settings must
match or 0xff bytes are mishandled.
paul
12:46 a.m.
And for those who do Tops10, a DN87 has by default DQ11 for speaking SYNC ddcmp.
-P
From: "Mark Pizzolato - Info Comm" <Mark
at infocomm.com>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Sunday, December 12, 2021 6:28:25 PM
Subject: RE: [HECnet] native Dup sync line revisited --> preliminary tests
reveals problems
Err.. Well I stand corrected. The logic I was
referring to was for generic pack
transmission through TMXR connected lines. The APIs which provide that packet
delivery functionality aren?t used for DDCMP connected circuits (I forgot this
since it was 8 or 9 years ago). Instead, as you said, the packet data itself
contains the needed length information. The APIs I was referring to are
tmxr_get_packet_ln_ex() and tmxr_put_packet_ln_ex() . The DDCMP circuits have
framing logic code located in pdp11_ddcmp.h and they use
ddcmp_tmxr_get_packet_ln() and ddcmp_tmxr_put_packet_ln() . Another protocol
which had imbedded framing logic and packet sizes could implement its own
{protocol}.h which handled that particular protocol framing and length details
and yet still use the TMXR layer for connectivity and transport.
12:49 a.m.
By the way. The logs that were included early on complained about
checksum errors, but looked like they understood things pretty fine
otherwise.
Could there be some error in the CRC calculation in simh compared to
what DEC is doing? I didn't fancy computing the CRC to verify if it was
correct, but I guess someone could do that?
I need to learn a little better how to compute the CRC before I try
doing that. It's one of those things I've never looked enough at.
Johnny
On 2021-12-13 00:28, Mark Pizzolato - Info Comm wrote:
Err.. Well I stand corrected.? The logic I was
referring to was for
generic pack transmission through TMXR connected lines.? The APIs which
provide that packet delivery functionality aren?t used for DDCMP
connected circuits (I forgot this since it was 8 or 9 years ago).
Instead, as you said, the packet data itself contains the needed length
information.? The APIs I was referring to are tmxr_get_packet_ln_ex()and
tmxr_put_packet_ln_ex().? The DDCMP circuits have framing logic code
located in pdp11_ddcmp.h and they use ddcmp_tmxr_get_packet_ln() and
ddcmp_tmxr_put_packet_ln().? Another protocol which had imbedded framing
logic and packet sizes could implement its own {protocol}.h which
handled that particular protocol framing and length details and yet
still use the TMXR layer for connectivity and transport.
*From:* owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> *On Behalf
Of *Paul Koning
*Sent:* Sunday, December 12, 2021 1:27 PM
*To:* hecnet at update.uu.se
*Subject:* Re: [HECnet] native Dup sync line revisited --> preliminary
tests reveals problems
So... if DUP-only mode using TMXR framed transmission which throws in a
size field on TCP, that would imply UDP mode should be used instead. ?Right?
paul
On Dec 12, 2021, at 1:46 PM, Mark Pizzolato - Info Comm
<Mark at infocomm.com <mailto:Mark at infocomm.com>> wrote:
The byte count is absolutely needed in TCP mode since the byte count
describes the packet boundaries on the wire.? UDP mode is already
packets hence the insertion of the packet length preceding the data
so the next layer doesn?t (in the device simulation) doesn?t have to
be aware of TCP or UDP.
*From:*owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>>*On
Behalf Of*Paul Koning
*Sent:*Sunday, December 12, 2021 10:42 AM
*To:*hecnet at update.uu.se <mailto:hecnet at update.uu.se>
*Subject:*Re: [HECnet] native Dup sync line revisited -->
preliminary tests reveals problems
You mean DUP-alone? ?KMC-DUP is compatible with DMC, right? ?And
that sends (in TCP mode) the frames as-is, no byte count since none
is needed.
paul
On Dec 12, 2021, at 1:37 PM, Mark Pizzolato - Info Comm
<Mark at infocomm.com <mailto:Mark at infocomm.com>> wrote:
The functioning DUP simulation only sends packets.? If the
connection is TCP, then a 2 byte packet size is stuffed ahead of
the packet data on transmit and the receiving side strips this
from the data presented to the simulated system.? In UDP mode,
the UDP packet size is stuffed into the beginning of the packet
buffer and that size is then also stripped just like the TCP case.
The problems that Reindert is seeing are probably related to
timing of byte delivery into the simulation or timing of
successive packets being delivered which may possibly overrun
buffer space in the simulated OS.
*From:*owner-hecnet at Update.UU.SE
<mailto:owner-hecnet at Update.UU.SE><owner-hecnet at Update.UU.SE
<mailto:owner-hecnet at Update.UU.SE>>*On Behalf Of*Paul Koning
*Sent:*Sunday, December 12, 2021 10:29 AM
*To:*hecnet at update.uu.se <mailto:hecnet at update.uu.se>
*Subject:*Re: [HECnet] native Dup sync line revisited -->
preliminary tests reveals problems
On Dec 11, 2021, at 7:41 PM, R. Voorhorst
<R.Voorhorst at swabhawat.com
<mailto:R.Voorhorst at swabhawat.com>> wrote:
L.S.
This is the follow-up from the Dup-without-Kdp in character
mode discussion somewhat earlier, where I stated it was not
supported per the specifications in Simh comments and Mark P
had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node
Rsx-11M+ test set, used for specific Decnet testing for
Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the
native (non-kdp) Dup. This one in multipoint mode is
character based and is driven through a Rsx Ddcmp software
driver to participate in Decnet communications.
If Simh Dup simulation is supported in native character
mode, this would establish sufficient proof for a
well-functioning character based synchronous line.
Yes, if you use TCP mode. ?It's not likely to work in UDP mode
because then the DMC emulation expects to get a full DDCMP frame
in a single UDP packet. ?But in TCP mode it just picks apart the
byte stream.
When the Dup line is interfaced to a Dmc line, the test
reveals flapping line behaviour: line up -? circuit fault ?
line down; when trying to transfer data an immediate circuit
fault appears.
When the Dup is interfaced to another Dup, there is packet
exchange so basically it should be able to work. However,
although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are
transferred, the receiver complains about bad header as well
as bad data crc checksums, so the packets are somewhat
mangled. ?It prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D
DF 01 28 04 01 40 02 02 00 .........(..@ <mailto:..@>...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D
46?????????????????????????????? .....F
DBG(10561953465)> DUP RCV:? rxnexttime=10561870955 (-20000
usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet? len: 22
DBG(10561953465)> DUP PKT:*Data Message, Count: 12, Num: 1,
Flags: SQ, Resp: 0,_HDRCRC: BAD, DATACRC: BAD_*
...
Per Mark P?s comment that some kind of filtering takes place
in non-kdp dup mode, that might indicate that the source of
the problems could be located in that corner.
That behaviour needs to be examined.
I wonder what kind of filtering that might be. ?The header
?looks completely normal for a DDCMP data frame, it indicates a
data length of 12 bytes which matches what you see in that
packet. ?12 would be the expected length of a Routing Init
message, normally the first data packet sent after DDCMP startup
is complete. ? Then again, its contents make no sense as an Init
message. ? Sending node 1.40, does that seem right? ?But the
"tiiinfo" (node type etc.) is 0x40 which isn't valid. ?Nor is
the routing version (0.0.15) or the hello timer value (0).
Could it be that one side is set in TELNET mode while the other
is not? ?The settings must match or 0xff bytes are mishandled.
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
1:23 a.m.
On Dec 12, 2021, at 6:49 PM, Johnny Billquist <bqt
at softjar.se> wrote:
By the way. The logs that were included early on complained about checksum errors, but
looked like they understood things pretty fine otherwise.
Could there be some error in the CRC calculation in simh compared to what DEC is doing? I
didn't fancy computing the CRC to verify if it was correct, but I guess someone could
do that?
I did, the error message is correct. I have a CRC (in PyDECnet) that's been tested
against the software DDCMP in RSTS, which in turn has been tested against a DMC.
paul
1:30 a.m.
On 2021-12-13 01:23, Paul Koning wrote:
Interesting. So the CRC is indeed incorrect. I wonder what generated the
CRC then, or how it got corrupted. Because the DDCMP header for sure
looked perfectly correct. I did decode that much.
Which would suggest that it's just a badly generated CRC on the sender side.
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 Dec 12, 2021, at 6:49 PM, Johnny Billquist
<bqt at softjar.se> wrote:
By the way. The logs that were included early on complained about checksum errors, but
looked like they understood things pretty fine otherwise.
Could there be some error in the CRC calculation in simh compared to what DEC is doing? I
didn't fancy computing the CRC to verify if it was correct, but I guess someone could
do that?
I did, the error message is correct. I have a CRC (in PyDECnet) that's been tested
against the software DDCMP in RSTS, which in turn has been tested against a DMC.
3:15 p.m.
On Dec 12, 2021, at 6:28 PM, Mark Pizzolato - Info
Comm <Mark at infocomm.com> wrote:
Err.. Well I stand corrected. The logic I was referring to was for generic pack
transmission through TMXR connected lines. The APIs which provide that packet delivery
functionality aren?t used for DDCMP connected circuits (I forgot this since it was 8 or 9
years ago). Instead, as you said, the packet data itself contains the needed length
information. The APIs I was referring to are tmxr_get_packet_ln_ex()and
tmxr_put_packet_ln_ex(). The DDCMP circuits have framing logic code located in
pdp11_ddcmp.h and they use ddcmp_tmxr_get_packet_ln() and ddcmp_tmxr_put_packet_ln().
Another protocol which had imbedded framing logic and packet sizes could implement its own
{protocol}.h which handled that particular protocol framing and length details and yet
still use the TMXR layer for connectivity and transport.
There are two cases, and they may be getting mixed up
One is HDLC, where packet framing is done by flag codes. Those are not represented in
the byte stream given to the device. Instead, the driver in some manner tells the device
that the frame is finished, and the device then generates the delimiting flag. To
represent this case in a TCP data stream, a frame size field is needed because there is no
other way to know where to place the simulated flag. A precise implementation would use a
bit count for the size because HDLC permits sending of any number of bits, not just a
multiple of 8 bits. That's probably not used very often in practice, though.
The other case is any character oriented protocol, such as BISYNC or DDCMP. In those, the
frame boundaries ARE represented in the byte stream supplied and read by the software. So
for these, the right encoding is to carry just the bytes, no additional metadata. If the
device has an "insert SYN bytes" feature, that needs to be emulated (by actually
sending those SYN bytes) so that a "SYN search" function at the receiving end
will find those bytes to exit the search mode. Even though emulated devices don't
have byte framing (the underlying connection carries whole bytes, properly framed) you
still need that search feature because software may use that for error recovery. For
example, if a DDCMP engine sees a header CRC error it would typically drop into SYN search
mode to skip over the data portion of the frame (at least usually; it would stop skipping
early if there happens to be a long-enough sequence of SYN bytes in the data field).
So if the plain sync device emulation were to do the above, that would give us an
emulation that interoperates with the DMC emulation if the software controlling the device
is running DDCMP.
Finally, as for multipoint, indeed that's not in the current emulation. It's not
clear how useful that would be, and I'm not sure how to make it work on emulated
connections. It could be done when driving real serial ports. Minimally those ports
would need transmit enable control on the tributary stations even if full duplex is used,
and for half duplex you'd of course need full modem control signalling.
paul
23 Dec
23 Dec
2:35 a.m.
On Dec 13, 2021, at 9:15 AM, Paul Koning
<paulkoning at comcast.net> wrote:
...
So if the plain sync device emulation were to do the above, that would give us an
emulation that interoperates with the DMC emulation if the software controlling the device
is running DDCMP.
More on this...
I built an M+ system with DUP lines, and unlike what was reported in this thread, I did
NOT see problems talking to other things (like PyDECnet or DMC emulation) that expect
plain data without frame length fields. I don't see frame lengths in the trace.
I don't understand this because the code is clearly there in the emulator, so
apparently it's not being hit. Not by DECnet/RSX anyway. More to be studied.
paul
8:56 p.m.
On Dec 22, 2021, at 8:35 PM, Paul Koning
<paulkoning at comcast.net> wrote:
I think the answer is as follows:
1. sim_tmxr has a get_packet and put_packet API, which inserts packet lengths ahead of the
data when in TCP mode.
2. That API is NOT used by any DEC sync device emulation. Instead, both DUP and DMC
buffer a packet within that device emulation, and use the get or put a character API of
sim_tmxr do deal with the actual data transfer. Those functions don't use length
fields.
3. The only place I see the packet API used are the CH11 (ChaosNet) device emulation for
PDP10 and PDP11, and in the H316 emulator. I haven't looked to see if that is
appropriate since it doesn't relate to the immediate subject under discussion.
So, Reindert, I'm wondering how you got it to send those length fields because there
isn't any way I can see in pdp11_dup.c for that to happen. A SIMH trace of the device
when it's not doing what you want would be interesting.
paul
On Dec 13, 2021, at 9:15 AM, Paul Koning
<paulkoning at comcast.net> wrote:
...
So if the plain sync device emulation were to do the above, that would give us an
emulation that interoperates with the DMC emulation if the software controlling the device
is running DDCMP.
More on this...
I built an M+ system with DUP lines, and unlike what was reported in this thread, I did
NOT see problems talking to other things (like PyDECnet or DMC emulation) that expect
plain data without frame length fields. I don't see frame lengths in the trace.
I don't understand this because the code is clearly there in the emulator, so
apparently it's not being hit. Not by DECnet/RSX anyway. More to be studied.
13 Dec
13 Dec
1:35 a.m.
Reindert,
You?ve always come along with the most complicated configurations for testing. ?
As a result of the potential complexity, we haven?t proved that we could ?walk? before we
try to ?run?.
Complexities I see in this case involve:
1. Phase I to Phase IV.
2. Triple nodes.
3. Multi-point mode ? this was absolutely never expected to be supported.
I can envision several basic test cases to test to see if we can ?walk?:
1. A 2 node configuration with DUP connected to DUP. Test this using TCP and UDP.
2. A 2 node configuration with DUP connected to DMC. Test this using TCP and UDP.
These systems should NOT have more than one disk or any other devices configured.
You should try things both WITH and WITHOUT idle detection enabled.
If you get failures, then please provide a way for me to get the disk images and
configuration files and instructions how to reproduce the failures (remember I?m not a
PDP11 user) and I?ll see what needs to be done.
FYI:
In the KDP case, to transmit packets the KDP gathers packet data from the simulated system
and then uses the DUP?s packet complete logic to send the data after first generating the
CRC (using ddcmp_crc16 from pdp11_ddcmp.h). The simulated PDP11 never commands the DUP
device. In the DUP to DUP case, the simulated system outputs bytes via the DUP?s
registers and when an outgoing packet is complete (which should include the CRC generated
within the simulated PDP11 system).
Thanks.
* Mark
From: R. Voorhorst <R.Voorhorst at swabhawat.com>
Sent: Saturday, December 11, 2021 4:42 PM
To: hecnet at Update.UU.SE
Cc: Mark Pizzolato - Info Comm <Mark at infocomm.com>
Subject: native Dup sync line revisited --> preliminary tests reveals problems
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion somewhat
earlier, where I stated it was not supported per the specifications in Simh comments and
Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test set, used for
specific Decnet testing for Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the native (non-kdp) Dup. This one
in multipoint mode is character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would establish
sufficient proof for a well-functioning character based synchronous line.
When the Dup line is interfaced to a Dmc line, the test reveals flapping line behaviour:
line up - circuit fault ? line down; when trying to transfer data an immediate circuit
fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so basically it should
be able to work. However, although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are transferred, the receiver complains
about bad header as well as bad data crc checksums, so the packets are somewhat mangled.
It prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01 40 02 02 00
.........(..@<mailto:..@>...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp: 0, HDRCRC:
BAD, DATACRC: BAD
DBG(10561955696)> DUP PKT: Line0: >>> XMT Packet len: 8
DBG(10561955696)> DUP PKT: Control: Type: 2 (NAK) Reason: 1 (HCRC), Flags: SQ, Resp: 0
DBG(10561955696)> DUP XMT: Line:0 0000 05 02 C1 00 00 01 85 A9
........
DBG(10561955696)> DUP XMT: rxnexttime=10561953465 (-541 usecs)
DBG(10561955696)> DUP PKT: dup_svc(dup=0) - 8 byte packet transmission complete
Per Mark P?s comment that some kind of filtering takes place in non-kdp dup mode, that
might indicate that the source of the problems could be located in that corner.
That behaviour needs to be examined.
So it looks that basically character mode Dup is (was meant to be) supported, but that it
needs to be tuned; this functional mode was probably not tested in the past as the accent
was on Ddcmp processing within Simh for Dmc/Dmr and Kdp/Dup device setups.
Reindert
1095
days inactive
1106
days old
18 comments
5 participants
participants (5)
-
bqt＠softjar.se -
Mark＠infocomm.com -
paulkoning＠comcast.net -
R.Voorhorst＠swabhawat.com -
roll＠stupi.com