June 2008 - Ag-tech - mailman3.cels.anl.gov

Summit to create a Cyber-Community to Advance Deaf and Hard-of-Hearing Individuals
by Matthew Leszczenski 26 Jun '08

26 Jun '08

Summit to Create a Cyber-Community to Advance Deaf and Hard-of-Hearing Individuals in STEM (DHH Cyber-Community) June 26, 2008 Rochester Institute of Technology 8:30 PM Eastern Standard Time http://summit.rit.edu There will be an Access Grid demo in the Rochester Institute of Technology Venue tonight. All those that wish to join in on the discussion and demonstration of the RIT collaboration grid, and the potentials of using cyberinfrastructure to assist the deaf and hard-of-hearing, are welcome to attend. We will be running mostly DV streams, with some H264 and only a single H261 stream, however if you have H261 streams broadcasting that can still be shown. Matthew Leszczenski - Technical Assistant and Eagle Scout - Undergraduate NSSA Major @ RIT - Collaboration Technology Developer @ RIT Research Computing department

1 0

AG Internationalization
by Tom Uram 26 Jun '08

26 Jun '08

One issue that came up at last month's AG Retreat was that of internationalization. In some ways (for example, chat), we support it, but we generally do not (for example, the VenueClient menus). I'm curious to know how useful people consider this, so a question for the non-English-speaking AG community: - How much of an increase in Access Grid usage do you think you'd see in your region if there was a native language version of the Venue Client? - Would you be willing to commit a small amount of time to translating the user interface into your native language? Please don't hesitate to answer. If the response is sufficient, I'll pool resources to make this happen. Thanks, Tom Uram

1 0

SIGGRAPH Chapter Seminar over AG: 4th July 2pm "Visual Algorithms and their Role in Modern Digital Feature Film Production"
by Martin Turner 25 Jun '08

25 Jun '08

ProgId Word.Document Generator Microsoft Word 11 Originator Microsoft Word 11 *** Apologies for Cross-posting *** " Visual Algorithms and their Role in Modern Digital Feature Film Production" Simon Robinson Seminar on Friday 4th July 2008; 2pm-3pm BST Room1:10 Kilburn Building the University of Manchester UK Access Grid Virtual Venue: " University of Manchester Room1:10" http://manchester.siggraph.org/ Based around a light introduction to live-action feature-film compositing, this talk gives an overview into the real-world application of signal-processing in post-production. While human artistry itself is still the hub of 2D digital effects work, I show how it can be greatly assisted today by the use of appropriate algorithms with appropriate implementations. As the film industry is rapidly evolving, I will also identify our favourite research areas for the next generation of tools. No equations will be harmed during this discussion. ** This is part of the ACM SIGGRAPH University of Manchester Professional Chapter Seminar Series: Access Grid instructions below. ** ****** Anyone wishing to view a seminar via Access Grid should note the following. Please check the Jabber room shortly before the start of the seminar to find if ScreenStreamer is to be used. Access Grid Support Centre Virtual Venue: " University of Manchester Room1:10" Jabber room: university-of-manchester-(1.10)(sam.ag.manchester.ac.uk)(a)conference.mcs.anl.gov ScreenStreamer: * Preferably use ScreenStreamer software - go to http://www.memetic-vre.net/software/ScreenStreamer/ScreenStreamer.php and select room "University of Manchester (1.10)" from the AGSC section. Grab the screen feed (by clicking on it) from the screenstreamer window and resize it - more info can be found on http://www.memetic-vre.net/software/ScreenStreamer. * Alternatively, the screenshot (not animated) can be accessed at http://192.150.184.66:7890 (this IP might change for some sessions - please check Jabber). technical assistance regarding the Access Grid, please contact the Access Grid Support Centre. Non-UK Access Grid nodes are advised to contact the Access Grid Support Centre to check connectivity before the date of the seminar. possible, please let us know in advance if your site intends to join a seminar. ****** Martin J. Turner Visualization Team Leader Research Computing Services The University of Manchester Kilburn Building, Oxford Road Manchester, M13 9PL t : +44 (0) 161 275 0613 m : +44 (0) 7990 918 509 e : martin.turner(a)manchester.ac.uk w : www.manchester.ac.uk/researchcomputing

