[HECnet] Emulated XQ polling timer setting and data overrun

[Mark Pizzolato - Info Comm]

   On Jun 4, 2014 5:38 PM, Jean-Yves Bernier <bernier at pescadoo.net> wrote:   >   > At 4:59 PM -0700 4/6/14, Mark Pizzolato - Info Comm wrote:   >   > >Did you change the number of receive buffers?   >   > That does not seem possible under RSX.   >   >   > >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.   >   >   > I have tested commit 753e4dc9 on Mac OS 10.6, no virtualization. Both    > simh instances run on the same hardware. XQ set to different MAC    > addresses, since this is now enforced.   >   > Asynchronous network/disk IO may explain the uncommon transfer speed    > (I have filled a   RM03 in seconds).
I didn't notice you were not testing traffic between VAXes .   The threaded network I/o buffers more traffic which could naturally avoid overruns.
Disk I/o with RQ and RP are now asynchronous on VAX and PDP11.
- Mark