[HECnet] Emulated XQ polling timer setting and data overrun

[Mark Pizzolato - Info Comm]

On Thursday, June 05, 2014 at 12:04 PM, Johnny Billquist wrote:
On 2014-06-05 20:46, Mark Pizzolato - Info Comm wrote:
On Thursday, June 05, 2014 at 10:53 AM, Johnny Billquist wrote:
On 2014-06-05 19:23, Paul_Koning at Dell.com wrote:

On Jun 5, 2014, at 12:47 PM, Johnny Billquist <bqt at softjar.se> wrote:

Interesting. I still have real network issues with the latest simh
talking to a real PDP-11 sitting on the same physical network. So
you seem to have hit sime other kind of limitation or something...

I wouldn't think that traffic between PDP11 systems would put so much
data in flight that all of the above issues would come into play.

Hmmm...Grind...Grind... I do seem have some vague recollection of an
issue with some DEQNA devices not being able to handle back-to-back
packets coming in from the wire.   This issue might have been behind DEC's
wholesale replacement/upgrading of every DEQNA in the field, and it also
may have had something to do with the DEQNA not being officially
supported as a cluster device...

Hey, just do:

            sim> SET XQ TYPE=DELQA-T

and your all good.   :-)   Too bad you can't just upgrade real hardware like
that.

Uh... It's the PDP-11 that have problems receiving packets, not simh.

I knew that.   It was a joke.   Notice ":-)"....

Also, my PDP-11 already have a DELQA-T. :-) Finally, of course a simulated
PDP-11 running on a fast machine will be able to output data at a high rate.
Why would it not?

It would.   I never argued that it wouldn't.

Two real PDP-11 systems do not get any problems.
Sending data from a real PDP-11 to the one in simh (or whatever) does not
have any problems either.
It is only when you send lots of data from a simulated machine (be that a
PDP-11 or a VAX) to a real PDP-11 that you get these issues. I would suspect
you should be able to see similar issues if the receiving end was physical VAX
as well.

I just tried to fire up the old VAX Station 4000 I've got on the shelf.   This system hasn't been booted in more than 5 years (maybe 10).   When it last booted, it didn't have any working disks, so I was planning to boot it into a cluster from my simh host.   Without a disk, I'll have to create a RAM disk to test file copies from simh side to real side...   I haven't had a monitor for the system for at about 15 years, but the last booting activities worked fine with a cable to one of the serial ports.   But today it doesn't work.   :-(

The problem is also partly DECnet. DECnet do not seem to keep packets that
arrive out of order. So if a packet in a sequence is lost, DECnet is going to
retransmit all packets from that point forward. Meaning that when the
session timer times out, the retransmission happens, and then you will yet
again drop a packet in the whole sequence of packets that are sent. Each
time the session timer times out, DECnet also do a backoff on the timeout
time of that timer, until the session timer is about 2 minutes. So after a while
you end up with DECnet sending a burst of packets, some of which are lost. It
then takes about 2 minutes before a retransmission happens, at which point
you get another 2 minute timeout. Thus, performance sucks.
TCP/IP is better (well, my TCP/IP anyway), in that when I loose a packet, I still
keep whatever later packets I get, so after a while I get to a stable mode
where TCP only sends one packet at a time, since the window is full. Only
actually lost packets needs to be retransmitted, so I actually do get to this
stable point.

OK.   So you sound like you really need a throttling option for the LAN devices.   I'll look over the throttling logic in the bridge and fold in something similar.

- Mark