vizstack-users — Mailing list for everyone who uses VizStack

[vizstack-users] Weight values in node_config.xml not working

[<Pet...@cs...>]

Hello,

I have four nodes being managed by Vizstack/SLURM (rviz[1-4]) running on Ubuntu 10.04 and would like to have rviz1 allocated jobs last by Vizstack.  According to the user guide I should be able to change the weight value for rviz1 to 1 in node_config.xml although this doesn't seem to have any effect ie rviz1 is still allocated first with viz-tvnc/viz-vgl etc scripts.  Any ideas?
I've tried 1.1-3 release and the latest source rev 350.

Cheers,
Peter

Peter Tyson
CSIRO IM&T - Advanced Scientific Computing
Gate 5 Normanby Road
Clayton Vic 3168
Ph +61 3 9545 2021

[vizstack-users] [Announcement] VizStack 1.1-3 released !

[Kumar, S. <shr...@hp...>]

VizStack 1.1-3 is out ! Users are recommended to upgrade from 1.1-2 from the usual place http://sourceforge.net/projects/vizstack/files/.

This is primarily a bugfix release. 

I'm pasting text from the announcement at http://vizstack.sourceforge.net/?p=102 below

----

I'm pleased to announce VizStack release 1.1-3. Download it NOW from SourceForge.

This release is primarily a bug-fix release.

 - VizStack now works well with SLURM version 2.10 and later. 
    Release 1.1-2 used to result in jobs not being cleaned up 
    properly, and SSM crashed after a while
 - Fixed issue in the resource allocator
 - Configure script now works on single GPU machines installed with SuSE Linux
 - Included functionality that was missing in 1.1-2 : clip_last_block for tiled displays.
 - Various other small changes to code and documentation

This release also includes one enhancement : viz-paraview can now use shared GPUs for 
parallel rendering. This is useful in the common case where the GPU rendering load 
for a model is much smaller compared to generation of the rendering commands. So, you 
can now put your many multi-core processors to use. VizStack will share the GPUs with 
multiple rendering processes, and configure ParaView for offscreen rendering. This should 
maximize your GPU and system utilization.

I'd highly recommend users of VizStack 1.1-2 to consider shifting to this release. All 
it takes is a package removal & package installation on all the nodes and you will be 
up and running !

Contributors for this release:

 * Peter Tyson (CSIRO): Found the interoperability issue with SLURM 2.10, and suggested the fix.
 * Simon Fowler (CSIRO): Pointed out the missing clip_last_block functionality and the bad merge
 * Wolfgang Dehn(HP): Found a SLURM nodelist expansion issue
 * Paul Melis : helped correct documentation

----

Cheers!
-- Shree

Re: [vizstack-users] Vizstack and SLURM issue

[Kumar, S. <shr...@hp...>]

Hi Peter,

Good to see that works. I had a look at the crash log you sent me, and that explains the need to restart the SSM. However, this issue also revealed one place where I was expecting everything would work; turns out not to be the case. 

I will fold this change into the trunk - and include it in the release 1.1-3.  Anybody who uses Slurm 2.10/Ubuntu 10.04 will be benefited. Thanks for your investigation again !

Cheers
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...] 
Sent: Friday, July 09, 2010 10:08 AM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Shree,

Sorry I was wrong, it is working with the change below!  I hadn't restarted the SSM and after restarting it, now it's behaving itself.

Peter



Hi Shree,

Unfortunately the change didn't help. With the change in place, in addition to the segfault get a message such as:

Jul  9 13:11:03 rviz1 slurmd[rviz1][29984]: done with job

But the job is still left in the queue.

Creating a script named scancel reveals that it is still being called with -q <job #>

I'm using a workaround in the script I created substituting the parameters as -Q <job #> and it is working for now.

Regards,
Peter

________________________________________
From: Kumar, Shree [shr...@hp...]
Sent: Thursday, 8 July 2010 9:58 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter,

Changing the following lines in slurmlauncher.py
----
        try:
            p = subprocess.Popen(["scancel"]+["-q", str(self.schedId)], stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)
        except OSError, e:
            raise SLURMError(e.__str__)

        if(p.returncode == 1):
            raise SLURMError(p.communicate()[1])
----
To
----
        try:
            p = subprocess.Popen(["scancel"]+[ str(self.schedId)], stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)
        except OSError, e:
            raise SLURMError(e.__str__)

        p.communicate()
----

Should be sufficient for all cases I think. This basically disregards any errors that happen during cleanup, but assume that proper cleanup will be done by SLURM.

Can you try this change ?

Thanks
-- Shree

-----Original Message-----
From: Kumar, Shree
Sent: Wednesday, July 07, 2010 8:55 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter,

Thanks for this investigation, and the information about SCANCEL_VERBOSE. That looks like a good way to keep the code independent of explicit version requirements.

If you have any SSM crash logs, that would be useful to understand any other issues in the code.

Regards
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...]
Sent: Wednesday, July 07, 2010 12:24 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Shree,

It appears that the segfault is due to a syntax change in scancel in the current version of SLURM.

VizStack uses, "scancel -q <jobid>" syntax which would kill a job in quiet mode in SLURM 2.0.9 and prior, but now -q relates to qos.
-Q is the current parameter for quiet mode. Both these situations could be covered by using the SCANCEL_VERBOSE  environment variable.

I think the SSM was crashing due to an excess of jobs in the queue, I'll see how it goes with jobs being cancelled as they should.

Regards,
Peter
________________________________________
From: Kumar, Shree [shr...@hp...]
Sent: Tuesday, 6 July 2010 2:37 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter,

That's the first time I have seen a SLURM segfault with VizStack. As part of the cleanup sequence, we issue a single scancel command that cancels the job.

Looks like it is the first time you are seeing this error. Is it reproducible using the same steps that you have mentioned ??

Can you also check the following ?
  - Start the SSM
  - Start the viz-tvnc script
  - Let the session startup (You may connect to the session to verify)
  - Lookup the SLURM queue using "sinfo"
  - Cancel the SLURM job using "scancel"
  - Do you see a similar segfault ? I am trying to simulate the things the vsapi does here.

Also, can you send me the SSM log when it terminates ? ( /var/log/vs-ssm.log ) I don't like SSM crashes, since it's a single point of failure !

Regards
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...]
Sent: Monday, July 05, 2010 2:09 PM
To: viz...@li...
Subject: [vizstack-users] Vizstack and SLURM issue

Hello,

I'm seeing an issue with Vizstack 1.1-2 and Slurm running under Ubuntu 10.04. I currently have two nodes running with the distro provided SLURM (2.1.0) configured as per the Vizstack manual. I can start viz-tvnc fine and an X server will be started on a node/GPU as expected but when terminating the session, the job remains in the SLURM queue and a message such as the following in the syslog:

scancel[5701]: segfault at 0 ip 00007f6c22edc376 sp 00007fff1341ca08 error 4 in libc-2.11.1.so[7f6c22db6000+178000]

I can manually clear the jobs with the scancel command.

The SSM seems prone to terminating when there are such jobs left the the queue.

Any ideas?


Regards,
Peter

Peter Tyson
CSIRO IM&T - Advanced Scientific Computing
Gate 5 Normanby Road
Clayton Vic 3168
Ph +61 3 9545 2021
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

Re: [vizstack-users] Vizstack and SLURM issue

[<Pet...@cs...>]

Hi Shree,

Sorry I was wrong, it is working with the change below!  I hadn't restarted the SSM and after restarting it, now it's behaving itself.

Peter





Hi Shree,

Unfortunately the change didn't help. With the change in place, in addition to the segfault get a message such as:

Jul  9 13:11:03 rviz1 slurmd[rviz1][29984]: done with job

But the job is still left in the queue.

Creating a script named scancel reveals that it is still being called with -q <job #>

I'm using a workaround in the script I created substituting the parameters as -Q <job #> and it is working for now.

Regards,
Peter

________________________________________
From: Kumar, Shree [shr...@hp...]
Sent: Thursday, 8 July 2010 9:58 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter,

Changing the following lines in slurmlauncher.py
----
        try:
            p = subprocess.Popen(["scancel"]+["-q", str(self.schedId)], stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)
        except OSError, e:
            raise SLURMError(e.__str__)

        if(p.returncode == 1):
            raise SLURMError(p.communicate()[1])
----
To
----
        try:
            p = subprocess.Popen(["scancel"]+[ str(self.schedId)], stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)
        except OSError, e:
            raise SLURMError(e.__str__)

        p.communicate()
----

Should be sufficient for all cases I think. This basically disregards any errors that happen during cleanup, but assume that proper cleanup will be done by SLURM.

Can you try this change ?

Thanks
-- Shree

-----Original Message-----
From: Kumar, Shree
Sent: Wednesday, July 07, 2010 8:55 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter,

Thanks for this investigation, and the information about SCANCEL_VERBOSE. That looks like a good way to keep the code independent of explicit version requirements.

If you have any SSM crash logs, that would be useful to understand any other issues in the code.

Regards
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...]
Sent: Wednesday, July 07, 2010 12:24 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Shree,

It appears that the segfault is due to a syntax change in scancel in the current version of SLURM.

VizStack uses, "scancel -q <jobid>" syntax which would kill a job in quiet mode in SLURM 2.0.9 and prior, but now -q relates to qos.
-Q is the current parameter for quiet mode. Both these situations could be covered by using the SCANCEL_VERBOSE  environment variable.

I think the SSM was crashing due to an excess of jobs in the queue, I'll see how it goes with jobs being cancelled as they should.

Regards,
Peter
________________________________________
From: Kumar, Shree [shr...@hp...]
Sent: Tuesday, 6 July 2010 2:37 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter,

