[HECnet] Emulated XQ polling timer setting and data overrun

[Jean-Yves Bernier]

[ Summary : File transfers between two simh PDP hang,
DECnet reports Data overruns and Response timeouts ]


At 2:14 AM +0200 26/5/14, Johnny Billquist wrote:

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.

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.)


The service   polling timer can be adjusted

SET XQ POLL={DEFAULT|4..2500}

Set to 100 by default.


Changing the polling timer makes a huge difference. Have a look at:

http://pastebin.com/AZ1U6bh3

Although it still hangs sometimes, reliability has vastly improved upon the erratic behavior of the beginning. Remember, the completion time was about 3 minutes.

We're almost there :)

This turns into an interesting challenge : optimize XQ service timer to make overruns the lowest possible. This depends on many factors, among them is the data sink bandwidth.

You may have flawless copy to TI:, but it will fail to disk. The terminal is actually throttling the transfer. Disks are faster, and emulated disks are order of magnitude faster than the original ones. Emulation is pushing DECnet to speeds it was never designed for.

I'm running here as low as 10 polls/sec. Maybe 50 would be optimal, and what about 500? I need a metrics. And tools. Here, I am using AT. to time a 100. blocks file transfer. Overruns and timeouts still raise slowly, but DECnet recovers happily most of the time.




-- 
Jean-Yves Bernier