[HECnet] FW: native Dup sync line revisited --> preliminary tests --> update logging Dup-Dmc communications

[Mark Pizzolato - Info Comm]

Your data proves that there are problems.

I can't debug or troubleshoot a pdf document.

Please provide minimal working pieces.

Thanks.

- Mark

On Dec 13, 2021 10:41 PM, "R. Voorhorst" <R.Voorhorst at swabhawat.com> wrote:

L.S.



Testing as it was done on the dup-dmc combination with the dmc side used as kind of proven reference.

The initial section is a log (see pdf link: https://drive.google.com/file/d/1-m3h5fpvv3JHHUYWi3zgX_qtfm3g1aRs/view?usp=sharing as Hecnet seems to disallow pdf attachments) of a dmc-dmc connection that works out of the box and leads to a Decnet adjacency up message.

Note that the dmc logging is not exactly time-sequential, therefor it is separated according to time stamp which reveals that xmt and rcv logging is not strictly ordered with respect to flow of time.

This snippet shows the exact packets that are exchanged with their correct crc checksums.



The dup-dmc logging in the second section below, can be arranged in lockstep with xmt/rcv and reveals an interesting anomaly where it seems somewhere in the beginning in dup two packets are coalesced, that at least is present in the dup logging, although the dmc does see it as two packets.

>From there onwards, dup-dmc are getting in a loop. It looks like the dup logging itself is neither consistent or constant (some lines are sometimes present and later on missing). The coalescing probably indicates some error(s) in dup simulation leading to the dmc dancing around with the dup in bad crc error reporting, although the checksums of the packets look ok, until some form of reset takes place and then it starts all over again.



Now it may be time to zoom in.



Reindert








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sonic.net/mailman/private/hecnet-list/attachments/20211214/08392190/attachment.htm>