[daip] AIPS timeout

[Eric Greisen]

Anita M. S. Richards wrote:
> On Wed, 29 Oct 2008, Eric Greisen wrote:
> 
>> Anita M. S. Richards wrote:
>>> Dear 'Daip',
>>>
>>> We have a recurrent error with Dec08 AIPS, in that tasks time out
>>> AIPS 1: TASK HAS NOT BEGUN IN   15.1 SECONDS
>>> AIPS 1: Begin check for any 'standard' scratch files
>>> AIPS 1: Scratch files -- destroyed:    0  still active:    0
> 
> ...
>> apply to you.  A suggestion was made - that when memory is crowded (both real 
>> RAM and swap) then tasks will try to start but not proceed properly until the 
>> memory becomes available.  31DEC08 uses a lot more memory for the XAS TV than 
>> previous versions and pseudo-AP tasks like IMAGR now can take more memory 
>> than they used to take (although they take only what they need and only after 
>> the task has started).  Try looking at "top" to see how memory is used.  If 
>> your machines have < 1 Gbyte then I would expect problems in many cases.  At 
>> 1 or 2 Gbyte, it would take heavier loading to cause problems (e.g. multiple 
>> TVs, emacs, browsers, mail readers, etc.)

Another suggestion has been put forward:

For sites involving multiple machines with a central server, the 
assignment of the $DA00 areas for each of the multiple machines is 
significant.  We recommend that the directory

         $AIPS_ROOT/DA00/<hostname>

be a link to a directory actually on <hostname>.  Thus

/home/filehost/AIPS/DA00/PRIMATE/  -->  /home/primate/AIPS/DA00/

When a file is changed and then looked at over NFS, the change may take 
some seconds or even longer to propagate.  This task start up is looking 
for a change in the $DA00/TDD000004; file.  If that file is on filehost 
(to use our local names) but being read by primate, then it may take 
rather a long time for a change in the file contents to propagate.

Note that file locking is also problematical over NFS so sometimes file 
locks fail to be cleared promptly or at all when $DA00 is on the central 
server.

Eric Greisen