That's the first time I have seen a SLURM segfault with VizStack. As part of the cleanup sequence, we issue a single scancel command that cancels the job.

Looks like it is the first time you are seeing this error. Is it reproducible using the same steps that you have mentioned ??

Can you also check the following ?
  - Start the SSM
  - Start the viz-tvnc script
  - Let the session startup (You may connect to the session to verify)
  - Lookup the SLURM queue using "sinfo"
  - Cancel the SLURM job using "scancel"
  - Do you see a similar segfault ? I am trying to simulate the things the vsapi does here.

Also, can you send me the SSM log when it terminates ? ( /var/log/vs-ssm.log ) I don't like SSM crashes, since it's a single point of failure !

Regards
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...]
Sent: Monday, July 05, 2010 2:09 PM
To: viz...@li...
Subject: [vizstack-users] Vizstack and SLURM issue

Hello,

I'm seeing an issue with Vizstack 1.1-2 and Slurm running under Ubuntu 10.04. I currently have two nodes running with the distro provided SLURM (2.1.0) configured as per the Vizstack manual. I can start viz-tvnc fine and an X server will be started on a node/GPU as expected but when terminating the session, the job remains in the SLURM queue and a message such as the following in the syslog:

scancel[5701]: segfault at 0 ip 00007f6c22edc376 sp 00007fff1341ca08 error 4 in libc-2.11.1.so[7f6c22db6000+178000]

I can manually clear the jobs with the scancel command.

The SSM seems prone to terminating when there are such jobs left the the queue.

Any ideas?


Regards,
Peter

Peter Tyson
CSIRO IM&T - Advanced Scientific Computing
Gate 5 Normanby Road
Clayton Vic 3168
Ph +61 3 9545 2021
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

Re: [vizstack-users] Vizstack and SLURM issue

[<Pet...@cs...>]

Hi Shree,

Unfortunately the change didn't help. With the change in place, in addition to the segfault get a message such as:
  
Jul  9 13:11:03 rviz1 slurmd[rviz1][29984]: done with job

But the job is still left in the queue.

Creating a script named scancel reveals that it is still being called with -q <job #>

I'm using a workaround in the script I created substituting the parameters as -Q <job #> and it is working for now.

Regards,
Peter

________________________________________
From: Kumar, Shree [shr...@hp...]
Sent: Thursday, 8 July 2010 9:58 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter,

Changing the following lines in slurmlauncher.py
----
        try:
            p = subprocess.Popen(["scancel"]+["-q", str(self.schedId)], stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)
        except OSError, e:
            raise SLURMError(e.__str__)

        if(p.returncode == 1):
            raise SLURMError(p.communicate()[1])
----
To
----
        try:
            p = subprocess.Popen(["scancel"]+[ str(self.schedId)], stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)
        except OSError, e:
            raise SLURMError(e.__str__)

        p.communicate()
----

Should be sufficient for all cases I think. This basically disregards any errors that happen during cleanup, but assume that proper cleanup will be done by SLURM.

Can you try this change ?

Thanks
-- Shree

-----Original Message-----
From: Kumar, Shree
Sent: Wednesday, July 07, 2010 8:55 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter,

Thanks for this investigation, and the information about SCANCEL_VERBOSE. That looks like a good way to keep the code independent of explicit version requirements.

If you have any SSM crash logs, that would be useful to understand any other issues in the code.

Regards
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...]
Sent: Wednesday, July 07, 2010 12:24 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Shree,

It appears that the segfault is due to a syntax change in scancel in the current version of SLURM.

VizStack uses, "scancel -q <jobid>" syntax which would kill a job in quiet mode in SLURM 2.0.9 and prior, but now -q relates to qos.
-Q is the current parameter for quiet mode. Both these situations could be covered by using the SCANCEL_VERBOSE  environment variable.

I think the SSM was crashing due to an excess of jobs in the queue, I'll see how it goes with jobs being cancelled as they should.

Regards,
Peter
________________________________________
From: Kumar, Shree [shr...@hp...]
Sent: Tuesday, 6 July 2010 2:37 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter,

That's the first time I have seen a SLURM segfault with VizStack. As part of the cleanup sequence, we issue a single scancel command that cancels the job.

Looks like it is the first time you are seeing this error. Is it reproducible using the same steps that you have mentioned ??

Can you also check the following ?
  - Start the SSM
  - Start the viz-tvnc script
  - Let the session startup (You may connect to the session to verify)
  - Lookup the SLURM queue using "sinfo"
  - Cancel the SLURM job using "scancel"
  - Do you see a similar segfault ? I am trying to simulate the things the vsapi does here.

Also, can you send me the SSM log when it terminates ? ( /var/log/vs-ssm.log ) I don't like SSM crashes, since it's a single point of failure !

Regards
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...]
Sent: Monday, July 05, 2010 2:09 PM
To: viz...@li...
Subject: [vizstack-users] Vizstack and SLURM issue

Hello,

I'm seeing an issue with Vizstack 1.1-2 and Slurm running under Ubuntu 10.04. I currently have two nodes running with the distro provided SLURM (2.1.0) configured as per the Vizstack manual. I can start viz-tvnc fine and an X server will be started on a node/GPU as expected but when terminating the session, the job remains in the SLURM queue and a message such as the following in the syslog:

scancel[5701]: segfault at 0 ip 00007f6c22edc376 sp 00007fff1341ca08 error 4 in libc-2.11.1.so[7f6c22db6000+178000]

I can manually clear the jobs with the scancel command.

The SSM seems prone to terminating when there are such jobs left the the queue.

Any ideas?


Regards,
Peter

Peter Tyson
CSIRO IM&T - Advanced Scientific Computing
Gate 5 Normanby Road
Clayton Vic 3168
Ph +61 3 9545 2021
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________

Re: [vizstack-users] Vizstack and SLURM issue

[Kumar, S. <shr...@hp...>]

Hi Peter,

Changing the following lines in slurmlauncher.py 
----
        try:
            p = subprocess.Popen(["scancel"]+["-q", str(self.schedId)], stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)
        except OSError, e:
            raise SLURMError(e.__str__)

        if(p.returncode == 1):
            raise SLURMError(p.communicate()[1])
----
To
----
        try:
            p = subprocess.Popen(["scancel"]+[ str(self.schedId)], stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)
        except OSError, e:
            raise SLURMError(e.__str__)

        p.communicate()
----

Should be sufficient for all cases I think. This basically disregards any errors that happen during cleanup, but assume that proper cleanup will be done by SLURM.

Can you try this change ?

Thanks
-- Shree

-----Original Message-----
From: Kumar, Shree 
Sent: Wednesday, July 07, 2010 8:55 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter, 

Thanks for this investigation, and the information about SCANCEL_VERBOSE. That looks like a good way to keep the code independent of explicit version requirements.

If you have any SSM crash logs, that would be useful to understand any other issues in the code.

Regards
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...] 
Sent: Wednesday, July 07, 2010 12:24 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Shree,

It appears that the segfault is due to a syntax change in scancel in the current version of SLURM.  

VizStack uses, "scancel -q <jobid>" syntax which would kill a job in quiet mode in SLURM 2.0.9 and prior, but now -q relates to qos.
-Q is the current parameter for quiet mode. Both these situations could be covered by using the SCANCEL_VERBOSE  environment variable.

I think the SSM was crashing due to an excess of jobs in the queue, I'll see how it goes with jobs being cancelled as they should.

Regards,
Peter  
________________________________________
From: Kumar, Shree [shr...@hp...]
Sent: Tuesday, 6 July 2010 2:37 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter,

That's the first time I have seen a SLURM segfault with VizStack. As part of the cleanup sequence, we issue a single scancel command that cancels the job.

Looks like it is the first time you are seeing this error. Is it reproducible using the same steps that you have mentioned ??

Can you also check the following ?
  - Start the SSM
  - Start the viz-tvnc script
  - Let the session startup (You may connect to the session to verify)
  - Lookup the SLURM queue using "sinfo"
  - Cancel the SLURM job using "scancel"
  - Do you see a similar segfault ? I am trying to simulate the things the vsapi does here.

Also, can you send me the SSM log when it terminates ? ( /var/log/vs-ssm.log ) I don't like SSM crashes, since it's a single point of failure !

Regards
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...]
Sent: Monday, July 05, 2010 2:09 PM
To: viz...@li...
Subject: [vizstack-users] Vizstack and SLURM issue

Hello,

I'm seeing an issue with Vizstack 1.1-2 and Slurm running under Ubuntu 10.04. I currently have two nodes running with the distro provided SLURM (2.1.0) configured as per the Vizstack manual. I can start viz-tvnc fine and an X server will be started on a node/GPU as expected but when terminating the session, the job remains in the SLURM queue and a message such as the following in the syslog:

scancel[5701]: segfault at 0 ip 00007f6c22edc376 sp 00007fff1341ca08 error 4 in libc-2.11.1.so[7f6c22db6000+178000]

I can manually clear the jobs with the scancel command.

The SSM seems prone to terminating when there are such jobs left the the queue.

Any ideas?


Regards,
Peter

Peter Tyson
CSIRO IM&T - Advanced Scientific Computing
Gate 5 Normanby Road
Clayton Vic 3168
Ph +61 3 9545 2021
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

Re: [vizstack-users] Bezels no longer supported in shree branch, rev 317.

[<Sim...@cs...>]

The current trunk looks good - thanks.

Simon 

