[AG-TECH] Multicast Debugging Information

[Michael Daw]

I'm currently writing a multicast extension to the UK e-Science Grid Network
Monitoring Toolkit that uses iperf to show stats on an historical basis. It
works like this: choose the period you want to know about, the sites you're
interested in and whether you want to know about bandwidth, jitter and/or
loss. Then you get some neat graphs.

If there's the appropriate demand (and the time/resource), I might be able
to leverage this on to AG2.0 (after I've got it working in the Toolkit, of
course, and as long as the authors of the bits of the toolkit I'm using to
do the graphing are happy).

If you want a sneak preview, let me know. (I'm not going to give out a url
because it doesn't always work, as you'd expect with work-in-progress.)

--Mike

> -----Original Message-----
> From: owner-ag-tech at mcs.anl.gov [mailto:owner-ag-tech at mcs.anl.gov]On
> Behalf Of Jennifer Teig von Hoffman
> Sent: 21 February 2003 11:46
> To: Bill Nickless
> Cc: ag-tech at mcs.anl.gov
> Subject: Re: [AG-TECH] Multicast Debugging Information
>
>
> Howdy Bill,
>
> I support your idea of having this networking information captured by
> the Venues Client. I also wonder if there might be a bigger opportunity
> here too, in building a Grid Service in AG2 for multicast debugging;
> this of course would still require operators to run it, but if all (or
> many) operators in a session where a site is having difficulty were
> running such a service, perhaps it could gather even more useful
> information and support networking staff in other ways?
>
> - Jennifer
>
> Bill Nickless wrote:
>
> > Thank you Ed,
> >
> > I agree completely that the first and foremost priority is to make the
> > meeting work for the attendees.  You're absolutely right.
> >
> > However, if the network doesn't work properly for a meeting, that fact
> > needs to be communicated to the network people so that it can be fixed.
> >
> > And it's still true that the network people need to know all of the
> > things I mentioned below: source/group IP addresses and a receiver
> > that's not working.
> >
> > The beacon can fill that requirement--but the node operators still
> > have to be sure the beacon client is running, and then tell the
> > network people about problems they run across.
> >
> > At 01:25 PM 2/20/2003 -0800, Ed Ritenour wrote:
> >
> >> Bill
> >>
> >> From an operations point of view I agree with the first three items,
> >> but our
> >> goal is to make the meeting a success. We have found that our users
> >> don't
> >> necessarily care if the video is down as long as they can still
> >> participate in
> >> the meeting. To do that they need need audio and slides. We have
> >> found from
> >> past experience that it is unlikely a network problem will be
> >> resolved during
> >> the testing process anyway and waiting up to the last minute to attempt
> >> bridging or calling into an audio bridge makes it difficult to have
> >> successful
> >> start.  By moving forward early on there is still time to finish up
> >> the power
> >> point slides and any other in room issues. The client is still happy
> >> and if the
> >> network comes up during the meeting that is all for the better. I
> >> realize this
> >> makes it more difficult for troubleshooting so we should
> provide as much
> >> inforamtin then ensure the clients needs are met.
> >>
> >> Ed
> >
> >
> > ===
> > Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630
> > 252 7390
> > PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7
> > nickless at mcs.anl.gov
>
>
>
>