EC2 - Micro Instance - Very slow network response

Question

One of my instances is having some unusual issues. Pinging any site is extremely slow. Trying to keep the SSH connection is quite crappy too.

The following is a ping to yahoo. Any idea what could be causing this?

PING yahoo.com (98.139.183.24) 56(84) bytes of data. 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=1 ttl=46 time=1523 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=2 ttl=47 time=1494 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=3 ttl=47 time=1526 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=4 ttl=47 time=27.1 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=5 ttl=46 time=1499 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=6 ttl=46 time=1496 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=7 ttl=47 time=18.4 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=8 ttl=46 time=1496 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=9 ttl=47 time=27.8 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=10 ttl=46 time=986 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=11 ttl=46 time=496 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=12 ttl=47 time=18.4 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=13 ttl=46 time=1501 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=14 ttl=46 time=1016 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=15 ttl=47 time=28.0 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=16 ttl=47 time=17.8 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=17 ttl=47 time=1500 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=18 ttl=46 time=1526 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=19 ttl=46 time=1530 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=20 ttl=47 time=1497 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=21 ttl=47 time=18.4 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=22 ttl=46 time=990 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=23 ttl=47 time=24.3 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=24 ttl=47 time=1002 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=25 ttl=47 time=990 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=26 ttl=46 time=1520 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=27 ttl=47 time=1499 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=28 ttl=46 time=1495 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=29 ttl=46 time=1532 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=30 ttl=46 time=1016 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=31 ttl=47 time=17.9 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=32 ttl=46 time=1527 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=33 ttl=46 time=1019 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=34 ttl=47 time=988 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=35 ttl=46 time=1519 ms 64 bytes from ir2.fp.vip.bf1.yahoo.com (98.139.183.24): icmp_seq=36 ttl=46 time=1496 ms ^C --- yahoo.com ping statistics --- 37 packets transmitted, 36 received, 2% packet loss, time 48854ms rtt min/avg/max/mdev = 17.839/996.928/1532.515/613.551 ms

Answer 1

My impression with EC2 micro instance is not necessarily networking is the problem but CPU cycles itself. I guess with micro instance, you are receiving left-over CPU cycles from other instances on a virtual machine. So, although over time, you receive a guaranteed average number of CPU cycles, in short run, you have burst of them instead of having constant CPU power. So, my guess is that when you have CPU cycles to respond a ping, it might be already too late. So, network travel time is not the issue but overall respond time is. Whatever I say here is my guess and may not reflect what is really going on.