Subject: Re: IRIX 5.0.1 & MOPAC 6.0??

From: Roberto Gomperts <[email-masked]>
Date: Fri, 27 Aug 93 07:59:10 EDT

Your message dated: Thu, 26 Aug 93 12:45:35 EDT
|>  Dear netters,
|>  
|>  We recently upgraded one of our SGI servers to an Onyx running IRIX 5.0.1
|>  and have seen a problem running MOPAC 6.0 with ESP options compiled in. 
|>  Now when we run a MOPAC job, the machine is unable to execute any
|>  other programs. Things just won't run! Never seen anything like this before.
|>  Errors appear in the console window stating things like:
|>  
|>  NOTICE: dupreg - temporarily insufficient memory to allocate virtual swap space,
|>   process buttonfly [1592]
|>  
|>  	OR
|>  
|>  NOTICE: growreg - temporarily insufficient memory to expand region, process
|>  sybyl [1596]
|>  
|>  This does *not* happen on our other SGI server running IRIX 4.0.5. and if
|>  we use a copy of MOPAC 6.0 without the ESP modules compiled in, there is 
|>  no problem on the new Onyx...I'm now very suspicious that the problem 
|>  has something to do with the new OS and the ESP modules in MOPAC 6.0. 
|>  Anybody seen anything similar?
|>  Thanks in advance for any help!
|>  Greg Durst

Hi Greg,

I am responding to you via the net because the answer will benefit other people 
seeing the same problem on the new OS for Challenge/Onyx systems.

The origin of the problem has to do with new ways of allocating swap space. There 
is a new feature (for SGI): virtual swap space that will allow you to, on the fly,
correct this situation.

Become superuser (root) and issue the following sequence of commands:
touch /usr/tmp/vswap
swap -a -p2 -v2000000 /usr/tmp/vswap

Please read the man page of swap to get more info and what to do to ensure that 
the virtual swap space is there after a reboot.

The inappropriate default setting of the machine should be corrected in the next 
release of the OS.

I hope this helps and apologies for the inconvenience.

				-- Roberto

						Roberto Gomperts
						[email-masked]
						phone: (508) 562 4800
						Fax:   (508) 562 4755

"Gracias a la vida,
que me ha dado tanto ..."
        Violeta Parra

---

From: [email-masked] (Peter Shenkin)
Date: Fri, 27 Aug 93 08:38:12 -0400

> From: "Gregory L. Durst - DowElanco Discovery Research" <[email-masked]>

> We recently upgraded one of our SGI servers to an Onyx running IRIX 5.0.1
> and have seen a problem running MOPAC 6.0 with ESP options compiled in. 
> Now when we run a MOPAC job, the machine is unable to execute any
> other programs. Things just won't run! Never seen anything like this before.
> Errors appear in the console window stating things like:
> 
> NOTICE: dupreg - temporarily insufficient memory to allocate virtual swap space,
>  process buttonfly [1592]
> 
> 	OR
> 
> NOTICE: growreg - temporarily insufficient memory to expand region, process 
> sybyl [1596]
> 
> This does *not* happen on our other SGI server running IRIX 4.0.5...

This is probably a consequence of the way SGI allocates memory under
IRIX 5.0.1.  The differences between IRIX 3.x.x and 4.x.x in this regard
were discussed in the comp. chem. list a few weeks ago.  IRIX 5.x.x
changes the paradigm again.  I don't know the 5.x.x paradigm as well
as the other two, but my understanding is as follows:

	3.x.x: On process startup (or at malloc time, for processes
	  that use malloc), reserve as much swap+RAM as the total
	  size of the program.  This guarantees that any memory allocated
	  will be available if/when used, but is wasteful for 
	  Fortran programs that allocate array space for large
	  data sets that are rarely encountered.

	4.x.x: Reserve swap+RAM for a memory location when an attempt is 
	  made to access it -- not when memory is declared or malloc'ed 
	  by the process.  This makes for higher efficiency of resource 
	  use, but is non-deterministic: a program can be killed in mid-
	  execution if some process (not necessarily itself!) all of a 
	  sudden tries to access array elements that the system can't 
	  find physical resources for.  The OS then has to kill some 
	  process, and usually selects the largest -- which on occasion 
	  may be the X-server :-(.

	5.x.x: Reinstate the 3.x.x behavior, but allow the system
	  administrator to declare an arbitrary amount of "virtual
	  swap space.  If this amount is zero, then we get exactly
	  the 3.x.x behavior.  If it is high, then we get some 
	  approximation to the 4.x.x behavior.  (4.x.x has essentially
	  infinite virtual swap space.)

Though the precise nature of your difficulty is not clear to me from 
the wording of your error messages, it may be that what you need 
to do is allocate more virtual swap space.  See the manual entry 
on "swap -v" for a description and a brief discussion of this.
The man page suggests that you "SEE ALSO" swapctl(2).  My manual
doesn't have an entry for this, but the name would suggest that
it allows a process to control the allocation of (virtual?) swap
space for itself.

It is also possible that you simply don't have enough "real"
swap space on your Onyx to run these presumably very large
programs.  You can see how much swap space you have on either 
your Onyx or your 4.x.x system by issuing the command "swap -l".
Certainly your real swap space should be at least as large on
the Onyx as on your 4.x.x system.  If it isn't, increase it.
If it is, add virtual swap space.  If you've been happy with
the indeterminate allocation method on the 4.x.x server, you
ought to add an effectively infinite amount of swap space to
the 5.x.x Onyx.

	-P.
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************
Peter S. Shenkin, Box 768 Havemeyer Hall, Dept. of Chemistry, Columbia Univ.,
New York, NY  10027;  [email-masked];  (212) 854-5143
********************** Wagner, Beame, Screvane in '93! **********************