> -----Original Message-----
> From: Kumar, Shree [mailto:shr...@hp...] 
> Sent: Thursday, 8 July 2010 1:29 AM
> To: viz...@li...
> Subject: Re: [vizstack-users] Bezels no longer supported in 
> shree branch, rev 317.
> 
> 
> Hi Simon, 
> 
> Today seems to be one of those Murphy law days. I merged all 
> changes onto the trunk, checked them. Just when I want to 
> update the changelog in the manual, my machine goes for a six ! 
> 
> That, unfortunately, means I can't cut out a formal release. 
> I was hoping to release all bits & docs as always.
> 
> However, note that all the changes are in the trunk (which is 
> basically in sync with "shree" branch). So, you may use that 
> for the time being if needed.
> 
> HTH
> -- Shree
> 
> -----Original Message-----
> From: Kumar, Shree
> Sent: Wednesday, July 07, 2010 8:46 AM
> To: viz...@li...
> Subject: Re: [vizstack-users] Bezels no longer supported in 
> shree branch, rev 317.
> 
>  
> Thanks for that update. 
> 
> I'll merge in the clip_last_block change (and other changes) 
> & cut out a release today. You should be able to get hold of 
> it tomorrow morning your time.
> 
> -- Shree
> 
> -----Original Message-----
> From: Sim...@cs... [mailto:Sim...@cs...]
> Sent: Tuesday, July 06, 2010 12:40 PM
> To: viz...@li...
> Subject: Re: [vizstack-users] Bezels no longer supported in 
> shree branch, rev 317.
> 
> Okay, it looks like the problem was a generated config for 
> the monitor that ended up in /etc/vizstack/templates/displays 
> - probably this dated back to an earlier version that I 
> tested, and of course it had no bezel information . . . I've 
> deleted it, and it's not being regenerated, so I'd say this 
> was a false alarm.
> 
> Testing with revision 317 and proper configs/templates shows 
> that it's working properly.
> 
> Simon 
> 
> > -----Original Message-----
> > From: Kumar, Shree [mailto:shr...@hp...]
> > Sent: Tuesday, 6 July 2010 4:41 PM
> > To: viz...@li...
> > Subject: Re: [vizstack-users] Bezels no longer supported in shree 
> > branch, rev 317.
> > 
> > Hi Simon,
> > 
> > Can you tell me what the change in the capitalization was ? 
> > (i.e. from what to what, expected value to actual value?)
> > 
> > VizStack is case sensitive at all places in the XML files, and does 
> > not change case anywhere.
> > 
> > To test this, I just tried the following procedure:
> >   - changed the "model" tag of HP-LP3065.xml file to "hp 
> lp3065" from 
> > "HP LP3065"
> >   - restarted the SSM
> >   - created a tiled display that used the "hp lp3065".
> >   - checked the config file, it had the right capitalization (i.e. 
> > small case on "hp lp")
> > 
> > Regards
> > -- Shree
> > 
> > -----Original Message-----
> > From: Sim...@cs... [mailto:Sim...@cs...]
> > Sent: Tuesday, July 06, 2010 11:32 AM
> > To: viz...@li...
> > Subject: Re: [vizstack-users] Bezels no longer supported in shree 
> > branch, rev 317.
> > 
> > Okay, this isn't the problem I thought it was - somehow or 
> other part 
> > of the name of the monitor had become capitalised in the 
> > resource_group_config.xml file, so it was failing to pick up the 
> > monitor's bezel info.
> > 
> > The capitalisation issue /is/ a problem with the 
> > vs-manage-tiled-displays script (or some part of the 
> support code), I 
> > think - I created a number of test tiled displays and they 
> all came up 
> > with the capitalised monitor name. Not sure when this problem 
> > appeared, but it's definitely there in revision 317.
> > 
> > Simon
> > 
> > > -----Original Message-----
> > > From: Sim...@cs... [mailto:Sim...@cs...]
> > > Sent: Tuesday, 6 July 2010 2:49 PM
> > > To: viz...@li...
> > > Subject: [ExternalEmail] Re: [vizstack-users] Bezels no longer 
> > > supported in shree branch, rev 317.
> > > 
> > > Actually, it looks like the bezel correction was never 
> supported by 
> > > the code base that supported clip_last_block - the two 
> features are 
> > > somehow on separate branches . . .
> > > 
> > > Is there any chance we can get these branches merged?
> > > 
> > > Simon
> > > 
> > > > -----Original Message-----
> > > > From: Sim...@cs... [mailto:Sim...@cs...]
> > > > Sent: Monday, 5 July 2010 3:45 PM
> > > > To: viz...@li...
> > > > Subject: [ExternalEmail] [vizstack-users] Bezels no longer
> > > supported
> > > > in shree branch, rev 317.
> > > > 
> > > > Somehow or other the bezel support seems to have reverted or 
> > > > disappeared as of (at least) rev 317 on the shree branch.
> > > The -B and
> > > > --enable-bezels options are recognised, but they do 
> nothing . . .
> > > > 
> > > > Simon Fowler
> > > > Technical Specialist eResearch Visualisation team CSIRO IM&T 
> > > > Yarralumla, 2600 Desk 02 6124 1453 Mob 0409 245 871
> > > > --------------------------------------------------------------
> > > > ----------------
> > > > This SF.net email is sponsored by Sprint What will you do
> > > first with
> > > > EVO, the first 4G phone?
> > > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > > > _______________________________________________
> > > > vizstack-users mailing list
> > > > viz...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/vizstack-users
> > > > 
> > > --------------------------------------------------------------
> > > ----------------
> > > This SF.net email is sponsored by Sprint What will you do
> > first with
> > > EVO, the first 4G phone?
> > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > > _______________________________________________
> > > vizstack-users mailing list
> > > viz...@li...
> > > https://lists.sourceforge.net/lists/listinfo/vizstack-users
> > > 
> > --------------------------------------------------------------
> > ----------------
> > This SF.net email is sponsored by Sprint What will you do 
> first with 
> > EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > vizstack-users mailing list
> > viz...@li...
> > https://lists.sourceforge.net/lists/listinfo/vizstack-users
> > 
> > --------------------------------------------------------------
> > ----------------
> > This SF.net email is sponsored by Sprint What will you do 
> first with 
> > EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > vizstack-users mailing list
> > viz...@li...
> > https://lists.sourceforge.net/lists/listinfo/vizstack-users
> > 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint What will you do 
> first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint What will you do 
> first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint What will you do 
> first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 

Re: [vizstack-users] Bezels no longer supported in shree branch, rev 317.

[Kumar, S. <shr...@hp...>]

Hi Simon, 

Today seems to be one of those Murphy law days. I merged all changes onto the trunk, checked them. Just when I want to update the changelog in the manual, my machine goes for a six ! 

That, unfortunately, means I can't cut out a formal release. I was hoping to release all bits & docs as always.

However, note that all the changes are in the trunk (which is basically in sync with "shree" branch). So, you may use that for the time being if needed.

HTH
-- Shree

-----Original Message-----
From: Kumar, Shree 
Sent: Wednesday, July 07, 2010 8:46 AM
To: viz...@li...
Subject: Re: [vizstack-users] Bezels no longer supported in shree branch, rev 317.

 
Thanks for that update. 

I'll merge in the clip_last_block change (and other changes) & cut out a release today. You should be able to get hold of it tomorrow morning your time.

-- Shree

-----Original Message-----
From: Sim...@cs... [mailto:Sim...@cs...] 
Sent: Tuesday, July 06, 2010 12:40 PM
To: viz...@li...
Subject: Re: [vizstack-users] Bezels no longer supported in shree branch, rev 317.

Okay, it looks like the problem was a generated config for the monitor that ended up in /etc/vizstack/templates/displays - probably this dated back to an earlier version that I tested, and of course it had no bezel information . . . I've deleted it, and it's not being regenerated, so I'd say this was a false alarm.

Testing with revision 317 and proper configs/templates shows that it's working properly.

Simon 

> -----Original Message-----
> From: Kumar, Shree [mailto:shr...@hp...] 
> Sent: Tuesday, 6 July 2010 4:41 PM
> To: viz...@li...
> Subject: Re: [vizstack-users] Bezels no longer supported in 
> shree branch, rev 317.
> 
> Hi Simon, 
> 
> Can you tell me what the change in the capitalization was ? 
> (i.e. from what to what, expected value to actual value?)
> 
> VizStack is case sensitive at all places in the XML files, 
> and does not change case anywhere. 
> 
> To test this, I just tried the following procedure:
>   - changed the "model" tag of HP-LP3065.xml file to "hp 
> lp3065" from "HP LP3065"
>   - restarted the SSM
>   - created a tiled display that used the "hp lp3065".
>   - checked the config file, it had the right capitalization 
> (i.e. small case on "hp lp")
> 
> Regards
> -- Shree
> 
> -----Original Message-----
> From: Sim...@cs... [mailto:Sim...@cs...]
> Sent: Tuesday, July 06, 2010 11:32 AM
> To: viz...@li...
> Subject: Re: [vizstack-users] Bezels no longer supported in 
> shree branch, rev 317.
> 
> Okay, this isn't the problem I thought it was - somehow or 
> other part of the name of the monitor had become capitalised 
> in the resource_group_config.xml file, so it was failing to 
> pick up the monitor's bezel info.
> 
> The capitalisation issue /is/ a problem with the 
> vs-manage-tiled-displays script (or some part of the support 
> code), I think - I created a number of test tiled displays 
> and they all came up with the capitalised monitor name. Not 
> sure when this problem appeared, but it's definitely there in 
> revision 317.
> 
> Simon
> 
> > -----Original Message-----
> > From: Sim...@cs... [mailto:Sim...@cs...]
> > Sent: Tuesday, 6 July 2010 2:49 PM
> > To: viz...@li...
> > Subject: [ExternalEmail] Re: [vizstack-users] Bezels no longer 
> > supported in shree branch, rev 317.
> > 
> > Actually, it looks like the bezel correction was never supported by 
> > the code base that supported clip_last_block - the two features are 
> > somehow on separate branches . . .
> > 
> > Is there any chance we can get these branches merged?
> > 
> > Simon
> > 
> > > -----Original Message-----
> > > From: Sim...@cs... [mailto:Sim...@cs...]
> > > Sent: Monday, 5 July 2010 3:45 PM
> > > To: viz...@li...
> > > Subject: [ExternalEmail] [vizstack-users] Bezels no longer
> > supported
> > > in shree branch, rev 317.
> > > 
> > > Somehow or other the bezel support seems to have reverted or 
> > > disappeared as of (at least) rev 317 on the shree branch.
> > The -B and
> > > --enable-bezels options are recognised, but they do nothing . . .
> > > 
> > > Simon Fowler
> > > Technical Specialist eResearch Visualisation team CSIRO IM&T 
> > > Yarralumla, 2600 Desk 02 6124 1453 Mob 0409 245 871
> > > --------------------------------------------------------------
> > > ----------------
> > > This SF.net email is sponsored by Sprint What will you do
> > first with
> > > EVO, the first 4G phone?
> > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > > _______________________________________________
> > > vizstack-users mailing list
> > > viz...@li...
> > > https://lists.sourceforge.net/lists/listinfo/vizstack-users
> > > 
> > --------------------------------------------------------------
> > ----------------
> > This SF.net email is sponsored by Sprint What will you do 
> first with 
> > EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > vizstack-users mailing list
> > viz...@li...
> > https://lists.sourceforge.net/lists/listinfo/vizstack-users
> > 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint What will you do 
> first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint What will you do 
> first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

