[HECnet] Emulated XQ polling timer setting and data overrun

[Mark Pizzolato - Info Comm]

On Wednesday, June 04, 2014 at 4:08 PM, Jean-Yves Bernier wrote:
At 10:44 AM -0700 4/6/14, Mark Pizzolato - Info Comm wrote:

If you're going to drive this deeply into testing it would really be
best if you ran with the latest code since your results may ultimately
suggest code changes, AND the latest code may behave significantly
different than the older versions.

Independent of which codebase you're running, and since you're now
tweaking the behavior of the simulated hardware, you may want to look
at sim> SHOW XQ STATS and try to analyze the relationship between these
stats and the ones the OS sees.

Also, you may want to explore what happens if:

NCP> DEFINE LINE QNA-0 RECEIVE BUFFER 32

Is done prior to starting your network...     The limit of 32 may be
different on different Operating Systems...

Once again the latest code is available from:
https://github.com/simh/simh/archive/master.zip



Mark, what kind of magic did you perform on XQ?

I tried commit 753e4dc9 and overruns are gone. No more NFT/FAL hangups.
Transfer speed is higher than ever : 10000. blocks in 4 seconds. I can't believe
it. This ROCKS.

Significant changes have been made since 3.9, but I haven't seen substantial throughput differences.

Did you change the number of receive buffers?

Maybe the secret is here:

sim> sh xq
XQ	address=17774440-17774457, vector=120, MAC=08:00:2B:AA:BB:01
	type=DEQNA, polling=disabled, sanity=OFF
	leds=(ON,ON,ON)
	attached to eth0


"polling=disabled"

That really only indicates that you're running on a platform which can do Ethernet network I/O in a parallel thread.   Most platforms did not use the threaded model previously.   Previously, in 3.9, Polling was still necessary since the simulator didn't really support an asynchronous I/O model.   The latest codebase has support for asynchronous network AND disk I/O.   On the current codebase if you've got threads available, then network reads and writes are performed asynchronously and interrupts (I/O completion) is triggered with a few microseconds of latency.   As I recall from earlier in these threads, you're running under CentOS on VirtualBox.   You didn't mention what host OS you're running on.     In any case, the threaded model might just work better in the virtual environment.

- Mark