...
| Code Block |
|---|
/nfs/slac/g/net/pinger/pingerdata/hep/data/monitor.niit.edu.pk/ping-2010-12-26.txt.gz |
Still the most likely suggestion is congestion/queuing at some point along the path. The number of packets that would cause queuing of 200ms depend on the link speeds. Assuming 1500Byte packets the number of packets is as follows
| Code Block |
|---|
Link Mbps Pkts queued up
1000 16,667
100 1,667
10 167
1 17
|
It would be interesting to know the speeds of the links. I would be most suspicious of the last mile at the UETTAXILA end.
Another, less likely possibility is dynamic routing such that sometimes the traffic takes one route and at others a different one. You might set up a cronjob to gather traceroutes every 10 mins for a few days and look if you can see anything that could cause large changes. On the other hand I would expect these to be step changes.
The poor reachability of UETTAXILA makes the problem harder to diagnose.
The reduced RTT seen between 2010-11-12 thru 2010-11-20 corresponds with Eids holiday in Pakistan when people are not using their work Internet. Thus this is indicative of the inflated RTTs elsewhere being due to congestion.
Change in minimum RTT
On the other hand looking at the smokeping plot above there is an obvious reduction in minimum RTT on or about November 10th. Prior to that date it is about 60ms, after that date it drops to about 35ms.