1 0

Re: [AG-TECH] VenueManagement cannot connect
by Christoph Willing 24 Jun '08

24 Jun '08

On 25/06/2008, at 1:40 AM, Jeremy Mann wrote: > We recently upgraded our venue server to a new machine and now Venue > Management does not connect locally and I do not know how to fix this. > Any ideas? Jeremy, This can be due to a disparity between the name or IP address which the venue server is using to make its services available and the name/ address being used to connect with the VenueManagement tool. For instance, if your server is offering its services as 192.168.100.100, then you can't connect using "localhost" (usually set to 127.0.0.1). There are some quirks with name setting in /etc/hosts (especially if using DHCP on the server machine) which can cause problems like this. Could you send me (perhaps privately) your venue server log file (~/.AccessGrid/Logs/VenueServer.log) - just a section showing the the server starting up and then a connection attempt from the VenueManagement tool (if the connection attempt appears in the venue server log file)? Also a copy of your /etc/hosts file? Also, what name are you using in the local VenueManagement tool that you're trying to connect with? BTW, you say you cannot connect locally; can you connect remotely? chris > 06/24/2008 10:35:59 AM -1211201856 VenueManagement > VenueManagement3.py:435 DEBUG VenueManagementClient.ConnectToServer: > Get venues from server > 06/24/2008 10:35:59 AM -1211201856 VenueManagement > VenueManagement3.py:521 ERROR VenueManagementClient.ConnectToServer: > Can not connect.: > Traceback (most recent call last): > File "/usr/bin/VenueManagement3.py", line 438, in ConnectToServer > vl = self.server.GetVenues() > File "/usr/lib/python2.5/site-packages/AccessGrid3/AccessGrid/ > interfaces/VenueServer_client.py", > line 142, in GetVenues > self.binding.Send(None, None, request, > soapaction="urn:#GetVenues", **kw) > File "/usr/lib/python2.5/site-packages/ZSI/client.py", line 265, > in Send > self.h.connect() > File "/usr/lib/python2.5/site-packages/M2Crypto/httpslib.py", line > 50, in connect > self.sock.connect((self.host, self.port)) > File "/usr/lib/python2.5/site-packages/M2Crypto/SSL/Connection.py", > line 167, in connect > self.socket.connect(addr) > File "<string>", line 1, in connect > error: (111, 'Connection refused') > > System is Slack 12.1 with the latest 12.1 package from the vislab > people. > > -- > Jeremy Mann > jeremy(a)biochem.uthscsa.edu > > University of Texas Health Science Center > Bioinformatics Core Facility > http://www.bioinformatics.uthscsa.edu > Phone: (210) 567-2672 > Christoph Willing +617 3365 8350 QCIF Access Grid Manager University of Queensland

1 0

VenueManagement cannot connect
by Jeremy Mann 24 Jun '08

24 Jun '08

We recently upgraded our venue server to a new machine and now Venue Management does not connect locally and I do not know how to fix this. Any ideas? 06/24/2008 10:35:59 AM -1211201856 VenueManagement VenueManagement3.py:435 DEBUG VenueManagementClient.ConnectToServer: Get venues from server 06/24/2008 10:35:59 AM -1211201856 VenueManagement VenueManagement3.py:521 ERROR VenueManagementClient.ConnectToServer: Can not connect.: Traceback (most recent call last): File "/usr/bin/VenueManagement3.py", line 438, in ConnectToServer vl = self.server.GetVenues() File "/usr/lib/python2.5/site-packages/AccessGrid3/AccessGrid/interfaces/VenueServer_client.py", line 142, in GetVenues self.binding.Send(None, None, request, soapaction="urn:#GetVenues", **kw) File "/usr/lib/python2.5/site-packages/ZSI/client.py", line 265, in Send self.h.connect() File "/usr/lib/python2.5/site-packages/M2Crypto/httpslib.py", line 50, in connect self.sock.connect((self.host, self.port)) File "/usr/lib/python2.5/site-packages/M2Crypto/SSL/Connection.py", line 167, in connect self.socket.connect(addr) File "<string>", line 1, in connect error: (111, 'Connection refused') System is Slack 12.1 with the latest 12.1 package from the vislab people. -- Jeremy Mann jeremy(a)biochem.uthscsa.edu University of Texas Health Science Center Bioinformatics Core Facility http://www.bioinformatics.uthscsa.edu Phone: (210) 567-2672