Re: [vizstack-users] Vizstack and SLURM issue

[Kumar, S. <shr...@hp...>]

Hi Peter, 

Thanks for this investigation, and the information about SCANCEL_VERBOSE. That looks like a good way to keep the code independent of explicit version requirements.

If you have any SSM crash logs, that would be useful to understand any other issues in the code.

Regards
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...] 
Sent: Wednesday, July 07, 2010 12:24 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Shree,

It appears that the segfault is due to a syntax change in scancel in the current version of SLURM.  

VizStack uses, "scancel -q <jobid>" syntax which would kill a job in quiet mode in SLURM 2.0.9 and prior, but now -q relates to qos.
-Q is the current parameter for quiet mode. Both these situations could be covered by using the SCANCEL_VERBOSE  environment variable.

I think the SSM was crashing due to an excess of jobs in the queue, I'll see how it goes with jobs being cancelled as they should.

Regards,
Peter  
________________________________________
From: Kumar, Shree [shr...@hp...]
Sent: Tuesday, 6 July 2010 2:37 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter,

That's the first time I have seen a SLURM segfault with VizStack. As part of the cleanup sequence, we issue a single scancel command that cancels the job.

Looks like it is the first time you are seeing this error. Is it reproducible using the same steps that you have mentioned ??

Can you also check the following ?
  - Start the SSM
  - Start the viz-tvnc script
  - Let the session startup (You may connect to the session to verify)
  - Lookup the SLURM queue using "sinfo"
  - Cancel the SLURM job using "scancel"
  - Do you see a similar segfault ? I am trying to simulate the things the vsapi does here.

Also, can you send me the SSM log when it terminates ? ( /var/log/vs-ssm.log ) I don't like SSM crashes, since it's a single point of failure !

Regards
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...]
Sent: Monday, July 05, 2010 2:09 PM
To: viz...@li...
Subject: [vizstack-users] Vizstack and SLURM issue

Hello,

I'm seeing an issue with Vizstack 1.1-2 and Slurm running under Ubuntu 10.04. I currently have two nodes running with the distro provided SLURM (2.1.0) configured as per the Vizstack manual. I can start viz-tvnc fine and an X server will be started on a node/GPU as expected but when terminating the session, the job remains in the SLURM queue and a message such as the following in the syslog:

scancel[5701]: segfault at 0 ip 00007f6c22edc376 sp 00007fff1341ca08 error 4 in libc-2.11.1.so[7f6c22db6000+178000]

I can manually clear the jobs with the scancel command.

The SSM seems prone to terminating when there are such jobs left the the queue.

Any ideas?


Regards,
Peter

Peter Tyson
CSIRO IM&T - Advanced Scientific Computing
Gate 5 Normanby Road
Clayton Vic 3168
Ph +61 3 9545 2021
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

Re: [vizstack-users] Vizstack and SLURM issue

[<Pet...@cs...>]

Hi Shree,

It appears that the segfault is due to a syntax change in scancel in the current version of SLURM.  

VizStack uses, "scancel -q <jobid>" syntax which would kill a job in quiet mode in SLURM 2.0.9 and prior, but now -q relates to qos.
-Q is the current parameter for quiet mode. Both these situations could be covered by using the SCANCEL_VERBOSE  environment variable.

I think the SSM was crashing due to an excess of jobs in the queue, I'll see how it goes with jobs being cancelled as they should.

Regards,
Peter  
________________________________________
From: Kumar, Shree [shr...@hp...]
Sent: Tuesday, 6 July 2010 2:37 PM
To: viz...@li...
Subject: Re: [vizstack-users] Vizstack and SLURM issue

Hi Peter,

That's the first time I have seen a SLURM segfault with VizStack. As part of the cleanup sequence, we issue a single scancel command that cancels the job.

Looks like it is the first time you are seeing this error. Is it reproducible using the same steps that you have mentioned ??

Can you also check the following ?
  - Start the SSM
  - Start the viz-tvnc script
  - Let the session startup (You may connect to the session to verify)
  - Lookup the SLURM queue using "sinfo"
  - Cancel the SLURM job using "scancel"
  - Do you see a similar segfault ? I am trying to simulate the things the vsapi does here.

Also, can you send me the SSM log when it terminates ? ( /var/log/vs-ssm.log ) I don't like SSM crashes, since it's a single point of failure !

Regards
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...]
Sent: Monday, July 05, 2010 2:09 PM
To: viz...@li...
Subject: [vizstack-users] Vizstack and SLURM issue

Hello,

I'm seeing an issue with Vizstack 1.1-2 and Slurm running under Ubuntu 10.04. I currently have two nodes running with the distro provided SLURM (2.1.0) configured as per the Vizstack manual. I can start viz-tvnc fine and an X server will be started on a node/GPU as expected but when terminating the session, the job remains in the SLURM queue and a message such as the following in the syslog:

scancel[5701]: segfault at 0 ip 00007f6c22edc376 sp 00007fff1341ca08 error 4 in libc-2.11.1.so[7f6c22db6000+178000]

I can manually clear the jobs with the scancel command.

The SSM seems prone to terminating when there are such jobs left the the queue.

Any ideas?


Regards,
Peter

Peter Tyson
CSIRO IM&T - Advanced Scientific Computing
Gate 5 Normanby Road
Clayton Vic 3168
Ph +61 3 9545 2021
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

Re: [vizstack-users] Bezels no longer supported in shree branch, rev 317.

[Kumar, S. <shr...@hp...>]

 
Thanks for that update. 

I'll merge in the clip_last_block change (and other changes) & cut out a release today. You should be able to get hold of it tomorrow morning your time.

-- Shree

-----Original Message-----
From: Sim...@cs... [mailto:Sim...@cs...] 
Sent: Tuesday, July 06, 2010 12:40 PM
To: viz...@li...
Subject: Re: [vizstack-users] Bezels no longer supported in shree branch, rev 317.

Okay, it looks like the problem was a generated config for the monitor that ended up in /etc/vizstack/templates/displays - probably this dated back to an earlier version that I tested, and of course it had no bezel information . . . I've deleted it, and it's not being regenerated, so I'd say this was a false alarm.

Testing with revision 317 and proper configs/templates shows that it's working properly.

Simon 

