[HECnet] native Dup sync line revisited --> preliminary tests reveals problems

[Mark Pizzolato - Info Comm]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sonic.net/mailman/private/hecnet-list/attachments/20211213/e61b509c/attachment-0001.htm>