[just found this in my drafts folder] Thankyou Chris and also John for the detail. It appears clear the right approach is to ensure that the multicast infrastructure is performing: are there definitive tests or measurements that we can perform that may help specify a bridge issue rather than a node problem? We shall continue to look at bridging infrastructure that we can contribute. Tim
Tim Salmon Mathematical Applications Officer School of Mathematics and Statistics UNSW ________________________________________ From: John I Quebedeaux Jr [jo...@lsu.edu] Sent: Tuesday, June 04, 2013 10:47 PM To: Christoph Willing; Tim Salmon Cc: 'accessgrid-tech@lists.sourceforge.net' Subject: Re: [AG-TECH] unicast bridge I'd like to echo Chris' comment about letting admins know if there is an issue with a bridge (for me this list is fine for that). In my case, we have reliable multicast in across our statewide fiber network that just a few of our sites need to use our unicast bridge - which is there mostly for emergency problems and sometimes i won't notice if there is an issue with it right awayŠ. -John Q. -- John I. Quebedeaux, Jr. Louisiana State University; Biological Sciences Computer Manager LBRN; 437 Life Sciences Bldg. Baton Rouge, LA 70803; 225-578-0062; http://lbrn.lsu.edu On 6/4/13 3:07 AM, "Christoph Willing" <c.will...@uq.edu.au> wrote: > >On 04/06/2013, at 5:01 PM, Tim Salmon <t...@unsw.edu.au> wrote: > >> Is it appropriate for us at UNSW with our unicast-only network to set >>up a unicast bridge or is this more appropriately set up in a multicast >>environment to assist those that are stranded, like us, in a unicast >>world? >> >> P.S. anyone else in the Australia/AP area noticed general problems with >>reliability of bridges lately? > >Very broadly, the second option (bridge set up in multicast environment) >is the most useful and intended scenario. > >However its a free world and there is at least one use case where a >bridge setting up a bridge in a unicast environment could be appropriate. >In that case, all participants in your meetings would/should connect via >that same bridge. Connections via other bridges or via multicast wouldn't >work or, at best, would work only by chance. This is similar to >traditional multipoint VC meetings where participants connect to a common >MCU. This technique wouldn't be useful as a day to day mechanism to >connect to meetings though. > >About bridge reliability in general, if you experience problems its >better to tell its admins about it - either directly or via the >appropriate list (this list for APAG & AccessGrid.org bridges) - straight >away so the problem can be fixed. We'd rather have these services running >smoothly rather than have people stewing about things not working. > >chris > > >Christoph Willing +61 7 3365 8316 >Research Computing Centre >University of Queensland > > > > >-------------------------------------------------------------------------- >---- >How ServiceNow helps IT people transform IT departments: >1. A cloud service to automate IT design, transition and operations >2. Dashboards that offer high-level views of enterprise services >3. A single system of record for all IT processes >http://p.sf.net/sfu/servicenow-d2d-j >_______________________________________________ >accessgrid-tech mailing list >accessgrid-tech@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/accessgrid-tech > ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ accessgrid-tech mailing list accessgrid-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/accessgrid-tech