1 0

Re: [AG-L] Lastest kernels (Fedora) causing issues with the AG Software
by Thomas D. Uram 23 Jun '08

23 Jun '08

It's a problem of the current SVN code that's included in the 3.2 pre-beta packages. The problem is due to services being optionally loaded inline rather than run as separate processes. This is controlled by an inlineClass option in the .svc file. Your fix of using a random string in the startupFile name is very similar to the approach that I had in mind, and that I thought was already in place. I'm puzzling over that at the moment... I'd suggest you commit the fix using getrandbits and cut new packages. We may change it later, but getrandbits will solve the problem for now. Tom On 6/23/08 9:51 PM, Christoph Willing wrote: > > On 24/06/2008, at 9:27 AM, Christoph Willing wrote: > >> >> On 23/06/2008, at 11:58 AM, Jason Bell wrote: >> >>> Colleagues >>> >>> This is just a quick email to warm about issues in regards to updating >>> to the latest kernels in Fedora. >>> >>> It has been found that using kernels 2.6.25.6-27.fc8 and >>> 2.6.25.4-10.fc8 >>> (Fedora 8) has caused issues in regards to "multiple instances of vic >>> (producer and service) "locking up". Basically, only one of the >>> streams >>> will transmit, whilst the others will lock up. >> >> >> This isn't just a Fedora thing, I just had the same problem with >> another distro upgraded to 2.6.25.8 (although no vic lock ups in this >> case). Rather, its a kernel version (2.6.25) issue - in particular >> its interaction with python. > > > More info - I can replicate this bug with a clean install of 3.2 with > earlier kernel versions too. This means the problem is not a Linux > kernel version issue and, by extension, won't be limited to Linux but > will affect all platforms. > > > chris > > >> For those in a hurry, here's short fix until something more elegant >> is devised: >> 1. edit your >> ~/.AccessGrid/local_services/VideoService/VideoService.py (or >> VideoProducerService/VideoProducerService.py) to include a new import: >> from random import getrandbits >> 2. then search for "os.getpid()" and replace it with "getrandbits(16)" >> 3. now restart your VenueClient >> >> >> For those interested in the background to the problem, each time >> VideoService.py is run (i.e. for each video device) an individual >> temporary startup file is created containing various startup >> parameters including the video device name (/dev/video0 etc.). Each >> of these startup files should have a unique name, normally >> constructed using the process id of the current (VideoService.py) >> process using python's os.getpid() function. Previously this returned >> a new pid for each service, but for some reason it now (with kernel >> 2.6.25) returns the process id of the VenueClient itself. This means >> that each of the startup files now has the same name (in fact each >> new one overwites the previous one) resulting in all vics being >> started with the same startup file. Each vic then tries to open the >> single video device named in that startup file. Only the first vic to >> run succeeds in grabbing the video device, the others trying to grab >> it just cause problems. >> >> Replacing os.getpid() with getrandbits() ensures that each of the vic >> startup files has a unique name so that all vics can run as configured. >> >> >> chris >> >> >> >>> An interesting side effect is that you cannot manually "kill" the >>> locked >>> up "vic" process. Though xkill seems to work. >>> >>> Additionally, if you add each stream manually (using configure node >>> service), rather than loading from a configuration, this appears to >>> work >>> fine. >>> >>> Will keep you posted when through testing has been conducted and any >>> possible resolutions found. >>> >>> Therefore, for now, I recommend not updating your kernel and/or >>> nvidia / >>> xorg drivers. >>> >>> We are also investigating whether there are any issues with out "Linux" >>> variants, but it appears that most other Linux distributions still only >>> run 2.6.24.xxx kernel, rather than 2.6.25.xxx, which appears to be the >>> problematic version. >>> >>> Thanks for your time, >>> Jason. >>> >>> -------------------------------------------- >>> Jason Bell, B.I.T. (Honours) >>> >>> Research Systems Support Officer >>> Information Technology Division >>> Central Queensland University >>> >>> Australian Research Collaboration Service >>> http://www.arcs.org.au/ >>> >>> E-mail : j.bell(a)cqu.edu.au >>> jason.bell(a)arcs.org.au >>> Work : +61 7 4930 9229 >>> Mobile : 0409 630897 >>> Postal : Building 19 >>> Central Queensland University >>> Bruce Highway >>> Rockhampton, Queensland, Australia, 4702 >>> -------------------------------------------- >>> Patience is a virtue. >>> >>> But if I wanted Patience, >>> I would have become a Doctor. >>> -------------------------------------------- >>> >>> >>> _______________________________________________ >>> accessgrid-l mailing list >>> accessgrid-l(a)lists.aarnet.edu.au >>> http://lists.aarnet.edu.au/mailman/listinfo/accessgrid-l >> >> Christoph Willing +617 3365 8350 >> QCIF Access Grid Manager >> University of Queensland >> >> >> >> >> _______________________________________________ >> accessgrid-l mailing list >> accessgrid-l(a)lists.aarnet.edu.au >> http://lists.aarnet.edu.au/mailman/listinfo/accessgrid-l > > Christoph Willing +617 3365 8350 > QCIF Access Grid Manager > University of Queensland > > > > > _______________________________________________ > accessgrid-l mailing list > accessgrid-l(a)lists.aarnet.edu.au > http://lists.aarnet.edu.au/mailman/listinfo/accessgrid-l >