> -----Original Message-----
> From: Kumar, Shree [mailto:shr...@hp...] 
> Sent: Tuesday, 6 July 2010 4:41 PM
> To: viz...@li...
> Subject: Re: [vizstack-users] Bezels no longer supported in 
> shree branch, rev 317.
> 
> Hi Simon, 
> 
> Can you tell me what the change in the capitalization was ? 
> (i.e. from what to what, expected value to actual value?)
> 
> VizStack is case sensitive at all places in the XML files, 
> and does not change case anywhere. 
> 
> To test this, I just tried the following procedure:
>   - changed the "model" tag of HP-LP3065.xml file to "hp 
> lp3065" from "HP LP3065"
>   - restarted the SSM
>   - created a tiled display that used the "hp lp3065".
>   - checked the config file, it had the right capitalization 
> (i.e. small case on "hp lp")
> 
> Regards
> -- Shree
> 
> -----Original Message-----
> From: Sim...@cs... [mailto:Sim...@cs...]
> Sent: Tuesday, July 06, 2010 11:32 AM
> To: viz...@li...
> Subject: Re: [vizstack-users] Bezels no longer supported in 
> shree branch, rev 317.
> 
> Okay, this isn't the problem I thought it was - somehow or 
> other part of the name of the monitor had become capitalised 
> in the resource_group_config.xml file, so it was failing to 
> pick up the monitor's bezel info.
> 
> The capitalisation issue /is/ a problem with the 
> vs-manage-tiled-displays script (or some part of the support 
> code), I think - I created a number of test tiled displays 
> and they all came up with the capitalised monitor name. Not 
> sure when this problem appeared, but it's definitely there in 
> revision 317.
> 
> Simon
> 
> > -----Original Message-----
> > From: Sim...@cs... [mailto:Sim...@cs...]
> > Sent: Tuesday, 6 July 2010 2:49 PM
> > To: viz...@li...
> > Subject: [ExternalEmail] Re: [vizstack-users] Bezels no longer 
> > supported in shree branch, rev 317.
> > 
> > Actually, it looks like the bezel correction was never supported by 
> > the code base that supported clip_last_block - the two features are 
> > somehow on separate branches . . .
> > 
> > Is there any chance we can get these branches merged?
> > 
> > Simon
> > 
> > > -----Original Message-----
> > > From: Sim...@cs... [mailto:Sim...@cs...]
> > > Sent: Monday, 5 July 2010 3:45 PM
> > > To: viz...@li...
> > > Subject: [ExternalEmail] [vizstack-users] Bezels no longer
> > supported
> > > in shree branch, rev 317.
> > > 
> > > Somehow or other the bezel support seems to have reverted or 
> > > disappeared as of (at least) rev 317 on the shree branch.
> > The -B and
> > > --enable-bezels options are recognised, but they do nothing . . .
> > > 
> > > Simon Fowler
> > > Technical Specialist eResearch Visualisation team CSIRO IM&T 
> > > Yarralumla, 2600 Desk 02 6124 1453 Mob 0409 245 871
> > > --------------------------------------------------------------
> > > ----------------
> > > This SF.net email is sponsored by Sprint What will you do
> > first with
> > > EVO, the first 4G phone?
> > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > > _______________________________________________
> > > vizstack-users mailing list
> > > viz...@li...
> > > https://lists.sourceforge.net/lists/listinfo/vizstack-users
> > > 
> > --------------------------------------------------------------
> > ----------------
> > This SF.net email is sponsored by Sprint What will you do 
> first with 
> > EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > vizstack-users mailing list
> > viz...@li...
> > https://lists.sourceforge.net/lists/listinfo/vizstack-users
> > 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint What will you do 
> first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint What will you do 
> first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

Re: [vizstack-users] Bezels no longer supported in shree branch, rev 317.

[<Sim...@cs...>]

Okay, it looks like the problem was a generated config for the monitor that ended up in /etc/vizstack/templates/displays - probably this dated back to an earlier version that I tested, and of course it had no bezel information . . . I've deleted it, and it's not being regenerated, so I'd say this was a false alarm.

Testing with revision 317 and proper configs/templates shows that it's working properly.

Simon 

> -----Original Message-----
> From: Kumar, Shree [mailto:shr...@hp...] 
> Sent: Tuesday, 6 July 2010 4:41 PM
> To: viz...@li...
> Subject: Re: [vizstack-users] Bezels no longer supported in 
> shree branch, rev 317.
> 
> Hi Simon, 
> 
> Can you tell me what the change in the capitalization was ? 
> (i.e. from what to what, expected value to actual value?)
> 
> VizStack is case sensitive at all places in the XML files, 
> and does not change case anywhere. 
> 
> To test this, I just tried the following procedure:
>   - changed the "model" tag of HP-LP3065.xml file to "hp 
> lp3065" from "HP LP3065"
>   - restarted the SSM
>   - created a tiled display that used the "hp lp3065".
>   - checked the config file, it had the right capitalization 
> (i.e. small case on "hp lp")
> 
> Regards
> -- Shree
> 
> -----Original Message-----
> From: Sim...@cs... [mailto:Sim...@cs...]
> Sent: Tuesday, July 06, 2010 11:32 AM
> To: viz...@li...
> Subject: Re: [vizstack-users] Bezels no longer supported in 
> shree branch, rev 317.
> 
> Okay, this isn't the problem I thought it was - somehow or 
> other part of the name of the monitor had become capitalised 
> in the resource_group_config.xml file, so it was failing to 
> pick up the monitor's bezel info.
> 
> The capitalisation issue /is/ a problem with the 
> vs-manage-tiled-displays script (or some part of the support 
> code), I think - I created a number of test tiled displays 
> and they all came up with the capitalised monitor name. Not 
> sure when this problem appeared, but it's definitely there in 
> revision 317.
> 
> Simon
> 
> > -----Original Message-----
> > From: Sim...@cs... [mailto:Sim...@cs...]
> > Sent: Tuesday, 6 July 2010 2:49 PM
> > To: viz...@li...
> > Subject: [ExternalEmail] Re: [vizstack-users] Bezels no longer 
> > supported in shree branch, rev 317.
> > 
> > Actually, it looks like the bezel correction was never supported by 
> > the code base that supported clip_last_block - the two features are 
> > somehow on separate branches . . .
> > 
> > Is there any chance we can get these branches merged?
> > 
> > Simon
> > 
> > > -----Original Message-----
> > > From: Sim...@cs... [mailto:Sim...@cs...]
> > > Sent: Monday, 5 July 2010 3:45 PM
> > > To: viz...@li...
> > > Subject: [ExternalEmail] [vizstack-users] Bezels no longer
> > supported
> > > in shree branch, rev 317.
> > > 
> > > Somehow or other the bezel support seems to have reverted or 
> > > disappeared as of (at least) rev 317 on the shree branch.
> > The -B and
> > > --enable-bezels options are recognised, but they do nothing . . .
> > > 
> > > Simon Fowler
> > > Technical Specialist eResearch Visualisation team CSIRO IM&T 
> > > Yarralumla, 2600 Desk 02 6124 1453 Mob 0409 245 871
> > > --------------------------------------------------------------
> > > ----------------
> > > This SF.net email is sponsored by Sprint What will you do
> > first with
> > > EVO, the first 4G phone?
> > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > > _______________________________________________
> > > vizstack-users mailing list
> > > viz...@li...
> > > https://lists.sourceforge.net/lists/listinfo/vizstack-users
> > > 
> > --------------------------------------------------------------
> > ----------------
> > This SF.net email is sponsored by Sprint What will you do 
> first with 
> > EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > vizstack-users mailing list
> > viz...@li...
> > https://lists.sourceforge.net/lists/listinfo/vizstack-users
> > 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint What will you do 
> first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint What will you do 
> first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 

Re: [vizstack-users] Bezels no longer supported in shree branch, rev 317.

[Kumar, S. <shr...@hp...>]

Hi Simon, 

Can you tell me what the change in the capitalization was ? (i.e. from what to what, expected value to actual value?)

VizStack is case sensitive at all places in the XML files, and does not change case anywhere. 

To test this, I just tried the following procedure:
  - changed the "model" tag of HP-LP3065.xml file to "hp lp3065" from "HP LP3065"
  - restarted the SSM
  - created a tiled display that used the "hp lp3065".
  - checked the config file, it had the right capitalization (i.e. small case on "hp lp")

Regards
-- Shree

-----Original Message-----
From: Sim...@cs... [mailto:Sim...@cs...] 
Sent: Tuesday, July 06, 2010 11:32 AM
To: viz...@li...
Subject: Re: [vizstack-users] Bezels no longer supported in shree branch, rev 317.

Okay, this isn't the problem I thought it was - somehow or other part of the name of the monitor had become capitalised in the resource_group_config.xml file, so it was failing to pick up the monitor's bezel info.

The capitalisation issue /is/ a problem with the vs-manage-tiled-displays script (or some part of the support code), I think - I created a number of test tiled displays and they all came up with the capitalised monitor name. Not sure when this problem appeared, but it's definitely there in revision 317.

Simon

> -----Original Message-----
> From: Sim...@cs... [mailto:Sim...@cs...] 
> Sent: Tuesday, 6 July 2010 2:49 PM
> To: viz...@li...
> Subject: [ExternalEmail] Re: [vizstack-users] Bezels no 
> longer supported in shree branch, rev 317.
> 
> Actually, it looks like the bezel correction was never 
> supported by the code base that supported clip_last_block - 
> the two features are somehow on separate branches . . .
> 
> Is there any chance we can get these branches merged?
> 
> Simon
> 
> > -----Original Message-----
> > From: Sim...@cs... [mailto:Sim...@cs...]
> > Sent: Monday, 5 July 2010 3:45 PM
> > To: viz...@li...
> > Subject: [ExternalEmail] [vizstack-users] Bezels no longer 
> supported 
> > in shree branch, rev 317.
> > 
> > Somehow or other the bezel support seems to have reverted or 
> > disappeared as of (at least) rev 317 on the shree branch. 
> The -B and 
> > --enable-bezels options are recognised, but they do nothing . . .
> > 
> > Simon Fowler
> > Technical Specialist eResearch Visualisation team CSIRO IM&T 
> > Yarralumla, 2600 Desk 02 6124 1453 Mob 0409 245 871
> > --------------------------------------------------------------
> > ----------------
> > This SF.net email is sponsored by Sprint What will you do 
> first with 
> > EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > vizstack-users mailing list
> > viz...@li...
> > https://lists.sourceforge.net/lists/listinfo/vizstack-users
> > 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint What will you do 
> first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

Re: [vizstack-users] Bezels no longer supported in shree branch, rev 317.

[<Sim...@cs...>]

Okay, this isn't the problem I thought it was - somehow or other part of the name of the monitor had become capitalised in the resource_group_config.xml file, so it was failing to pick up the monitor's bezel info.

The capitalisation issue /is/ a problem with the vs-manage-tiled-displays script (or some part of the support code), I think - I created a number of test tiled displays and they all came up with the capitalised monitor name. Not sure when this problem appeared, but it's definitely there in revision 317.

Simon

