Examples of the use of PingER

Supported by DOE MICS Link to SLAC Home Page

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%).

Identifying Last Mile Problems

From a detailed Case Study on NIIT Pakistan we were able to identify that the problem with connectivity to universities in Pakistan was not due to the performance of the Pakistani National Research and Education Network (NREN) supplied by PERN but rather due to the poor last mile connections to the university sites. These were dramatically congested. This was reported to the head of the Higher Education Commission (HEC) Atta ur Rahman and led to upgrading of the links to universities.

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.

Evaluating the Impact of Major Cable Cuts

When the major cables through the Mediterranean were cut in January and December 2008 the PingER data was used to evaluate which countries were affected, by how much and for how long. See the Effects of Fibre Outage through the Mediterranean and Effects of Mediterranean Fibre Cuts December 2008.

Quantifying the Impact of Changes

In July 2009, the Seacom submarine fibre cable went line, connecting East Africa at higher speeds and dramatically reduced Round Trip Times (RTT) to the Internet. Using the PingER data we were able to identify the effects via a Case Study.

Quantifying the Digital Divide

PingER has been used in many studies to quantify the discrepancy in Internet performance for developed countries/regions and developing countries regions, see for example: January 2009 Report of the ICFA-SCIC Monitoring Working Group

Comprehensive Nuclear-Test-Ban Treaty Organization

The CTBTO based in Vienna--- is engaged in monitoring the world for signs of nuclear explosions. The collected data and processed results are made available to authorized recipients in CTBTO Member States as well as a number of tsunami warning organizations. Many of the recipients, so-called National Data Centres, receive the data over a secure Internet connection. For this reason, they are interested in evaluations of the quality and available bandwidths for Internet connections in the African countries, as well as in Asia and other parts of the world that are on the low-end side of the so-called Digital Divide. They looked with interest at the data we publish in the PingER pages. More.


Identifying the optimal location to provide a HotMail service. Knowing the performance between PingER hosts in similar locations as the client and the various HotMail servers, one can optimize which server to access from the client.

Internet History

With measurements going back to 1997, PingER data provides a history of Internet performance. For example the uneven development of the Internet.

Used as Illustrations

Back to top

Created 9/17/99. Revised 5/18/2012..
Comments to