1 0

Re: [AG-L] Lastest kernels (Fedora) causing issues with the AG Software
by Christoph Willing 23 Jun '08

23 Jun '08

On 24/06/2008, at 9:27 AM, Christoph Willing wrote: > > On 23/06/2008, at 11:58 AM, Jason Bell wrote: > >> Colleagues >> >> This is just a quick email to warm about issues in regards to >> updating >> to the latest kernels in Fedora. >> >> It has been found that using kernels 2.6.25.6-27.fc8 and >> 2.6.25.4-10.fc8 >> (Fedora 8) has caused issues in regards to "multiple instances of vic >> (producer and service) "locking up". Basically, only one of the >> streams >> will transmit, whilst the others will lock up. > > > This isn't just a Fedora thing, I just had the same problem with > another distro upgraded to 2.6.25.8 (although no vic lock ups in > this case). Rather, its a kernel version (2.6.25) issue - in > particular its interaction with python. More info - I can replicate this bug with a clean install of 3.2 with earlier kernel versions too. This means the problem is not a Linux kernel version issue and, by extension, won't be limited to Linux but will affect all platforms. chris > For those in a hurry, here's short fix until something more elegant > is devised: > 1. edit your ~/.AccessGrid/local_services/VideoService/ > VideoService.py (or VideoProducerService/VideoProducerService.py) > to include a new import: > from random import getrandbits > 2. then search for "os.getpid()" and replace it with "getrandbits(16)" > 3. now restart your VenueClient > > > For those interested in the background to the problem, each time > VideoService.py is run (i.e. for each video device) an individual > temporary startup file is created containing various startup > parameters including the video device name (/dev/video0 etc.). Each > of these startup files should have a unique name, normally > constructed using the process id of the current (VideoService.py) > process using python's os.getpid() function. Previously this > returned a new pid for each service, but for some reason it now > (with kernel 2.6.25) returns the process id of the VenueClient > itself. This means that each of the startup files now has the same > name (in fact each new one overwites the previous one) resulting in > all vics being started with the same startup file. Each vic then > tries to open the single video device named in that startup file. > Only the first vic to run succeeds in grabbing the video device, > the others trying to grab it just cause problems. > > Replacing os.getpid() with getrandbits() ensures that each of the > vic startup files has a unique name so that all vics can run as > configured. > > > chris > > > >> An interesting side effect is that you cannot manually "kill" the >> locked >> up "vic" process. Though xkill seems to work. >> >> Additionally, if you add each stream manually (using configure node >> service), rather than loading from a configuration, this appears >> to work >> fine. >> >> Will keep you posted when through testing has been conducted and any >> possible resolutions found. >> >> Therefore, for now, I recommend not updating your kernel and/or >> nvidia / >> xorg drivers. >> >> We are also investigating whether there are any issues with out >> "Linux" >> variants, but it appears that most other Linux distributions still >> only >> run 2.6.24.xxx kernel, rather than 2.6.25.xxx, which appears to be >> the >> problematic version. >> >> Thanks for your time, >> Jason. >> >> -------------------------------------------- >> Jason Bell, B.I.T. (Honours) >> >> Research Systems Support Officer >> Information Technology Division >> Central Queensland University >> >> Australian Research Collaboration Service >> http://www.arcs.org.au/ >> >> E-mail : j.bell(a)cqu.edu.au >> jason.bell(a)arcs.org.au >> Work : +61 7 4930 9229 >> Mobile : 0409 630897 >> Postal : Building 19 >> Central Queensland University >> Bruce Highway >> Rockhampton, Queensland, Australia, 4702 >> -------------------------------------------- >> Patience is a virtue. >> >> But if I wanted Patience, >> I would have become a Doctor. >> -------------------------------------------- >> >> >> _______________________________________________ >> accessgrid-l mailing list >> accessgrid-l(a)lists.aarnet.edu.au >> http://lists.aarnet.edu.au/mailman/listinfo/accessgrid-l > > Christoph Willing +617 3365 8350 > QCIF Access Grid Manager > University of Queensland > > > > > _______________________________________________ > accessgrid-l mailing list > accessgrid-l(a)lists.aarnet.edu.au > http://lists.aarnet.edu.au/mailman/listinfo/accessgrid-l Christoph Willing +617 3365 8350 QCIF Access Grid Manager University of Queensland

