[Simh] Device Timing Question

[J. David Bryan]

Rob,


On Sunday, October 7, 2012 at 18:04, Rob Jarratt wrote:

> The device I am emulating appears to be running too fast for the
> driver that uses it....

I've run into that problem several times before with the HP simulator.  OS 
software assumes that a device interrupt cannot occur before a certain 
amount of time has elapsed after initiation, and dire consequences accrue 
when it does.

As Mark noted, most devices are timed by instruction counts.  For example, 
a TTY output device may output a character every 100 instructions.  That 
provides for snappy screen output, but it is far faster than a real TTY 
operated on a real CPU (more on the order of a character every 100K 
instructions).  With the shorter time, interrupts occur far more frequently 
than they did with real hardware, and unless the driver and OS software can 
accommodate the higher rate, there may well be problems.

A simple fix is to work out how many instructions on the simulated CPU 
would elapse for a given device response time.  In the TTY case, interrupts 
would occur every 100 milliseconds (based on 10 cps).  An HP 1000 E-Series 
(for example) executed about 1580 instructions per millisecond, so setting 
the character output time to 158,000 instructions ensures that the driver 
and OS would see interrupts at about the same rate as the actual device 
would produce.

A more involved fix is to trace the code path through the OS and driver to 
determine how long interrupt servicing takes (in machine instructions) and 
then use that value as a lower bound on the character output time.

Timing I/O devices by instruction counts ensures that the target OS 
interrupt rate remains predictable regardless of the speed of the host 
system.  However, some devices (e.g., a TOD clock) must interrupt at a rate 
related to wall-clock time.  These are calibrated as Mark described.  In 
addition to clocks, devices that poll for input, such as terminals, also 
use calibrated timers to ensure that the poll rate remains constant across 
a variety of host system speeds.


> I have never fully understood the use of sim_activate, in particular
> what are the units of time that are passed to this routine? 

"sim_activate" sets the time in the future (measured in target machine 
instructions) when a device's unit service routine will be called.  For 
example, a TTY output routine might transmit a character and then call 
"sim_activate" to request that it be called again after 100,000 
instructions have elapsed.  When it is reentered, the next character is 
transmitted, and the process repeats until the entire buffer is sent.

The main difference between SIMH I/O and real hardware is that there are no 
asynchronous operations.  SIMH is event driven, and "sim_activate" 
establishes a list of events to process at varying times in the future.  An 
I/O operation, such as a terminal write or a disc seek, is broken down into 
a series of sequential operations with differing elapsed times that are 
handled by a unit's service routine.  As each is finished, the next is 
scheduled with "sim_activate" until the entire operation is complete.

                                      -- Dave