> -----Original Message-----
> From: Sim...@cs... [mailto:Sim...@cs...] 
> Sent: Tuesday, 6 July 2010 2:49 PM
> To: viz...@li...
> Subject: [ExternalEmail] Re: [vizstack-users] Bezels no 
> longer supported in shree branch, rev 317.
> 
> Actually, it looks like the bezel correction was never 
> supported by the code base that supported clip_last_block - 
> the two features are somehow on separate branches . . .
> 
> Is there any chance we can get these branches merged?
> 
> Simon
> 
> > -----Original Message-----
> > From: Sim...@cs... [mailto:Sim...@cs...]
> > Sent: Monday, 5 July 2010 3:45 PM
> > To: viz...@li...
> > Subject: [ExternalEmail] [vizstack-users] Bezels no longer 
> supported 
> > in shree branch, rev 317.
> > 
> > Somehow or other the bezel support seems to have reverted or 
> > disappeared as of (at least) rev 317 on the shree branch. 
> The -B and 
> > --enable-bezels options are recognised, but they do nothing . . .
> > 
> > Simon Fowler
> > Technical Specialist eResearch Visualisation team CSIRO IM&T 
> > Yarralumla, 2600 Desk 02 6124 1453 Mob 0409 245 871
> > --------------------------------------------------------------
> > ----------------
> > This SF.net email is sponsored by Sprint What will you do 
> first with 
> > EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > vizstack-users mailing list
> > viz...@li...
> > https://lists.sourceforge.net/lists/listinfo/vizstack-users
> > 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint What will you do 
> first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 

Re: [vizstack-users] Which branch to use right now?

[Kumar, S. <shr...@hp...>]

Looks like I've made a mess of the merge ? Doh ! Sorry for the slip up - I thought I merged in all the changes. I'll also look at the bezel support stuff reported by you. 

I couldn't cut out a release last week. Will have a new release on SF tomorrow for sure - with these fixed!

Thanks for your patience !
-- Shree

-----Original Message-----
From: Sim...@cs... [mailto:Sim...@cs...] 
Sent: Monday, July 05, 2010 9:38 AM
To: viz...@li...
Subject: Re: [vizstack-users] Which branch to use right now?

Any update on the new release? I've just realised that the trunk doesn't currently include the clip_last_block support, so we'll have to switch back to the shree branch until the new release is out.

Simon 

> -----Original Message-----
> From: Kumar, Shree [mailto:shr...@hp...] 
> Sent: Friday, 25 June 2010 1:37 PM
> To: viz...@li...
> Subject: Re: [vizstack-users] Which branch to use right now?
> 
> Hi Simon,
> 
> For production systems, you could use the trunk (equivalent 
> to release 1.1-2).
> 
> I'm planning to roll in the changes in the shree branch 
> (fixes, doc, etc) into the trunk & cut out a new release next week.
> 
> Regards
> -- Shree
> 
> -----Original Message-----
> From: Sim...@cs... [mailto:Sim...@cs...]
> Sent: Friday, June 25, 2010 6:32 AM
> To: viz...@li...
> Subject: [vizstack-users] Which branch to use right now?
> 
> Having just updated both the main branch and the shree 
> branch, I'm wondering which one we should be using for 
> production systems right now? There are some quite major 
> differences now, and I'm not sure whether they're functional 
> or just documentation and extraneous stuff.
> 
> Simon Fowler
> Technical Specialist eResearch Visualisation team CSIRO IM&T 
> Yarralumla, 2600 Desk 02 6124 1453 Mob 0409 245 871
> --------------------------------------------------------------
> ----------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky 
> parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 
> --------------------------------------------------------------
> ----------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky 
> parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

Re: [vizstack-users] Bezels no longer supported in shree branch, rev 317.

[<Sim...@cs...>]

Actually, it looks like the bezel correction was never supported by the code base that supported clip_last_block - the two features are somehow on separate branches . . .

Is there any chance we can get these branches merged?

Simon

> -----Original Message-----
> From: Sim...@cs... [mailto:Sim...@cs...] 
> Sent: Monday, 5 July 2010 3:45 PM
> To: viz...@li...
> Subject: [ExternalEmail] [vizstack-users] Bezels no longer 
> supported in shree branch, rev 317.
> 
> Somehow or other the bezel support seems to have reverted or 
> disappeared as of (at least) rev 317 on the shree branch. The 
> -B and --enable-bezels options are recognised, but they do 
> nothing . . .
> 
> Simon Fowler
> Technical Specialist eResearch Visualisation team CSIRO IM&T 
> Yarralumla, 2600 Desk 02 6124 1453 Mob 0409 245 871
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by Sprint What will you do 
> first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 

Re: [vizstack-users] Vizstack and SLURM issue

[Kumar, S. <shr...@hp...>]

Hi Peter,

That's the first time I have seen a SLURM segfault with VizStack. As part of the cleanup sequence, we issue a single scancel command that cancels the job.

Looks like it is the first time you are seeing this error. Is it reproducible using the same steps that you have mentioned ??

Can you also check the following ?
  - Start the SSM
  - Start the viz-tvnc script
  - Let the session startup (You may connect to the session to verify)
  - Lookup the SLURM queue using "sinfo"
  - Cancel the SLURM job using "scancel"
  - Do you see a similar segfault ? I am trying to simulate the things the vsapi does here.

Also, can you send me the SSM log when it terminates ? ( /var/log/vs-ssm.log ) I don't like SSM crashes, since it's a single point of failure !

Regards
-- Shree

-----Original Message-----
From: Pet...@cs... [mailto:Pet...@cs...] 
Sent: Monday, July 05, 2010 2:09 PM
To: viz...@li...
Subject: [vizstack-users] Vizstack and SLURM issue

Hello,

I'm seeing an issue with Vizstack 1.1-2 and Slurm running under Ubuntu 10.04. I currently have two nodes running with the distro provided SLURM (2.1.0) configured as per the Vizstack manual. I can start viz-tvnc fine and an X server will be started on a node/GPU as expected but when terminating the session, the job remains in the SLURM queue and a message such as the following in the syslog:

scancel[5701]: segfault at 0 ip 00007f6c22edc376 sp 00007fff1341ca08 error 4 in libc-2.11.1.so[7f6c22db6000+178000]

I can manually clear the jobs with the scancel command.

The SSM seems prone to terminating when there are such jobs left the the queue.

Any ideas?


Regards,
Peter

Peter Tyson
CSIRO IM&T - Advanced Scientific Computing
Gate 5 Normanby Road
Clayton Vic 3168
Ph +61 3 9545 2021
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

[vizstack-users] Vizstack and SLURM issue

[<Pet...@cs...>]

Hello,

I'm seeing an issue with Vizstack 1.1-2 and Slurm running under Ubuntu 10.04. I currently have two nodes running with the distro provided SLURM (2.1.0) configured as per the Vizstack manual. I can start viz-tvnc fine and an X server will be started on a node/GPU as expected but when terminating the session, the job remains in the SLURM queue and a message such as the following in the syslog:

scancel[5701]: segfault at 0 ip 00007f6c22edc376 sp 00007fff1341ca08 error 4 in libc-2.11.1.so[7f6c22db6000+178000]

I can manually clear the jobs with the scancel command.

The SSM seems prone to terminating when there are such jobs left the the queue.

Any ideas?


Regards,
Peter

Peter Tyson
CSIRO IM&T - Advanced Scientific Computing
Gate 5 Normanby Road
Clayton Vic 3168
Ph +61 3 9545 2021

[vizstack-users] Bezels no longer supported in shree branch, rev 317.

[<Sim...@cs...>]

Somehow or other the bezel support seems to have reverted or disappeared as of (at least) rev 317 on the shree branch. The -B and --enable-bezels options are recognised, but they do nothing . . .

Simon Fowler
Technical Specialist eResearch Visualisation team
CSIRO IM&T
Yarralumla, 2600 
Desk 02 6124 1453
Mob 0409 245 871

Re: [vizstack-users] Which branch to use right now?

[<Sim...@cs...>]

Any update on the new release? I've just realised that the trunk doesn't currently include the clip_last_block support, so we'll have to switch back to the shree branch until the new release is out.

Simon 

> -----Original Message-----
> From: Kumar, Shree [mailto:shr...@hp...] 
> Sent: Friday, 25 June 2010 1:37 PM
> To: viz...@li...
> Subject: Re: [vizstack-users] Which branch to use right now?
> 
> Hi Simon,
> 
> For production systems, you could use the trunk (equivalent 
> to release 1.1-2).
> 
> I'm planning to roll in the changes in the shree branch 
> (fixes, doc, etc) into the trunk & cut out a new release next week.
> 
> Regards
> -- Shree
> 
> -----Original Message-----
> From: Sim...@cs... [mailto:Sim...@cs...]
> Sent: Friday, June 25, 2010 6:32 AM
> To: viz...@li...
> Subject: [vizstack-users] Which branch to use right now?
> 
> Having just updated both the main branch and the shree 
> branch, I'm wondering which one we should be using for 
> production systems right now? There are some quite major 
> differences now, and I'm not sure whether they're functional 
> or just documentation and extraneous stuff.
> 
> Simon Fowler
> Technical Specialist eResearch Visualisation team CSIRO IM&T 
> Yarralumla, 2600 Desk 02 6124 1453 Mob 0409 245 871
> --------------------------------------------------------------
> ----------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky 
> parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 
> --------------------------------------------------------------
> ----------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky 
> parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> vizstack-users mailing list
> viz...@li...
> https://lists.sourceforge.net/lists/listinfo/vizstack-users
> 

Re: [vizstack-users] Which branch to use right now?

[Kumar, S. <shr...@hp...>]

Hi Simon,

