Comparison of ihep.ac.cn with cas.ac.cn March-April 2001Les Cottrell. Page created: March 19, 2001.Central Computer Access | Computer Networking | Network Group | ICFA-NTF Monitoring |
|
Dear Les, The Chinese Academy of Science will cut our dedicated line between KEK and IHEP. I have informed KEK. Dr. Yukio Karita has tested and compared the route from KEK to IHEP and from KEK to CAS. The latter is much worth than the former. I worry about the status of the new route from SLAC to IHEP. Would you please to trace the routes from SLAC to CAS and compare it with the route from SLAC to IHEP (Now, via the KEK to IHEP) ? Thanks a lot. Best Regards, ChuansongEarlier Chuansong had sent email to Yukio Karita of KEK Japan (the IHEP link connects directly from IHEP to KEK via a fiber).
> It is what a pitty to us that I have to tell you an information >that the Dedicated line between KEK and IHEP will be lost before >the end of June. It is because the cost of the line. The Network >Center of the Academy of Science will give us a 2Mbps bandwidth >DDN line, the cost is much lower than this line. > > I know that this line is a bridge which directly connect IHEP to KEK >and the world. It has satisfied us for many years in the scientific research >and international collaboration. We like it. But the things can not come >back. The directors of the Academy of Science have decided to cut it. > > We thank KEK very much for so many years help, both in >financial support and in technical support. > >Best Regards, > > Chuansong
Packet loss from flora.slac.stanford.edu to www.ihep.ac.cn < 1 in 100 packets: ----www.ihep.ac.cn PING Statistics---- 103 packets transmitted, 102 packets received, 0% packet loss round-trip (ms) min/avg/max = 339/902/3387 Packet loss from flora.slac.stanford.edu to www.cas.ac.cn about 10% ----www.cas.ac.cn PING Statistics---- 103 packets transmitted, 92 packets received, 10% packet loss round-trip (ms) min/avg/max = 429/464/515It is apparent that at the time of the measurements, CAS was much worse than IHEP. With the CAS packet loss email is OK, web access is tedious, FTPs will often completely fail, interactive access (telnet, ssh) will be almost impossible (see the Network Monitoring Tutorial for more ideas on impact of losses etc.)
Yukio Karita of KEK also made some traceroute and ping measurements from KEK to CAS and IHEP, which confirm the above differences and poor performance of the KEK - CAS link.
To ensure that the losses were not caused by ICMP rate limiting, we also used synack from SLAC to use the TCP session opening syn and syn/ack response for the web port (80) on www.cas.ac.cn to measure the RTT and losses.
***** Round Trip Statistics of SYN-ACK to www.cas.ac.cn (Port = 80) ****** 100 packets transmitted, 91 packets received, 9.00 percent packet loss round-trip (ms) min/avg/max = 463.135/1600.969/4311.713 (std = 1438.009) (median = 890.625) (interquartile range = 129.084) (25 percentile = 853.625) (75 percentile = 982.709)Ping measurements made 2 minutes later indicated reasonable agreement:
----www.cas.ac.cn PING Statistics---- 100 packets transmitted, 87 packets received, 13% packet loss round-trip (ms) min/avg/max = 436/699/954
The RTT and losses between SLAC and CAS (shown below) measured with 1 64 byte ping/second over a period of 10 hours starting at 20:16:29, 3/19/01 PST shows that the losses and RTTs are very variable. The summary for this period shows that the average loss was 19%. However, there were long periods with no loss at all.
----www.cas.ac.cn PING Statistics---- 36000 packets transmitted, 28878 packets received, 19% packet loss round-trip (ms) min/avg/max = 147/464/10499
Some early PingER results showing RTT and loss seen between SLAC and KEK, SLAC and IHEP and SLAC and CAS for the period covering the one second ping measurements from SLAC to CAS shown above indicate that losses to KEK are good, to IHEP are good to acceptable and to CAS are very poor to bad.
Dear Dr. Cottrell and Karita, We have received the result of the tests that you have done on May 19, 2001. And we found that the route from SLAC or KEK to the www.cas.ac.cn is not correct. Because a new Internet 2 link from Tsin-Hua university, via STAR TAP, to abilene was installed since the beginning of March. This new 10Mbps link will be shared by CERNET and CSTNet, but only for some research and development use, not for all the hosts of the two networks. When Tsin-Hua University announces our IP to the abilene, they included the host www.cas.ac.cn and many other hosts as well, making these hosts do not go through our normal international links, but going through the CERNET, STAR TAP and Abilene instead. The performance of CERNET depicted in "Average Round Trip Time and Packet Loss Measured from slac.stanford.edu to dns.edu.cn" is very poor. But our CSTNet is good. If the traffic going through the CERNET, it will be surely very poor. This should not be the case for IHEP use. Now we have asked them to correct this situation. Please do the same tests (traceroute and ping) again and send the result to us.Ping and traceroutes from xxx.cas.ac.cn to SLAC indicated that the losses were now less than 1%. Yukio Karita confirmed the performance by making ping and traceroute measurements from KEK to ww.cas.ac.cn. Similar results were obtained from SLAC where the loss was measured to be less than 0.05%. A PingER plot of the losses and RTTs indicates that performance improved dramatically around 2pm GMT March 30th.
The pipechar path characteristic measurement is unable to get beyond hop 23. As far as that goes it indicates that the bottleneck is 10mbps starting in the APAN network.
I do not understand why the traceroute from KEK should be going via the US, that certainly will introduce considerable extra delay. Comparing the traceroute from CAS to SLAC with the route SLAC to CAS it appears the routes are quite asymmetric (the * * *) is since the SLAC internal routers are in private address spaces. The route from SLAC to CAS is quite tortuous going via CalREN2/Internet 2 (in California) to Chicago STARTAP and thence to China. Going to Chicago and back adds about 80 msec to the route. The current route to ihep is more direct going from SLAC to Sunnyvale (about 5 5 miles away in Silicon Valley) across to KEK/Japan and thence to IHEP, however the round trip time is worse.