Examples of the use of PingER

Supported by DOE MICS

Web page contents

Below are some actual examples of the use to which the PingER data and reports have been put.

Identifying sites to upgrade

From the PingER reports, we identified that some U.S. universities had poor to bad connectivity to ESnet sites. This was impeding some collaborations. In 1997, a working group was formed by the ESnet Steering Committee (ESSC) to review the situation and provide recommendations. We selected the top 20 universities (ranked by DoE funding) which did not have direct ESnet connections and made sure they were all monitored by PingER. After reviewing the results, we identified those (there were 4) with very poor (> 5% packet loss) and poor (> 2.5% loss) connectivity (there were 8) over a period of 4 months. This list was then reviewed to look at the existing plans for improved connectivity (in particular several of the universities were about to join the vBNS). The information was then provided to the ESnet management to evaluate the cost of prviding direct ESnet connections for each of the universities. This exercise was repeated a year later, except the threshold was reduced to 1%. This time there were 2 with poor packet loss (> 2.5%) and 8 with acceptable packet loss (>1%).

Choosing an ISP for home connectivity

In 1996, SLAC wanted to recommend a ISDN Internet Service provider (ISP) for people wishing to connect to SLAC from their homes in the San Francisco Bay Area. To evaluate the connectivity that the various ISPs could provide we decided to use PingER to monitor the ISP gateways in areas where we had several potential SLAC users. The results enabled us to select an ISP who had low loss and good RTT. We continued the monitring after selecting the ISP and used it to request improvements to and identify problems with the ISP. We also used the information to recommend a second ISP and remove our recommendation on the first ISP. Finally due to inconsistent performance we removed all recommendations for ISPs and provided our own ISDN service.

In 1999, SLAC wanted to recommend a DSL ISP for people wishing to connect to SLAC from their home. There were 2 major contenders, one of which was about twice the price of the other. We needed to compare the performances of the 2 ISPs, so we set PingER to monitor nodes on both networks from SLAC. We discovered that the TCP thruput of the more expensive ISP was an order of magnitude better. This was very valuable information that we were able to provide to prospective users to help in making a decision.

Setting expectations for a collaboration

Several High Energy Physics (HEP) experiments have introduced the concept of regional computer centers. Typically there a few of these (e.g. BaBar regional computer centers in France, Italy and the U.K. as well as the main center at SLAC). These centers are expected to perform much of the computing required by the collaboration and so need good connectivity to the experiment in order to get a copy of the data and to be able to share the results. By using PingER to measure the loss and RTT, we are able to provide expectations for the performance for bulk data transfer and other applications.

When putting together the Particle Physic Data Grid (PPDG) proposal (a collaboration of 3 universities and 6 Labs), it was very valuable to be able to look at the PingER data and evaluate what the performance between the sites would be like with the existing production links. As a result of this we put together a web site for the PPDG collaboration focussed on the PingER results for the collaborators.

Deciding where to site a software development effort

The BaBar experiment at SLAC needed to locate a software code porting activity at one of the collaborator sites with expertise in a particular Unix platform. We used PingER to evaluate the performance between SLAC and the various potential university collaborator sites to see which one had appropriate connectivity and performance. This information was a major selection factor in the final choice.

Setting expectations for VoIP

Several national Labs (CERN in Geneva, DESY in Hamburg, FNAL in Chicago IL, LBNL in Berkeley CA, and SLAC in Menlo Park CA) have set up a pilot Voice over IP (VoIP) project to evaluate the utility and performance of this technology. By comparing the results from PingER with various ITU recommendations for loss, RTT and jitter, together with the perceptions of voice quality from the pilot, we are able to determine how well VoIP might work between various pairs of sites.

Choosing routes

SLAC has two connections to the Internet. One is via ESnet, the other via Stanford University. The performance of both these connections is excellent, however, the way the 2 network peer with other ISPs can differ dramatically. By reviewing the performance and routes from Stanford and from SLAC to sites of interest to SLAC we can see whether sending packets via Stanford or via ESnet (SLAC's default routing is via ESnet) should provide better performance for SLAC.

In one example of this we compared the performance between SLAC/ESnet or Stanford and Colorado State (see Routing via Campus), discovered it was much better (factor of 2 less RTT) via Stanford, and then worked with the ESnet NOC to change ESnet's routing to Colorado State to make a big improvement.

In another case we compared the performance between SLAC/ESnet or Stanford and PacBell's Internet. In the former case the traffic went via the STARTAP in Chicago and sustained RTT's of around 130 msec. In the latter case it went via Palo Alto and sustained an RTT of about 30 msec.

Created 9/17/99. Revised 17 September 1999
URL: http://www-iepm.slac.stanford.edu/pinger/uses.html
Comments to iepm-l@slac.stanford.edu