For production systems, you could use the trunk (equivalent to release 1.1-2).

I'm planning to roll in the changes in the shree branch (fixes, doc, etc) into the trunk & cut out a new release next week.

Regards
-- Shree

-----Original Message-----
From: Sim...@cs... [mailto:Sim...@cs...] 
Sent: Friday, June 25, 2010 6:32 AM
To: viz...@li...
Subject: [vizstack-users] Which branch to use right now?

Having just updated both the main branch and the shree branch, I'm wondering which one we should be using for production systems right now? There are some quite major differences now, and I'm not sure whether they're functional or just documentation and extraneous stuff.

Simon Fowler
Technical Specialist eResearch Visualisation team
CSIRO IM&T
Yarralumla, 2600 
Desk 02 6124 1453
Mob 0409 245 871
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

[vizstack-users] Which branch to use right now?

[<Sim...@cs...>]

Having just updated both the main branch and the shree branch, I'm wondering which one we should be using for production systems right now? There are some quite major differences now, and I'm not sure whether they're functional or just documentation and extraneous stuff.

Simon Fowler
Technical Specialist eResearch Visualisation team
CSIRO IM&T
Yarralumla, 2600 
Desk 02 6124 1453
Mob 0409 245 871

[vizstack-users] Anybody using ParaView with VizStack ?

[Kumar, S. <shr...@hp...>]

A quick query : is there anybody out there using ParaView with VizStack ?

I am making a few changes to that script which are small in terms of code change, but bigger in terms of ease of use.

