[HECnet] QNA Data overrun (Was: Same MAC address)

Johnny Billquist bqt at softjar.se
Mon May 26 01:14:26 PDT 2014


On 2014-05-26 01:37, Jean-Yves Bernier wrote:
At 1:00 AM +0200 26/5/14, Johnny Billquist wrote:

Well, that is not the full story... :-)

10.1>NCP SHO NOD 10.2 COU

Node counters as of 30-MAR-82 00:21:30

Remote node = 10.2 (SNAKE)

              1266   Seconds since last zeroed
          272319   Bytes received
              1723   Bytes sent
                821   Messages received
                373   Messages sent
                    1   Connects received
                    4   Connects sent
                    0   Response timeouts
                    0   Received connect resource errors
                    2   Node maximum logical links active


10.2>NCP SHO NOD 10.1 COU

Node counters as of 30-MAR-82 01:10:34

Remote node = 10.1 (SHARK)

              4212   Seconds since last zeroed
            13475   Bytes received
        1382813   Bytes sent
              2626   Messages received
              5177   Messages sent
                  26   Connects received
                    2   Connects sent
                  73   Response timeouts
                    0   Received connect resource errors
                    3   Node maximum logical links active

Aha. So it is 10.2 that gets timeouts when sending packets to 10.1. So 10.1 are dropping packets.

Good. Now, in which direction was the transfer attempted?

Summary of my last experiments:

Node A & node B inside VirtualBox (Linux) : that's the configuration i
am running since the beginning of this discussion.

Node A & node B on a same MacMini (BSD). VirtualBox out of the loop.
=> same problem.

Node A on a MacPro, node B on the MacMini. VirtualBox out of the loop
again.
=> same problem.

Node A inside VirtualBox Linux (MacPro), node B on the MacMini (BSD).
=> same problem.

We can rule out VirtualBox.

We can rule out a Linux/BSD/pcap problem.

We can rule out running multiple nodes on the same host (MAC addresses,
etc).

Two versions of simh were used, 3.6 and 3.9, in Mac and Linux build.

Right. And I never expected any of the things listed above to be the problem to start with.
This is a problem inside of DECnet on the simulated host. It gets packets faster than it can process them, so some packets are dropped.
Unfortunately DECnet deals very bad with systematic packet loss like this. You get retransmissions, and after a while the retransmission timeout backs off until you have more than a minute between retransmission attempts.

It is a known problem.

[ Note: since simh 3.7, set console pchar=37777777777 if you want to use
EDT/RMD/NTD at the console, took me an hour to figure. ]

:-)

Anyway, if you can get simh to throttle the ethernet interface, that might help you. (I don't remember offhand if it do support such functionality.)

	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



More information about the Hecnet-list mailing list