SLAC logo

Probelms with performance between SLAC and IHEP.SU Network logo

Les Cottrell and Warren Matthews. Page created: September 19, 2001, last update September 19, 2001.

Central Computer Access | Computer Networking | Network Group | ICFA-NTF Monitoring
SLAC Welcome
Highlighted Home
Detailed Home


Louise Addis of SLAC reported that the SLAC library folks could not use ssh to execute commands at The packet loss was measured to be over 80%:
--- ping statistics ---
103 packets transmitted, 12 packets received, 88% packet loss
round-trip min/avg/max/mdev = 213.072/219.313/234.612/5.784 ms
ksa@osiris $
Packet losses of this magnitude (in fact losses over 10-12% make it difficult to maintain a connection) will quickly lead to the TCP connection being broken.


The traceroute indicates that the route is via ESnet to Internet 2 to NorduNet to various Russian networks. Pipechar indicates that the path is OC3 through NorduNet and then drops to T3. Pingroute indicates that the losses start to occur between St Petersburg and rbnet.RUN.Net, and gets really bad (90%) on the last hop to Looking at the PingER plots from SLAC to for 1000 Byte and 100 Byte pings shows that this route has heavy loss, and that it has got worse somewhere around September 18th. The tabular output for from PingER indicates that the median daily losses have increased from about 8% to about 12% on September 18th. This is way below the over 80% reported by Louise to Looking at the hourly losses for September 18th, 2001, it appears that they are varying between 0 and 20%, again way below the ~80% reported by Louise. Pings measured around 8:40pm 9/19/01 PDT from to show losses of 90% for 105 packets. The losses appear quite bursty, e.g. most of the packets will be lost (not respond in 1 second) but then a burst of 4 or 5 consective pings respond.
---- ( PING Statistics ----
105 packets transmitted, 10 packets received, 90% packet loss
round-trip (ms) min/avg/max = 212/216/223 (std = 3.48)
Pings to measured around the same time on the other hand show much lower packet losses of less than 10%:
---- ( PING Statistics ----
107 packets transmitted, 102 packets received, 4.7% packet loss
round-trip (ms) min/avg/max = 211/215/241 (std = 5.37)
Thus it appears that the major part of the problem is in the IHEP LAN, or the machine usparc itself. Comparing the pingroute from SLAC to witrh the pingroute above from SLAC to confirms the above conclusions.
Page owner: Les Cottrell