[Simh] VAX: CPU Usage and Network Timeout

[Tim Riker]

Tim Newsham wrote:
> Why would you want your machine to use less than 100% of its cpu?
> I mean, you paid for the whole cpu, might as well use it.  If
> you're concerned about other processes getting more share of
> the cpu, see the nice(1) and renice(p) man pages.

Others have commented, but here's my 2 bits.

My primary reason is that I'm often on a laptop. Running the cpu at 100%
causes the cpu to run at full clock speed the whole time simh is
running. This causes the laptop to resemble a hot pad. I could fry eggs,
but more likely I'll just fry my lap.

Another issue is battery life. I paid for my batteries too. I want to
get full use of those.

Yet another issue is when multiple copies of simh are running. This
happens when emulating 2000/Access Time Shared Basic on hp2100 hardware.
There is one host as the main system and another dedicated to i/o.

Having both of them sucking up 100% cpu means that the both perform
pretty poorly. If simh gave up cpu cycles when it was "idle" then both
systems would perform better.

Yet another issue is network performance. If the active task is asking
for 100% cpu, background processing runs a bit slower. When I ssh into a
machine running simh, the forked ssh process takes lags for a bit before
getting an equal slice of processing.

Now nice() or renice do not solve all these issue. Also they cause
poorer performance when simh is doing real work and there are other
applications running.

If simh would select() for a longer period of time when idle, and a very
short period of time when active, things would be much improved.

Now to the real issue: how do we "know" when simh is "idle"? The systems
we are emulating were not "green" systems that made idle calls. (at
least not any on the list that I'm aware of) so there is likely no hook
to watch that way. A few ideas:

1) watch for frequency of NOP calls. If there are a lot of them, assume
that we're in an idle loop, and sleep more. This could be an analog
range based on NOP frequency.

2) keep track of the program counter inside the emulated system. Perhaps
this would be the number of different values that the program counter
has hit between each "code burst" or "timer tick". There should be some
relationship between duplicate code execution and idleness.

2)
-- 
Tim Riker - http://rikers.org/ - TimR at Debian.org
Embedded Linux Technologist
BZFlag maintainer - http://BZFlag.org/ - for fun!