1. At the February meeting we agreed; - the requirements for Network Monitoring found at http://icfamon.dl.ac.uk/papers/WP7/netmon-requirements.htm - 7 sites to act as “pre-testbed” for network monitoring Bologna, CERN, IN2P3, NIKHEF, Rutherford and Daresbury - Goal, by end of March, to install and configure, - PingER software and Web-based access to the data - Purchase and install RIPE NCC TTM boxes with access to the related data via the RIPE Web site Network Monitoring Robin Tasker, Daresbury Laboratory, 9 May 2001

2. Where are we now? -PingER - installed and operational at Bologna, Rutherford and Daresbury. - IN2P3 planning dedicated m/c, waiting effort -> mid May - CERN already have PingER running (on suncs02.cern.ch) but will install m/c dedicated for our purpose soon - NIKHEF ? RIPE NCC TTM Box - installed and operational at Daresbury and CERN (already had one!) - ordered/purchased at Bologna, IN2P3, Rutherford, awaiting installation - NIKHEF ?

3. So what does http://icfamon.dl.ac.uk/ppncg/datagrid.html look like right now?

4. and in more detail at the testbed sites?

5. Last 14 days pkt loss and rtt between Daresbury and Bologna

6. and there’s more…..

7. So what’s next? - Ability to extract data from various repositories (both for PingER and RIPE NCC), collate it and provide a report for the time period / parameter of interest. How? Probably not by storing ”raw output" in a database, but by storing the necessary tools to allow access to the data to be viewed. - Need a straightforward Web-based tool to assess how the network is between my site and wherever, right *now*. Meets one of our requirements, but need to ask, why does it make the Grid a better place to be?

8. And then there’s the Network Weather System http://nws.npaci.edu/NWS/ basically, - a distributed system that periodically monitors and dynamically forecasts the performance various network and computational resources can deliver over a given time interval. - The service operates a distributed set of performance sensors (network monitors, CPU monitors, etc.) from which it gathers readings of the instantaneous conditions. - It uses numerical models to generate forecasts of what the conditions will be for a given time frame.

9. And there’s more.. - the NWS has been developed for use by dynamic schedulers and to provide Quality-of-Service readings in a networked computational environment - Each prototype forecasts process-to-process network performance (latency and bandwidth) and available CPU percentage for each machine that it monitors. - The AppLeS scheduling methodology makes extensive use of its facilities and prototype implementations for Legion and Globus/Nexus have been developed.

10. But why do it? No doubt : - it’s the fashionable thing to do right now; - it attracts money possibly because, - it’s an easy concept to sell to the layman but - need to understand the benefits to the Grid. - need to be convinced as to the value of this activity and even if we want to do it - do we need yet another set of monitoring stuff deployed; - can’t we use the PingER or RIPE data with a “predictive engine” to do essentially the same thing