1 0

Re: [AG-L] Lastest kernels (Fedora) causing issues with the AG Software
by Christoph Willing 23 Jun '08

23 Jun '08

On 23/06/2008, at 11:58 AM, Jason Bell wrote: > Colleagues > > This is just a quick email to warm about issues in regards to updating > to the latest kernels in Fedora. > > It has been found that using kernels 2.6.25.6-27.fc8 and > 2.6.25.4-10.fc8 > (Fedora 8) has caused issues in regards to "multiple instances of vic > (producer and service) "locking up". Basically, only one of the > streams > will transmit, whilst the others will lock up. This isn't just a Fedora thing, I just had the same problem with another distro upgraded to 2.6.25.8 (although no vic lock ups in this case). Rather, its a kernel version (2.6.25) issue - in particular its interaction with python. For those in a hurry, here's short fix until something more elegant is devised: 1. edit your ~/.AccessGrid/local_services/VideoService/ VideoService.py (or VideoProducerService/VideoProducerService.py) to include a new import: from random import getrandbits 2. then search for "os.getpid()" and replace it with "getrandbits(16)" 3. now restart your VenueClient For those interested in the background to the problem, each time VideoService.py is run (i.e. for each video device) an individual temporary startup file is created containing various startup parameters including the video device name (/dev/video0 etc.). Each of these startup files should have a unique name, normally constructed using the process id of the current (VideoService.py) process using python's os.getpid() function. Previously this returned a new pid for each service, but for some reason it now (with kernel 2.6.25) returns the process id of the VenueClient itself. This means that each of the startup files now has the same name (in fact each new one overwites the previous one) resulting in all vics being started with the same startup file. Each vic then tries to open the single video device named in that startup file. Only the first vic to run succeeds in grabbing the video device, the others trying to grab it just cause problems. Replacing os.getpid() with getrandbits() ensures that each of the vic startup files has a unique name so that all vics can run as configured. chris > An interesting side effect is that you cannot manually "kill" the > locked > up "vic" process. Though xkill seems to work. > > Additionally, if you add each stream manually (using configure node > service), rather than loading from a configuration, this appears to > work > fine. > > Will keep you posted when through testing has been conducted and any > possible resolutions found. > > Therefore, for now, I recommend not updating your kernel and/or > nvidia / > xorg drivers. > > We are also investigating whether there are any issues with out > "Linux" > variants, but it appears that most other Linux distributions still > only > run 2.6.24.xxx kernel, rather than 2.6.25.xxx, which appears to be the > problematic version. > > Thanks for your time, > Jason. > > -------------------------------------------- > Jason Bell, B.I.T. (Honours) > > Research Systems Support Officer > Information Technology Division > Central Queensland University > > Australian Research Collaboration Service > http://www.arcs.org.au/ > > E-mail : j.bell(a)cqu.edu.au > jason.bell(a)arcs.org.au > Work : +61 7 4930 9229 > Mobile : 0409 630897 > Postal : Building 19 > Central Queensland University > Bruce Highway > Rockhampton, Queensland, Australia, 4702 > -------------------------------------------- > Patience is a virtue. > > But if I wanted Patience, > I would have become a Doctor. > -------------------------------------------- > > > _______________________________________________ > accessgrid-l mailing list > accessgrid-l(a)lists.aarnet.edu.au > http://lists.aarnet.edu.au/mailman/listinfo/accessgrid-l Christoph Willing +617 3365 8350 QCIF Access Grid Manager University of Queensland

