[Simh] RE : RE : How to setup a simh VAX VMS cluster that handles more than 16 disks.

[Mark Pizzolato]

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

> You are sending me an interesting track to follow about the disk IO
> optimisation.
>  
> It makes sense to me that buffered disk IO would create the
described 
> inconsistencies.  If one would like to bypass this problem, how
would you
> recommend to modify the source code?
> Is there a replacement function that makes direct unbuffered IO to
the
> virtual disk container files that can be used in place of fwrite ?
> I did not check very much this aspect of the code, but I find your
inputs
> very very informative.

Well, simh could be restructured to use use a different set of
routines for simulated disk I/O.  This is hard since the current
routines used for disk I/O are also used for other I/O operations by
the simulator.  They also pass around FILE*'s which are then
sometimes used directly by other functions which take FILE*'s as an
argument.  If a restructuring was to be done, and disk block oriented
I/O were simulated by a separate library, then the various parts of
the various simulators could be converted to leverage this block
oriented I/O library.  The block oriented I/O library could be
implemented to use OS specific unbuffered I/O calls on a host
platform by host platform basis.  For example on Unix calls to open,
read, write, lseek, and close would be used.  On Windows, CreateFile,
ReadFile, WriteFile CloseHandle, etc would be used, on VMS QIO would
be used, etc.  When I looked back through the simh history it seems
that at one time Bob was thinking of separating the I/O to block
devices out from the existing code base and implementing a raw block
I/O library called sim_ra.c.  Clearly this never got far enough to
see the light of day, maybe you could get it going again.

> I was also rethinking about the polling of the ethernet interfaces.
> In the hardware world, we would use an  hardware interrupt to
> trigger the treatment
> of the receiving buffer.  In the simulator world, would it be
possible to 
> modify the source code of the simulator to do a software interrupt
that
> triggers the reading of the receiving buffer?

Well, the I/O structure of the simh is single threaded and all I/O
operations are done by explicit "cycle stealing" polling operations. 
Changing this architecture to one which was asynchronous would be a
rather significant change.  Before going there you should run your
plan by Bob Supnik.  

I saw your optimization efforts which yielded a 45% improvement in
speed.  In the 2002/2003 timeframe, I looked at inlining optimization
but the Read, Write, ReadB, WriteB, etc. routines you inlined didn't
do anything for me since the machines of the time didn't have large
enough caches to keep enough of the program in cache to provide any
benefit.  You went to optimize these calls since they were called
many times.  I looked at why they were called and noticed that many
of the calls were called from within loops which operated on blocks
of data(During DMA activities).  I wrote a couple of extra routines
which operated directly on blocks and brought the loops into called
routines.  These efforts significantly improved all I/O performance
in the vax simulator.  In any case, Bob rejected the changes I
submitted since they merely optimized the result but were implemented
with different logic than the original hardware implementation.  He
argued that the goal of simh was to preserve the computing record,
and my approach wasn't part of that.  He also argued that over time
Intel or commodity CPUs would continue to get faster so we didn't
need the extra.  Meanwhile, these days, many host CPUs will have
sufficiently large caches to hold the resulting simulator when all of
your inlines are included.  Inlines don't change the logic or
structure of the implementation, so they shouldn't meet Bob's first
argument.  I'd bet that if most folks get faster simulation with the
inline's in place, then Bob will adopt those changes.

- Mark

> Mark Pizzolato wrote:
>  
>> This "could" work as is if the I/O done by simh to the virtual
disk
>> container files was NOT done with the C runtime library (fopen,
>> fread, fwrite, fclose), and was done with direct unbuffered I/O to
>> the respective file storage.  Currently the buffering done by each
>> simh instance leads to inconsistencies since each simh instance
has
>> its own buffered data which the other simh instances have no
>> mechanism to synchronize.
>> 
>> - Mark Pizzolato