[daip] problems running multiple tv displays on different desktops

[Susan Neff]

Okay - some followup here, and a new line of questions.


I thought a bit about how I wanted to use my machine, 
and decided I'd like to have the option of running 4 
tvs on the four different "desktops" I have 
available.  I think that means I'd want to quadruple 
the parameters in  /etc/sysctl.conf
that support TVs.   After talking with my sysadmin, 
David Friedlander, I changed the parameters 
interactively (i.e. not in the file, just real-time), 
to see how they worked - with the idea of changing 
them in the sysctl.conf file once they seemed to be 
doing what I wanted.  I'm running on a machine with 4 
cores and 32GB memory (so it seemed okay to use 68MB 
for TVs.  ??Perhaps this is misguided, and I should be 
less greedy??)


I was able to quadruple shmmax, shmseg, and shmall.   
I wasn't able to change shmmni interactively, so it 
stayed at 32 (I gather that I can change it but only 
in the file and with a reboot).  (I found online that 
this limits the number of total segments that can be 
shared, but I don't really understand what this means, 
or what a segment is.)   I then loaded the machine up, 
started several TV's etc.   I was also running some 
heavy-user CASA jobs at the same time.


Sometime last night, the machine froze up.  I had to 
power cycle it this morning.  For a few hours before 
it froze up, there were occasionally a series of error 
messages from the kernel saying that it was out of 
paging space, switching on emergency paging, switching 
off emergency paging, etc.   At the end, just before 
it froze, there were also a bunch of error messages 
reporting attempted breakins.  All of the breakins 
appear to be from the Goddard IT Security folks - 
apparently they run automated scans every few days,  
to try to break into computers on center.


So, I'm trying to figure out what caused the freezeup 
and how to tune the machine so I don't shoot myself in 
the feet.  Would the non-changing of the shmmni  
value, when I changed the other parameters, have let 
the computer get into some state where this could 
happen? (in which case, I could just go ahead and do 
the changes in the file, including the shmmni change 
also).   Would the attack on the machine by the 
security folks have taxed an already near-the-limit 
machine so it froze?

Or, does this just sound like an over-greedy user?  Is 
it likely to be the case that running big AIPS jobs 
(spflg, imagr) and big CASA jobs (sort, mfs clean)  at 
the same time caused some sort of bad collision?  (in 
which case, I might need to limit the TV's, or run 
fewer jobs at once)  Other likely possibilities?   
What does the shared memory stuff required by AIPS do 
to the memory available for CASA?   This is all a bit 
of a surprise - I'm used to and expected that if I 
tried to run too much at one time, it would all just 
run really slowly - not hogtie the machine.

......

And, my second line of questions (I hope you meant it 
when you said "there are no dumb questions"):

Our IT security office apparently runs these attempted 
breakin scans several times a week, and they seem to 
like the open ports used by MSSERV, TVSERV and 
TKSERV.  I'm running AIPS standalone on this desktop, 
so do I need to have these ports open for AIPS to 
work?   What about the XAS x-windows?

I apparently have the option to turn off all incoming 
connections.   It will interfere with my being able to 
login from home, and it will keep the sysadmins from 
being able to check on things without coming to my 
office, so I'd prefer to not do this if I don't need 
to.  But, I was wondering if AIPS would run with all 
the ports closed.


A bunch of questions - thank you in advance for your 
answers.

-s-



On 2/7/12 11:13 AM, Wes Young wrote:
> There are no dumb questions.
>
> Yes allocating additional shared memory will decrease the amount of total memory your machine has available for running AIPS tasks. In practice it's a pretty small amount of memory compared to what many machine have installed, i.e. maybe 16 or 32 MB out of 2-16GB  so the impact is likely to be pretty small.
>
> I doubt "set ufs" parameters would have any effect on the Mac. I found that if I striped my non-system disks I got some improvement in disk IO.
>
> wes
> wyoung at aoc.nrao.edu
>
>
> On Feb 7, 2012, at 9:00 AM, Susan Neff wrote:
>
>> Hi again, Wes,
>>
>> Does the shared memory allocation impact the memory available for other AIPS tasks to use?  Does it "reserve" that much memory for the TV?   Or are they independent?  (If they impact the performance of other AIPS tasks,
>> I might want to not run on too many TV's at once).
>>
>> The FAQ also talks about improving overall AIPS performance on a Solaris machine by changing the settings to the following - will these help any on a Mac (OS X)?:
>>
>> set ufs:ufs_HW=6291456
>> set ufs:ufs_LW=4194304
>> set priority_paging=1
>>
>> Sorry if these are dumb questions.
>>
>> Thanks,
>> -s-
>>
>>
>> On 2/7/12 10:37 AM, Wes Young wrote:
>>> Susan,
>>>
>>> In short yes, you will need to increase the amount shared memory allocation. I would guess you would need to double everything but kern.sysv.shmmin. It may be that you can get by with doubling kern.sysv.shmmax but I'm not sure.
>>>
>>> wes
>>>
>>> wyoung at aoc.nrao.edu
>>>
>>>
>>>
>>> On Feb 7, 2012, at 8:22 AM, Susan Neff wrote:
>>>
>>>
>>>>    However, I don't really
>>>> understand how shared memory works - do I need to
>>>> double/triple/...   the shared memory value for
>>>> kern.sys.shmmax  in /etc/sysctl.conf   if I want to
>>>> use two/three/...  TV displays at the same time?   Is
>>>> there something else I should change?   I'm running
>>>> with a 23 inch display, 1920 x 1200 pixels.
>>>>
>>>>
>>>> Thanks very much,
>>>> Susan
>>>>
>>>> _______________________________________________
>>>> Daip mailing list
>>>>
>>>> Daip at listmgr.cv.nrao.edu
>>>> http://listmgr.cv.nrao.edu/mailman/listinfo/daip
>> _______________________________________________
>> Daip mailing list
>> Daip at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/daip