The parallel rendering section of the ParaView wiki (http://paraview.org/Wiki/Setting_up_a_ParaView_Server) recommends using shared GPUs for parallel rendering tasks. Currently, viz-paraview allocates only exclusive GPUs (i.e. no sharing). My modification would change the situation, as below:

  - viz-paraview would allocate shared GPUs by default. Thus, hardware utilization would be better. Offscreen rendering would be used for this. 
  - a "-x" option would be available to turn off GPU sharing
  - viz-paraview would be able to use additional GPUs to drive tiled displays (currently, it allows doing sort-first OR sort-last, but not both together)

If you have any feedback on these changes, please let me know.

With these changes, viz-paraview would cater to many use cases. It will make VizStack a very good option for ParaView users.

There have been a few bugfixes to VizStack post release 1.1-2. I'm planning to include these changes and put out another release, perhaps next week. At that time, I am also planning to announce VizStack on the ParaView mailing list.

Regards
-- Shree

Re: [vizstack-users] viz-desktop should now work with bezels

[Kumar, S. <shr...@hp...>]

> CGLX in its current form isn't all that practical - it has potential, but it's a 
> little too proprietary to be really usable. If they ever make it open source it could be much better. 

+1. They don't even allow a direct download, sigh.

We're a small community; and with closed source is hard to get stuff working.

> VizStack might be useful as a way to manage GPUs on the cluster that CGLX was 
> running on, but I'm having a hard time thinking of other ways they might meld. 

I was thinking something like this: when users want to use a Tiled Display with 
CGLX, they allocate the TD & use it with CGLX. When the CGLX user is done, the
GPUs are usable for other users. 

CGLX seems to be very flexibile w.r.t what Tiled displays it can run on. You may
have a 5x5 tiled display setup. However, some users may be happy running just on
4x4 of that, some on 3x2, etc. TDs aren't typically used like this, but they could
be.

> What /would/ be useful combined with VizStack is some form of distributed Xinerama 
> or XRandR, which would allow a virtual desktop to be shared across multiple machines. 
> CGLX implements one way to create a clustered display like that, but it has significant 
> issues. Something more transparent to applications would be far more valuable.

Have you used DMX and Chromium ? Unfortunately, Chromium may not work well with newer OpenGL apps.

You may also want to look at SAGE (http://www.sagecommons.org/0; I haven't used it yet, but it's
on my list of things to look at. 

> The Quadroplexes we're looking at for other things seem to present as multiple 
> separate GPUs, same as the NVS420s. This may be the way we're using them, though - the 
> default setup may only present as a single GPU. We're using them as remote rendering 
> boxes via VizStack and VirtualGL, so having direct access to all the internal cards is 
> useful to us.

Right. Unless you configure "SLI Mosaic mode" (or some other SLI mode), the GPUs in the 
QuadroPlex look like individual GPUs. If you use the "QuadroPlex" type of block with
Tiled displays, this mode is setup automatically.

-- Shree

-----Original Message-----
From: Sim...@cs... [mailto:Sim...@cs...] 
Sent: Friday, May 28, 2010 11:40 AM
To: viz...@li...
Subject: Re: [vizstack-users] viz-desktop should now work with bezels

CGLX in its current form isn't all that practical - it has potential, but it's a little too proprietary to be really usable. If they ever make it open source it could be much better.

VizStack might be useful as a way to manage GPUs on the cluster that CGLX was running on, but I'm having a hard time thinking of other ways they might meld. 

What /would/ be useful combined with VizStack is some form of distributed Xinerama or XRandR, which would allow a virtual desktop to be shared across multiple machines. CGLX implements one way to create a clustered display like that, but it has significant issues. Something more transparent to applications would be far more valuable.

The Quadroplexes we're looking at for other things seem to present as multiple separate GPUs, same as the NVS420s. This may be the way we're using them, though - the default setup may only present as a single GPU. We're using them as remote rendering boxes via VizStack and VirtualGL, so having direct access to all the internal cards is useful to us.

Simon

________________________________________
From: Kumar, Shree [shr...@hp...]
Sent: Friday, May 28, 2010 2:19 PM
To: viz...@li...
Subject: Re: [vizstack-users] viz-desktop should now work with bezels

> You're arranging the blocks in rows and disabling the right-most output
>of each row -  explaining it like that should help . . . but I've spent
> the whole evening trying to think of a good concise way to explain it,
> and so far nothing. I'll think about it some more and see if I can suggest
> anything, but it really is quite hard to explain clearly.

I'm hoping to add some images. Can't think of anything better for now.

> One question: is it possible (or meaningful) to use a value of [None,1]
> or similar? It seems like it would disable the first output on the GPU
> rather than the second, which might be useful in some cases . . .

The first element corresponds to the clipping applied to the last column.
The second element corresponds to the clipping applied to the last row.

Using [None,1] would clip all displays that form the last row. E.g. if you were
driving [1,2] from every GPU, this would be useful. If you were using a
QuadroPlex, both would elements could be used together, since it can drive upto
4 displays as one unit.

> Also, does it /have/ to be the last GPU in the row? It might be nice to be
> able to set up, say, a 5x5 display with the odd monitor in each row being in
> the middle. Obviously very low priority, but still possibly useful. Also, how
> hard would it be to support arbitrary mixing of different types of blocks? We
> have a 5x5 system (completely unrelated to the stuff I'm working on right now
> - it uses CGLX as the display system) which has the fifth column made up of two
> vertical pairs and a singleton, with the rest of the display made up of horizontal
> pairs - as it stands I think Vizstack would have to have the whole fifth column
> made up of singleton monitors. In practice it's probably not an issue, but if
> supporting arbitrary mixes of blocks is easy it might be something to consider
> for a future version.

Good points. To me, arbitrary mixing of different types of blocks is the way to go.
The current mechanism is a quick plug; it is something easier to understand and
configure, but with the drawback of not handling all cases.

Setting up arbitrary mixing of blocks is not difficult. However, preventing
users from making mistakes, and describing arbitrary layouts is where the work is.
Visualizing mix of blocks poses a problem too, perhaps a GUI is the best way to
create them (and not command line tools OR handwritten config files.)

Also, with arbitrary blocks, we need some more "intelligence" in scripts for
applications that can't handle all types of Tiled Displays.

I've never used CGLX before. However, I have asked them for a password to download.
Could you describe how you've configured your CGLX tiled display ?

Quite by coincidence, I did some reading about CGLX yesterday (A paper on
CGLX is getting published in TCVG). Do you think it makes sense to use
CGLX inside VizStack ? That way, GPUs could be used for CGLX or other
purposes on demand.

> And one final question: if you have a single GPU with four outputs, would
> you have to make each block 4x1, or could you make them 2x2? i.e. to get
> a 3x2 display would you need to have two rows of 4x1 blocks, or could you
> use one row of 2x2 blocks? I doubt there's any hardware out there where
> this would be an issue, but I imagine there's stuff on the horizon . . .

You would be able to make each block 4x1 or 2x2, or anything in between
(that's what we support for the QuadroPlex block).

Do you have any GPU that supports 4 displays ? Your QuadroNVS is actually
two GPUs in one, with each capable of driving 2 displays at once.

Current nVidia cards support 2 displays in one, and they call that support
"TwinView". They will come out with more, and configuring them will need
additional options in the config file I guess. When such GPUs are available,
we will handle them.

Regards
-- Shree

-----Original Message-----
From: Sim...@cs... [mailto:Sim...@cs...]
Sent: Thursday, May 27, 2010 7:47 PM
To: viz...@li...
Subject: Re: [vizstack-users] viz-desktop should now work with bezels

> -----Original Message-----
> From: Kumar, Shree [mailto:shr...@hp...]
> Sent: Thursday, 27 May 2010 3:57 PM
> To: viz...@li...
> Subject: Re: [vizstack-users] viz-desktop should now work with bezels
>
>
> I'm an atheist, but will take the compliments :-)
>
> > Aside from being caught out at first by using 'none' instead of
> > 'None', and having to rearrange the cabling (thankfully
> displayport is
> > much nicer than DVI in that regard), it was as simple as
> creating the
> > tiled display and adding the clip_last_block line. Running
> from the console works perfectly.
>
> Yeah, the cabling is irregular with this setup. Is this setup
> hard to understand ?
>
Not too hard once I realised how it needed to be arranged.

> One reason I haven't add this to the vs-manage-tiled-displays
> tool is : I find it complicated to explain !
> Any hints w.r.t explaining this would be useful.
>
You're arranging the blocks in rows and disabling the right-most output of each row -  explaining it like that should help . . . but I've spent the whole evening trying to think of a good concise way to explain it, and so far nothing. I'll think about it some more and see if I can suggest anything, but it really is quite hard to explain clearly.

> > Thanks for implementing this so quickly!
>
> As I said, this turned out to be fairly simple in the end.
> The same mechanism works with QuadroPlexes too, but nobody
> seems to be using more than one QuadroPlex at the moment with
> VizStack. And now others can use this too.
>
It's definitely a very nice feature.

One question: is it possible (or meaningful) to use a value of [None,1] or similar? It seems like it would disable the first output on the GPU rather than the second, which might be useful in some cases . . .

Also, does it /have/ to be the last GPU in the row? It might be nice to be able to set up, say, a 5x5 display with the odd monitor in each row being in the middle. Obviously very low priority, but still possibly useful. Also, how hard would it be to support arbitrary mixing of different types of blocks? We have a 5x5 system (completely unrelated to the stuff I'm working on right now - it uses CGLX as the display system) which has the fifth column made up of two vertical pairs and a singleton, with the rest of the display made up of horizontal pairs - as it stands I think Vizstack would have to have the whole fifth column made up of singleton monitors. In practice it's probably not an issue, but if supporting arbitrary mixes of blocks is easy it might be something to consider for a future version.

And one final question: if you have a single GPU with four outputs, would you have to make each block 4x1, or could you make them 2x2? i.e. to get a 3x2 display would you need to have two rows of 4x1 blocks, or could you use one row of 2x2 blocks? I doubt there's any hardware out there where this would be an issue, but I imagine there's stuff on the horizon . . .

Lots of extra questions - none of them very critical for us, since with this update you've resolved the last outstanding issue we had.

Thanks,

Simon
------------------------------------------------------------------------------

_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

------------------------------------------------------------------------------

_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

------------------------------------------------------------------------------

_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

Re: [vizstack-users] viz-desktop should now work with bezels

[<Sim...@cs...>]

CGLX in its current form isn't all that practical - it has potential, but it's a little too proprietary to be really usable. If they ever make it open source it could be much better.

VizStack might be useful as a way to manage GPUs on the cluster that CGLX was running on, but I'm having a hard time thinking of other ways they might meld. 

What /would/ be useful combined with VizStack is some form of distributed Xinerama or XRandR, which would allow a virtual desktop to be shared across multiple machines. CGLX implements one way to create a clustered display like that, but it has significant issues. Something more transparent to applications would be far more valuable.

The Quadroplexes we're looking at for other things seem to present as multiple separate GPUs, same as the NVS420s. This may be the way we're using them, though - the default setup may only present as a single GPU. We're using them as remote rendering boxes via VizStack and VirtualGL, so having direct access to all the internal cards is useful to us.

Simon

________________________________________
From: Kumar, Shree [shr...@hp...]
Sent: Friday, May 28, 2010 2:19 PM
To: viz...@li...
Subject: Re: [vizstack-users] viz-desktop should now work with bezels

> You're arranging the blocks in rows and disabling the right-most output
>of each row -  explaining it like that should help . . . but I've spent
> the whole evening trying to think of a good concise way to explain it,
> and so far nothing. I'll think about it some more and see if I can suggest
> anything, but it really is quite hard to explain clearly.

I'm hoping to add some images. Can't think of anything better for now.

> One question: is it possible (or meaningful) to use a value of [None,1]
> or similar? It seems like it would disable the first output on the GPU
> rather than the second, which might be useful in some cases . . .

The first element corresponds to the clipping applied to the last column.
The second element corresponds to the clipping applied to the last row.

Using [None,1] would clip all displays that form the last row. E.g. if you were
driving [1,2] from every GPU, this would be useful. If you were using a
QuadroPlex, both would elements could be used together, since it can drive upto
4 displays as one unit.

> Also, does it /have/ to be the last GPU in the row? It might be nice to be
> able to set up, say, a 5x5 display with the odd monitor in each row being in
> the middle. Obviously very low priority, but still possibly useful. Also, how
> hard would it be to support arbitrary mixing of different types of blocks? We
> have a 5x5 system (completely unrelated to the stuff I'm working on right now
> - it uses CGLX as the display system) which has the fifth column made up of two
> vertical pairs and a singleton, with the rest of the display made up of horizontal
> pairs - as it stands I think Vizstack would have to have the whole fifth column
> made up of singleton monitors. In practice it's probably not an issue, but if
> supporting arbitrary mixes of blocks is easy it might be something to consider
> for a future version.

Good points. To me, arbitrary mixing of different types of blocks is the way to go.
The current mechanism is a quick plug; it is something easier to understand and
configure, but with the drawback of not handling all cases.

Setting up arbitrary mixing of blocks is not difficult. However, preventing
users from making mistakes, and describing arbitrary layouts is where the work is.
Visualizing mix of blocks poses a problem too, perhaps a GUI is the best way to
create them (and not command line tools OR handwritten config files.)

Also, with arbitrary blocks, we need some more "intelligence" in scripts for
applications that can't handle all types of Tiled Displays.

I've never used CGLX before. However, I have asked them for a password to download.
Could you describe how you've configured your CGLX tiled display ?

Quite by coincidence, I did some reading about CGLX yesterday (A paper on
CGLX is getting published in TCVG). Do you think it makes sense to use
CGLX inside VizStack ? That way, GPUs could be used for CGLX or other
purposes on demand.

> And one final question: if you have a single GPU with four outputs, would
> you have to make each block 4x1, or could you make them 2x2? i.e. to get
> a 3x2 display would you need to have two rows of 4x1 blocks, or could you
> use one row of 2x2 blocks? I doubt there's any hardware out there where
> this would be an issue, but I imagine there's stuff on the horizon . . .

You would be able to make each block 4x1 or 2x2, or anything in between
(that's what we support for the QuadroPlex block).

Do you have any GPU that supports 4 displays ? Your QuadroNVS is actually
two GPUs in one, with each capable of driving 2 displays at once.

Current nVidia cards support 2 displays in one, and they call that support
"TwinView". They will come out with more, and configuring them will need
additional options in the config file I guess. When such GPUs are available,
we will handle them.

Regards
-- Shree

-----Original Message-----
From: Sim...@cs... [mailto:Sim...@cs...]
Sent: Thursday, May 27, 2010 7:47 PM
To: viz...@li...
Subject: Re: [vizstack-users] viz-desktop should now work with bezels

> -----Original Message-----
> From: Kumar, Shree [mailto:shr...@hp...]
> Sent: Thursday, 27 May 2010 3:57 PM
> To: viz...@li...
> Subject: Re: [vizstack-users] viz-desktop should now work with bezels
>
>
> I'm an atheist, but will take the compliments :-)
>
> > Aside from being caught out at first by using 'none' instead of
> > 'None', and having to rearrange the cabling (thankfully
> displayport is
> > much nicer than DVI in that regard), it was as simple as
> creating the
> > tiled display and adding the clip_last_block line. Running
> from the console works perfectly.
>
> Yeah, the cabling is irregular with this setup. Is this setup
> hard to understand ?
>
Not too hard once I realised how it needed to be arranged.

> One reason I haven't add this to the vs-manage-tiled-displays
> tool is : I find it complicated to explain !
> Any hints w.r.t explaining this would be useful.
>
You're arranging the blocks in rows and disabling the right-most output of each row -  explaining it like that should help . . . but I've spent the whole evening trying to think of a good concise way to explain it, and so far nothing. I'll think about it some more and see if I can suggest anything, but it really is quite hard to explain clearly.

> > Thanks for implementing this so quickly!
>
> As I said, this turned out to be fairly simple in the end.
> The same mechanism works with QuadroPlexes too, but nobody
> seems to be using more than one QuadroPlex at the moment with
> VizStack. And now others can use this too.
>
It's definitely a very nice feature.

One question: is it possible (or meaningful) to use a value of [None,1] or similar? It seems like it would disable the first output on the GPU rather than the second, which might be useful in some cases . . .

Also, does it /have/ to be the last GPU in the row? It might be nice to be able to set up, say, a 5x5 display with the odd monitor in each row being in the middle. Obviously very low priority, but still possibly useful. Also, how hard would it be to support arbitrary mixing of different types of blocks? We have a 5x5 system (completely unrelated to the stuff I'm working on right now - it uses CGLX as the display system) which has the fifth column made up of two vertical pairs and a singleton, with the rest of the display made up of horizontal pairs - as it stands I think Vizstack would have to have the whole fifth column made up of singleton monitors. In practice it's probably not an issue, but if supporting arbitrary mixes of blocks is easy it might be something to consider for a future version.

And one final question: if you have a single GPU with four outputs, would you have to make each block 4x1, or could you make them 2x2? i.e. to get a 3x2 display would you need to have two rows of 4x1 blocks, or could you use one row of 2x2 blocks? I doubt there's any hardware out there where this would be an issue, but I imagine there's stuff on the horizon . . .

Lots of extra questions - none of them very critical for us, since with this update you've resolved the last outstanding issue we had.

Thanks,

Simon
------------------------------------------------------------------------------

_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users

------------------------------------------------------------------------------

_______________________________________________
vizstack-users mailing list
viz...@li...
https://lists.sourceforge.net/lists/listinfo/vizstack-users