[Simh] 10ms delay on ethernet communications - the solution!

[Mark Pizzolato]

--- Boucher, François <boucher.francois at uqam.ca> wrote:

> Hi to all!
> 
> I did some more search and it appears that Mr Robert Supnik did
> modify in Oct 2006 the
> files PDP11/pdp11_xq.c and pdp11_xu.c to synchronize the polling of
> the Ethernet interface with the timer clock.
[ ... ]
> When I do a monitor system, I obtain a 2300 buffered IO rate per
> second, from a 800 buffered I/O rate per second.
> 
> That modification and tuning of 1300 polls per second gave us a
> 300% increase in Ethernet throughput!
> 
> Also, I did see by running PT_VAX.EXE that there is a slight
> performance penalty when I rise at 1300 polls per second the rate,
> but that penalty is of the order of passing from 25.0 VUPS to 23.9
> VUPS, for the performance gain of 300% Ethernet I/O.
>
> So, for my part, this case is closed, but I would appreciate any
> comments about further optimisation of the Ethernet driving of
> simh.

Francois,

Clearly you've observed part of the consequential trade off (i.e. the
reduction of available CPU cycles).  The other consequence of polling
more frequently than the clock tick, is that MANY more host CPU
cycles will be used and the efforts to "idle" the running simulator
when the simulated computer really isn't doing anything will be much
less effective.

You wouldn't need to poll as often if your network applications would
put more packets "on the wire" simultaneously.  This would let the
pcap kernel buffering gather more packets to pass to the simulator in
each poll.

As I recall, the original polling rate of 100/sec gave a simulator,
on a good computer at the time (circa 2002), the ability to drive
more than 10mbits/sec on a 100mbit LAN.  This seemed to fit well with
the original ethernet capabilities which were available when the Vax
was in it's prime.

It would seem possible that simh could be changed to honor the
specified poll value if idle detection wasn't enabled.

- Mark Pizzolato