Tim, I don't know specifically a definitive test - unless this counts: my version of testing involves having two nodes - putting one on multicast and another i use on different bridges and seeing how they interact (video/audio up) between the two nodes. I can test multicast this way between the bridge location in question and my multicast. The other test is multicast between bridges (if one isn't mine - otherwise it's usually redundant if i'm on multicast or not locally except to test my bridge) between my bridge and a remote bridge because multicast between the bridges would have to work... which helps verify i have multicast connectivity in/out of campus, in/out of state, in/out of country (in a particular directionish) or just between two external locations (and back to me if i have a third node for more fun and access grid games)...
In this way i've quickly established when i'm having multicast issues and approximately the scope (area - in or out of campus/state/country) between the two locations and then try to get the appropriate networking folks to start looking at it from the IP information i can give them. I've never had a bridge 'issue' locally - it's always been a network issue within a site where a client was running (except the one time i was working on the local bridge machine's firewall). Usually i can test my bridge and verify this to the site having client issues with it always turns out to be a networking issue there... Hope that gives some kind of help... Cheers, 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/23/13 7:22 PM, "Tim Salmon" <t...@unsw.edu.au> wrote: >[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
