[lugm.org] My adventures with the Mauritius Internet Exchange Point

Fri Oct 23 18:42:57 UTC 2015

MTR [WinMTR on Windows] might be your friend, to indicate where in the
network the packet loss is happening.
Appreciate if you could paste MTR results from both directions and also at
different times of the day [peak v/s less busy hours]. Very curious to know.

#mtr 154.71.9.70 --report -c 50

As you can see below, no packets loss through IP Transit though:-

----------- From US:-
rviews at route-server.ip.att.net> ping 154.71.9.70 count 10
PING 154.71.9.70 (154.71.9.70): 56 data bytes
64 bytes from 154.71.9.70: icmp_seq=0 ttl=46 time=311.445 ms
64 bytes from 154.71.9.70: icmp_seq=1 ttl=46 time=310.264 ms
64 bytes from 154.71.9.70: icmp_seq=2 ttl=46 time=309.209 ms
64 bytes from 154.71.9.70: icmp_seq=3 ttl=46 time=315.209 ms
64 bytes from 154.71.9.70: icmp_seq=4 ttl=46 time=315.049 ms
64 bytes from 154.71.9.70: icmp_seq=5 ttl=46 time=316.097 ms
64 bytes from 154.71.9.70: icmp_seq=6 ttl=46 time=313.581 ms
64 bytes from 154.71.9.70: icmp_seq=7 ttl=46 time=309.875 ms
64 bytes from 154.71.9.70: icmp_seq=8 ttl=46 time=310.774 ms
64 bytes from 154.71.9.70: icmp_seq=9 ttl=46 time=321.320 ms

--- 154.71.9.70 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 309.209/313.282/321.320/3.556 ms

rviews at route-server.ip.att.net> ping 41.136.241.246 count 10
PING 41.136.241.246 (41.136.241.246): 56 data bytes
64 bytes from 41.136.241.246: icmp_seq=0 ttl=55 time=290.118 ms
64 bytes from 41.136.241.246: icmp_seq=1 ttl=55 time=281.909 ms
64 bytes from 41.136.241.246: icmp_seq=2 ttl=55 time=282.080 ms
64 bytes from 41.136.241.246: icmp_seq=3 ttl=55 time=282.280 ms
64 bytes from 41.136.241.246: icmp_seq=4 ttl=55 time=282.297 ms
64 bytes from 41.136.241.246: icmp_seq=5 ttl=55 time=283.976 ms
64 bytes from 41.136.241.246: icmp_seq=6 ttl=55 time=282.085 ms
64 bytes from 41.136.241.246: icmp_seq=7 ttl=55 time=282.175 ms
64 bytes from 41.136.241.246: icmp_seq=8 ttl=55 time=282.140 ms
64 bytes from 41.136.241.246: icmp_seq=9 ttl=55 time=282.213 ms

--- 41.136.241.246 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 281.909/283.127/290.118/2.395 ms

------------------ From UK:
# ping 154.71.9.70 -i 0.02 -c 10
PING 154.71.9.70 (154.71.9.70) 56(84) bytes of data.
64 bytes from 154.71.9.70: icmp_seq=1 ttl=48 time=268 ms
64 bytes from 154.71.9.70: icmp_seq=2 ttl=48 time=259 ms
64 bytes from 154.71.9.70: icmp_seq=3 ttl=48 time=260 ms
64 bytes from 154.71.9.70: icmp_seq=4 ttl=48 time=257 ms
64 bytes from 154.71.9.70: icmp_seq=5 ttl=48 time=260 ms
64 bytes from 154.71.9.70: icmp_seq=6 ttl=48 time=257 ms
64 bytes from 154.71.9.70: icmp_seq=7 ttl=48 time=261 ms
64 bytes from 154.71.9.70: icmp_seq=8 ttl=48 time=268 ms
64 bytes from 154.71.9.70: icmp_seq=9 ttl=48 time=260 ms
64 bytes from 154.71.9.70: icmp_seq=10 ttl=48 time=262 ms

--- 154.71.9.70 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 251ms
rtt min/avg/max/mdev = 257.369/261.750/268.976/3.921 ms

~# ping 41.136.241.246 -c 10
PING 41.136.241.246 (41.136.241.246) 56(84) bytes of data.
64 bytes from 41.136.241.246: icmp_seq=1 ttl=53 time=269 ms
64 bytes from 41.136.241.246: icmp_seq=2 ttl=53 time=262 ms
64 bytes from 41.136.241.246: icmp_seq=3 ttl=53 time=264 ms
64 bytes from 41.136.241.246: icmp_seq=4 ttl=53 time=263 ms
64 bytes from 41.136.241.246: icmp_seq=5 ttl=53 time=269 ms
64 bytes from 41.136.241.246: icmp_seq=6 ttl=53 time=268 ms
64 bytes from 41.136.241.246: icmp_seq=7 ttl=53 time=263 ms
64 bytes from 41.136.241.246: icmp_seq=8 ttl=53 time=263 ms
64 bytes from 41.136.241.246: icmp_seq=9 ttl=53 time=263 ms
64 bytes from 41.136.241.246: icmp_seq=10 ttl=53 time=262 ms

--- 41.136.241.246 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 251ms
rtt min/avg/max/mdev = 262.782/265.102/269.511/2.714 ms

>From above, also note difference in latency for Emtel/MT from UK v/s US.
>From US latency to Emtel is ~25ms greater than MT, however from UK they are
very close to each other.

>From traceroutes/mtrs, I could see both Emtel/MT with Internet breakouts in
London, although they could have diverse routing/transmission paths, load
sharing over different Transit providers. As mentioned in one of my
previous emails, latency is subject to many factors.

It could be down to transmission paths [as illustrated above: US latency
for Emtel v/s MT] which also applies locally inland as well, should there
be any issues in local backhaul such as fibre cuts etc. E.g during fibre
cuts in the inland backhaul, the backup transmission medium could be
Microwave, copper or even satellite links, latency would definitely take a
hit.

That's probably one of the reason ISPs would be reluctant on guaranteeing
latency, especially over the Internet where beyond some point they have no
control.  With Internet, once your traffic is on the Internet backbone, its
a best effort service.

Cheers,
Ashvin

Ashvin

On Fri, Oct 23, 2015 at 6:00 PM, Loganaden Velvindron <gnukid1 at yahoo.co.uk>
wrote:

> I decided to ask an Emtel Airbox customer to do some latency measurements,
> and here are our results:
>
> http://logan.hackers.mu/2015/10/emtel-lossy
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://discuss.lugm.org/pipermail/discuss_discuss.lugm.org/attachments/20151023/c3d14180/attachment-0001.html>