AccessGridWorkingGroup < Main

EditAttachPrintable

r2 - 24 Dec 2007 - 00:01:37 - JasonBellYou are here: ARCS Wiki >

Main Web > Videoconferencing > AccessGridWorkingGroup

-- DavidBannon - 06 Dec 2007

Access Grid Working Group

Members - Jason Ozolins, Jason Bell, Greg Wickham, Leigh Gordon, Chris Willing

Three broad activities have been identified -

Access Grid Working Group

Network Issues - (multicast, bridges, run servers, provide toolkit packages etc.)

Item	Actions	Status
Develop virtual machine which includes multicast beacon client and multicast/unicast bridge services.	This VM to be deployed on each of the ARCS grid gateway machines. This will provide an Australia wide network of multicast/unicast bridges as well as a wider view of multicast connectivity to assist multicast network troubleshooting.	new
Provide a multicast/unicast bridge to run directly on the AARNet3 network.	Such a bridge will have good multicast connectivity, unencumbered by the additional network issues inherent in any institutional based bridge. having a bridge directly on AARNet3 will in itself also provide a more reliable unicast connection mechanism. Participating venue clients would need to be configured to use the new bridge as their default connection mode. the current AG toolkit already provides a (generally unused) mechanism for utilizing a particular bridge out of a peered network of bridges. When the AARNet3 bridge commences, it could provide such a peered network of bridges – in this case, a network of one.	new
Provide access to a known AARNet support contact for multicast issues.	Although some sites discourage their users contacting AARNet directly, other sites are keen to have some sort of AARNet helpdesk available or to be able to contact AARNet engineers when necessary.	new
Maintain AG2 and AG3 venue servers, bridges	The APAG AG3 and AG3 venue servers and bridges are currently run and maintained at UQVislab with support from QCIF. This work was previously supported by the APAC grid program and currently ARCS proto-NeAT. ARCS support will allow this to continue (including when the physical hardware is moved to AARNet)	ongoing

Local Site Deployment issues - (QA, usability, training etc.)

Item	Actions	Who	Status
Operate a Quality Assurance program.	under the previous APAC grid program and more recently ARCS proto-NeAT, the QA program developed by CQU’s Jason Bell is already established world wide and all ARCS AG nodes should participate in the QA process. preparation for, and participation in, the QA process is itself a valuable form of training for AG node operators thus improving user expertise. It also provides a mechanism for new users to learn about additional operating techniques as well as the range of available shared applications.	Jason Bell	In Progress
Establish a support Service	We need to determine how to do this. Perhaps - * Phone would seem most appropriate. When someone needs to join a meeting, they cannot wait for an email to go to RT. * A much less satisfactory system might be a mailing list, user blasts off a message and it goes to multiple people, perhaps one will respond in time. RT would provide this. * Email (and RT) would be fine for low priority situations.	David	new
Establish a serious incentive for sites to be QA'ed.	Any ARCS funding support to individual sites should be conditional on those sites having their nodes QA’d regularly ? Publish a list of sites that are QA'ed and establish in people's minds that sites that are not on the list are not playing the game.	Jason Bell	In Progress
Provide improved AG documentation	Although a vast amount of AG documentation exists [2] (much of it with support from APAC and ARCS proto-NeAT), it is often not targeted at completely new “average users”. A range of such documentation should be provided, perhaps including a “newbie” install guide, as well as an update of the now out of date AG2 online documentation [3]. - a range of additional documentation about solving specific common problems should also be created e.g. how to run multiple AG clients in a NAT’d network. - documentation from the QCIF/ARCS Workshops should be made available online for those unable to attend the live versions. David - documentation is great but not a substitute for ease of use.	Jason Bell	In Progress
Provide AG Workshops	In order to improve user expertise, a number of AG Workshops should be run throughout the year. Support could include costs involved in actually hosting the workshop, perhaps including participants’ airfares and accommodation (for “preferred” support sites?). These workshops would be modelled on the recent QCIF/ARCS Access Grid Workshop [4]. David - training is great but not a substitute for ease of use. Our training should be focused on local help people rather than end users.	Jason Bell	In Progress

Development Activities

Item	Actions	Status
Develop an automatic bridge failover mechanism.	A peered network of bridges can already be configured but no automatic failover migration to another bridge is available. Some programming effort would be required to implement this feature. David - Maybe all we need initially is a means of ensuring the list of bridges presented to user was checked recently ?	new
Develop AG Toolkit packages with special “ARCS defaults”	The AG software is difficult for the “average user” to configure and run. At the same time, some of the operational modes suggested above to improve reliability and stability e.g. unicast networking, require some reconfiguration by the user. Even configuration of a single webcam is apparently beyond some users. Much of this manual configuration could be preset into customised packages to be installed instead of the default AG packages.	new
Investigate & provide bug fixes for AG toolkit and related software	One of the “preferential support” services to be provided could be the investigation and fixing of bugs identified by (QA’d) ARCS sites. Minor enhancements could also be provided in the same way. - an extension of this could be provision of a general user helpdesk system, again with preference given to QA’d sites. This should not become a substitute for attendance at the regular testing sessions already provided.	new
Provide AG Toolkit packages	all Linux AG Toolkit and associated packages (world wide) are currently provided by UQVislab/QCIF (again, with previous support from APAC and now ARCS proto-NeAT). ARCS support will ensure this activity can continue. It is important not only in providing packages for end users, but also in the testing and bug fixing cycle inherent in the preparation of the packages. It has also provided entrée into the circle of AG programmers with access to the CVS code repository at Argonne National Laboratory. This is a significant advantage over other collaboration applications in the provision of new features and bug fixes.	ongoing
Establish a regional jabber server as the APAG server’s text tool service.	This would eliminate the current single point of failure associated with use of the jabber server at Argonne National Laboratory.	new
Improve AG user interface	The AG user interface is considered by some to not be user friendly, although it is often difficult to extract specific details. Enhancements to the GUI (and possibly other areas of the AG toolkit) could be undertaken in response to users’ specific requests - other developmental projects could also be considered e.g. EVO compatibility. Solicit input from non AG experienced people.	new

See also

http://www.accessgrid.org/documentation
http://www-unix.mcs.anl.gov/fl/research/accessgrid/documentation/VENUE_CLIENT_MANUAL_HTML/VenueClientManualHTML.htm
http://www.qcif.edu.au/education/workshop/

Main

Quick Links

Admin

Users
Groups

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding ARCS Wiki? Send feedback