1 0

Lastest kernels (Fedora) causing issues with the AG Software
by Jason Bell 22 Jun '08

22 Jun '08

Colleagues This is just a quick email to warm about issues in regards to updating to the latest kernels in Fedora. It has been found that using kernels 2.6.25.6-27.fc8 and 2.6.25.4-10.fc8 (Fedora 8) has caused issues in regards to "multiple instances of vic (producer and service) "locking up". Basically, only one of the streams will transmit, whilst the others will lock up. An interesting side effect is that you cannot manually "kill" the locked up "vic" process. Though xkill seems to work. Additionally, if you add each stream manually (using configure node service), rather than loading from a configuration, this appears to work fine. Will keep you posted when through testing has been conducted and any possible resolutions found. Therefore, for now, I recommend not updating your kernel and/or nvidia / xorg drivers. We are also investigating whether there are any issues with out "Linux" variants, but it appears that most other Linux distributions still only run 2.6.24.xxx kernel, rather than 2.6.25.xxx, which appears to be the problematic version. Thanks for your time, Jason. -------------------------------------------- Jason Bell, B.I.T. (Honours) Research Systems Support Officer Information Technology Division Central Queensland University Australian Research Collaboration Service http://www.arcs.org.au/ E-mail : j.bell(a)cqu.edu.au jason.bell(a)arcs.org.au Work : +61 7 4930 9229 Mobile : 0409 630897 Postal : Building 19 Central Queensland University Bruce Highway Rockhampton, Queensland, Australia, 4702 -------------------------------------------- Patience is a virtue. But if I wanted Patience, I would have become a Doctor. --------------------------------------------

1 0

Re: [AG-TECH] AG on the iPhone, anyone?
by Andrew Daviel 22 Jun '08

22 Jun '08

On Wed, 11 Jun 2008, R. P. C. Rodgers wrote: > In my previous message, I was focussed on the iPhone due to its announcement > today -- but the Nokia and openmoko devices would remain of interest > in this regard, and of course android is yet to really hit the streets. Re. the Nokia N800/N810, there is a camera intended for videoconferencing (facing the user on the N810), and there is python. There is a version of Gizmo which supports video, using gstreamer. All the APIs are documented and I imagine it would be possible to port AG (beyond my skill level, though). Of course the iPhone gets lots more media buzz because of the brand and the "pinch" GUI, but it has a smaller screen. There's a WiMax version of the N810 now in the US, working on Sprint. I'm stuck with finding hotspots or paying through the nose for EDGE via my phone (no unlimited data plans here, planless rate is 10c/Kb) -- Andrew Daviel, TRIUMF, Canada Tel. +1 (604) 222-7376 (Pacific Time) Network Security Manager

1 0