From last few days traffic on website(https://www.fanspole.com/) is too high, so we are trying to optimise website. One thing I notice was DNS resolve time is too high..
#MacBook-Air ~ $ ping fanspole.com
PING fanspole.com (139.162.35.126): 56 data bytes
64 bytes from 139.162.35.126: icmp_seq=0 ttl=56 time=717.688 ms
64 bytes from 139.162.35.126: icmp_seq=1 ttl=56 time=606.560 ms
64 bytes from 139.162.35.126: icmp_seq=2 ttl=56 time=654.942 ms
64 bytes from 139.162.35.126: icmp_seq=3 ttl=56 time=677.301 ms
64 bytes from 139.162.35.126: icmp_seq=4 ttl=56 time=699.991 ms
Request timeout for icmp_seq 5
64 bytes from 139.162.35.126: icmp_seq=6 ttl=56 time=601.355 ms
64 bytes from 139.162.35.126: icmp_seq=7 ttl=56 time=660.974 ms
64 bytes from 139.162.35.126: icmp_seq=8 ttl=56 time=605.084 ms
--- fanspole.com ping statistics ---
10 packets transmitted, 8 packets received, 20.0% packet loss
round-trip min/avg/max/stddev = 601.355/652.987/717.688/42.087 ms
we are using Linode DNS Manager as of now..
Can someone suggest better alternatives.
This is not a DNS resolution issue, its a network congestion issue.
traceroute to 139.162.35.126 (139.162.35.126), 30 hops max, 60 byte packets
<internal hops removed>
4 10gigabitethernet5-1.core1.lon1.he.net (5.57.80.128) 22.367 ms 22.618 ms 22.841 ms
5 10ge2-9.core1.lon2.he.net (72.52.92.222) 24.056 ms 24.277 ms 24.500 ms
6 100ge1-1.core1.nyc4.he.net (72.52.92.166) 94.769 ms 93.549 ms 93.694 ms
7 100ge14-2.core1.sjc2.he.net (184.105.81.213) 156.692 ms 147.815 ms 147.974 ms
8 * * *
9 * * *
10 xe0-2-0.gw1.sin2.pacnet.net (202.147.52.66) 320.731 ms 321.978 ms 321.950 ms
11 * * *
12 139.162.0.10 (139.162.0.10) 252.825 ms 251.826 ms 251.285 ms
13 li1448-126.members.linode.com (139.162.35.126) 251.746 ms 252.270 ms 251.406 ms
That is a traceroute from London UK - you can see on line 7 when it hits the he.net it starts to pick up latency. By the time it gets to line 10 in pacnet.net its 300+ms
The only option here is to move to a different Linode region or different hosting provider with better/less congested network links.
Related
Following a previous Stack Overflow response, (here) I am trying to check if a particular sentence/string is returned in the response of a io.popen command I’m running..
local function DevicePing(ip)
local handler = io.popen("ping -c 3 " ..ip.. " 2>&1")
local response = handler:read("*a")
print(response)
if string.find(response, "0% packet loss") then
print ("Pings were all successfull.")
else
print ("Pings were all unsuccessfull.")
end
end
DevicePing("192.168.1.180")
But every time I run it, it doesn’t find the requested string/sentence; see the print output below..
PING 192.168.1.180 (192.168.1.180): 56 data bytes
64 bytes from 192.168.1.180: seq=0 ttl=64 time=2.983 ms
64 bytes from 192.168.1.180: seq=1 ttl=64 time=1.620 ms
64 bytes from 192.168.1.180: seq=2 ttl=64 time=2.465 ms
--- 192.168.1.180 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.620/2.356/2.983 ms
Pings were all unsuccessfull.
What am I doing wrong for it not to see ‘0% packet loss‘ is present and say it was successfull?
% is the escape character in Lua patterns.
Use "0%% packet loss" to mean a literal %.
However, this pattern will also matches 100% packet loss. I suggest ", 0%% packet loss".
Also, it won't work in macOS which shows decimals in the report: 0.0% packet loss.
I am trying to solve the below question:
filter the UDP packets having a size equal to 242 bytes.
I looked to this answer udp.length==209 set a filter of packet length in wireshark, but instead of getting packets with length 209 bytes I get packets with length 243 bytes.
screenshot. can anyone explain?
Your image shows a packet like
Frame 243 bytes
'-> Ethernet
'-> IPv4
'-> UDP
'-> Dropbox LAN Sync
Ethernet will be 14 bytes with 6 per src/dst MAC address and 2 bytes for Ethertype.
The IPv4 header will be a minimum of 20 bytes, but could be more with options. It just so happens to be 20 here.
Eth 14 bytes + IP 20 bytes = 34 bytes
243 bytes - 34 bytes of Eth/IP = 209 bytes of UDP data
https://www.maxmind.com/en/geoip2-precision-demo shows 3 different countries for 5.62.61.176, 5.62.61.196 and 5.62.61.172. Is it possible?
It looks like Maxmind has incorrect results for 3 IP addresses. In this case, I performed network traceroute to determine the location of Avast servers.
You can see that 5.62.62.176 is located in UK. Meanwhile 5.62.61.196 and 5.62.61.172 are located in CZ.
Below are the traceroute reports and geolocation results from IP2Location.
Case 1) 5.62.62.176
Reference: https://www.locaping.com/result/pjsaQmv0
%>traceroute to 5.62.62.176 (5.62.62.176), 20 hops max, 60 byte packets
1 176.67.168.129 (176.67.168.129) 1.225 ms 1.263 ms 1.242 ms
2 te0-3-1-3.nr51.b022764-0.par05.atlas.cogentco.com (149.6.166.145) 0.643 ms 0.594 ms 0.868 ms
3 be3587.rcr21.par05.atlas.cogentco.com (154.25.5.125) 1.118 ms 1.050 ms 1.065 ms
4 be3625.ccr41.par01.atlas.cogentco.com (130.117.0.165) 1.482 ms be3626.ccr42.par01.atlas.cogentco.com (130.117.1.45) 1.327 ms be3625.ccr41.par01.atlas.cogentco.com (130.117.0.165) 1.379 ms
5 be12497.ccr41.lon13.atlas.cogentco.com (154.54.56.129) 8.949 ms be12489.ccr42.lon13.atlas.cogentco.com (154.54.57.69) 8.961 ms 8.977 ms
6 be2871.ccr21.lon01.atlas.cogentco.com (154.54.58.186) 9.121 ms 8.980 ms be2868.ccr21.lon01.atlas.cogentco.com (154.54.57.154) 8.873 ms
7 be2207.rcr21.b015589-1.lon01.atlas.cogentco.com (130.117.51.158) 9.084 ms 9.065 ms 9.351 ms
8 149.14.8.78 (149.14.8.78) 9.485 ms 9.734 ms 9.665 ms
9 border3.xe-1-1-0-bbnet2.lon003.pnap.net (212.118.240.116) 9.820 ms 8.881 ms border3.xe-0-1-0-bbnet1.lon003.pnap.net (212.118.240.52) 8.990 ms
10 avast-13.lon007.pnap.net (212.118.253.130) 14.051 ms 14.241 ms 14.433 ms
Case 2) 5.62.61.196
Reference: https://www.locaping.com/result/LRlnuyBU
%> traceroute 5.62.61.196 traceroute to 5.62.61.196 (5.62.61.196), 20 hops max, 60 byte packets 1 176.67.168.129 (176.67.168.129) 0.724 ms
0.679 ms 0.708 ms 2 te0-3-1-3.nr51.b022764-0.par05.atlas.cogentco.com (149.6.166.145) 0.555 ms 0.562 ms 0.877 ms 3 be3587.rcr21.par05.atlas.cogentco.com (154.25.5.125) 1.105 ms 1.078 ms
1.184 ms 4 be3625.ccr41.par01.atlas.cogentco.com (130.117.0.165) 1.380 ms be3626.ccr42.par01.atlas.cogentco.com (130.117.1.45) 1.341 ms be3625.ccr41.par01.atlas.cogentco.com (130.117.0.165) 1.280 ms 5 be3183.ccr31.par04.atlas.cogentco.com (154.54.38.66) 1.668 ms be3184.ccr31.par04.atlas.cogentco.com (154.54.38.158) 1.918 ms be3183.ccr31.par04.atlas.cogentco.com (154.54.38.66) 1.559 ms 6 * * * 7 * * * 8 * * * 9 AVAST-SOFTW.bear1.Prague1.Level3.net (212.162.11.86)
35.346 ms AVAST-SOFTW.bear1.Prague1.Level3.net (212.162.8.146) 35.510 ms AVAST-SOFTW.bear1.Prague1.Level3.net (212.162.11.82) 35.157 ms 10 *
* *
Case 3) 5.62.61.172
Reference: https://www.locaping.com/result/gPfLiKV8
%> traceroute 5.62.61.172 traceroute to 5.62.61.172 (5.62.61.172), 20 hops max, 60 byte packets 1 176.67.168.129 (176.67.168.129) 0.515 ms
0.525 ms 0.455 ms 2 te0-3-1-3.nr51.b022764-0.par05.atlas.cogentco.com (149.6.166.145) 0.738 ms 0.680 ms 0.626 ms 3 be3587.rcr21.par05.atlas.cogentco.com (154.25.5.125) 1.068 ms 1.026 ms
1.108 ms 4 be3625.ccr41.par01.atlas.cogentco.com (130.117.0.165) 1.033 ms 1.430 ms 1.364 ms 5 be3183.ccr31.par04.atlas.cogentco.com (154.54.38.66) 1.588 ms 1.987 ms 1.909 ms 6 * * * 7 * * * 8 * * * 9 AVAST-SOFTW.bear1.Prague1.Level3.net (212.162.11.86) 35.133 ms AVAST-SOFTW.bear1.Prague1.Level3.net (212.162.8.146) 35.527 ms AVAST-SOFTW.bear1.Prague1.Level3.net (212.162.11.86) 35.069 ms 10 * *
*
I have been having occasional lag spikes while playing online realtime games (LoL for example). I ran a tracert to LoL's servers (216.52.241.254):
C:\Windows\system32>tracert -d 216.52.241.254
Tracing route to 216.52.241.254 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.0.1
2 29 ms 29 ms 26 ms 68.84.4.1
3 10 ms 8 ms 10 ms 68.85.80.165
4 9 ms 11 ms 70 ms 68.85.130.85
5 14 ms 15 ms 15 ms 68.86.90.85
6 12 ms 12 ms 11 ms 68.86.82.222
7 13 ms 13 ms 12 ms 66.208.229.142
8 48 ms 13 ms 13 ms 154.54.6.170
9 26 ms 25 ms 26 ms 154.54.31.97
10 44 ms 45 ms 46 ms 154.54.29.222
11 75 ms 74 ms 73 ms 154.54.7.158
12 76 ms 75 ms 75 ms 154.54.47.170
13 76 ms 76 ms 75 ms 154.24.22.122
14 77 ms 74 ms 74 ms 38.104.77.122
15 74 ms 74 ms 75 ms 216.52.241.254
Trace complete.
and did a ping -t to the first few nodes to see if the problem showed up there. I let that run while I was playing, and checked on it whenever I had a lag spike or disconnect. The results for the first two nodes:
Localhost:
C:\Windows\system32>ping -t 192.168.0.1
Pinging 192.168.0.1 with 32 bytes of data:
...omitted...
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Ping statistics for 192.168.0.1:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
Control-C
^C
Second node:
C:\Windows\system32>ping -t 68.84.4.1
Pinging 68.84.4.1 with 32 bytes of data:
...omitted...
Reply from 68.84.4.1: bytes=32 time=8ms TTL=254
Reply from 68.84.4.1: bytes=32 time=14ms TTL=254
Reply from 68.84.4.1: bytes=32 time=12ms TTL=254
Reply from 68.84.4.1: bytes=32 time=10ms TTL=254
Reply from 68.84.4.1: bytes=32 time=15ms TTL=254
Reply from 68.84.4.1: bytes=32 time=10ms TTL=254
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 68.84.4.1: bytes=32 time=11ms TTL=254
Reply from 68.84.4.1: bytes=32 time=11ms TTL=254
Reply from 68.84.4.1: bytes=32 time=10ms TTL=254
Reply from 68.84.4.1: bytes=32 time=8ms TTL=254
Reply from 68.84.4.1: bytes=32 time=10ms TTL=254
Reply from 68.84.4.1: bytes=32 time=9ms TTL=254
Reply from 68.84.4.1: bytes=32 time=14ms TTL=254
Reply from 68.84.4.1: bytes=32 time=10ms TTL=254
Reply from 68.84.4.1: bytes=32 time=15ms TTL=254
Request timed out.
Ping statistics for 68.84.4.1:
Packets: Sent = 2911, Received = 2889, Lost = 22 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 2953ms, Average = 12ms
Control-C
^C
Each line of the results should roughly match the corresponding line in the other in terms of time of ping. Sometimes, I have multiple timeouts like above, while other times, it is only one or two lines with very high latency (>900ms). I also had results for a few more nodes, but those had the same behavior, so I figured the problem was in the second node.
I recently got a new router because Comcast cut off our internet, saying, "You have to upgrade your router. It's outdated and you're not taking advantage of the speedups we've been implementing in your area." I cannot recall if we had this lag spike problem before we got the new router because I spent most of my time at school.
My question is: Is this a problem with my router or with the house's connection to the rest of the internet?
EDIT:
The problem seems to arise only when I am playing. I have been running a ping -t to 68.84.4.1 for the last hour while not playing, and have not seen it timeout a single time. The results are:
Ping statistics for 68.84.4.1:
Packets: Sent = 3477, Received = 3476, Lost = 1 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 88ms, Average = 10ms
Over the entire hour, the max latency was 88ms, and only 1 packet was lost.
There can be a number of reasons that cause games to lag on a machine besides the internet connection.
Assuming that the problem lies in your connection
The first point is most relevant to your question, rest are just suggestions
Perform a "full" Speedtest: the data you provided only tells half of the story, do a proper speed test using some online service like Speedtest.net by Ookla. Network games have high bandwidth requirements so take a note of the (total) bandwidth that comes to your home. If no other devices and/or program is consuming your network bandwith, you shall have a similar value. you may also do a DNS speed test using Namebench
Use a Wired Connection: A wireless connection will always add latency to bandwidth. Disconnect from the router and use a wired connection directly to the computer. Also, if others are using the router at the same time, it is possible that there are too many people grabbing for the same bandwidth.
However if that is not possible make sure that the router is properly configured. It must be in the right position, at the right elevation, wireless channel etc for optimal performance.
There are number of guides available online which you can follow.
Also look out for any new wireless networks in your area that may interfere with your signal.
Try a different router firmware, as some routers have broken firmware and don't perform well on excess load , give Gargoyle or OpenWRT a chance if you are desperate.
Close down other applications that use the internet
Optimize your game settings: All popular online games have network settings, its just a case of finding them. Search online for a guide to tweaking your game.
Turn on Compound TCP, which increases the TCP window much quicker than the traditional TCP algorithms allow for. This means that when a sudden burst of larger packets comes in, or goes out, Windows adjusts its settings faster than normal to compensate for it, allow for faster data transfer on broadband connections and lower latency while gaming.
netsh int tcp set global congestionprovider=ctcp
Enable UPnP on your router: This will automatically route the correct data to the correct ports.
Experiment at different days and time for lags
Try a Speed optimizer like SG TCP Optimizer
Lastly make sure that you have the latest Drivers installed and are
using compatible hardware.
I'm working on a multiplayer game. The principle is simple, each of the two players sends each other periodically 512 bytes every 50 milliseconds.
The problem is that about every 20-30 seconds players stop receiving data for sometimes one but sometimes even up to 20 seconds (though, sending had not been interrupted).
At first I thought that this is caused by a slow network connection on either my side or on the side of my remote PC which I use for debugging.
But then I noticed that all network traffic on my side slows down at the same times when the game stops receiving data.
So I started ping <my-local-router> and this is what it shows me:
When the game isn't running:
...
64 bytes from 192.168.1.1: icmp_req=4520 ttl=64 time=4.89 ms
64 bytes from 192.168.1.1: icmp_req=4521 ttl=64 time=7.96 ms
64 bytes from 192.168.1.1: icmp_req=4522 ttl=64 time=10.5 ms
64 bytes from 192.168.1.1: icmp_req=4523 ttl=64 time=7.21 ms
64 bytes from 192.168.1.1: icmp_req=4524 ttl=64 time=8.10 ms
64 bytes from 192.168.1.1: icmp_req=4525 ttl=64 time=3.37 ms
64 bytes from 192.168.1.1: icmp_req=4526 ttl=64 time=5.12 ms
64 bytes from 192.168.1.1: icmp_req=4527 ttl=64 time=3.29 ms
...
When the game is running:
...
64 bytes from 192.168.1.1: icmp_req=47 ttl=64 time=6.99 ms
64 bytes from 192.168.1.1: icmp_req=48 ttl=64 time=1.69 ms
64 bytes from 192.168.1.1: icmp_req=49 ttl=64 time=2.60 ms
64 bytes from 192.168.1.1: icmp_req=50 ttl=64 time=2.88 ms
64 bytes from 192.168.1.1: icmp_req=52 ttl=64 time=9210 ms
64 bytes from 192.168.1.1: icmp_req=53 ttl=64 time=17144 ms
64 bytes from 192.168.1.1: icmp_req=54 ttl=64 time=16214 ms
64 bytes from 192.168.1.1: icmp_req=55 ttl=64 time=15372 ms
64 bytes from 192.168.1.1: icmp_req=56 ttl=64 time=14482 ms
64 bytes from 192.168.1.1: icmp_req=57 ttl=64 time=13486 ms
64 bytes from 192.168.1.1: icmp_req=58 ttl=64 time=12511 ms
64 bytes from 192.168.1.1: icmp_req=59 ttl=64 time=11546 ms
64 bytes from 192.168.1.1: icmp_req=60 ttl=64 time=10591 ms
64 bytes from 192.168.1.1: icmp_req=61 ttl=64 time=9626 ms
64 bytes from 192.168.1.1: icmp_req=62 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_req=63 ttl=64 time=3.33 ms
...
It seems that the game is causing the router to become unresponsive.
I don't have any P2P running on my local PC, but that doesn't even sound relevant since I don't experience the slowback when the game isn't running.
I'm new to UDP programming and I'm getting clueless with this, especially since the 512 bytes every 50ms seems like quite a small bandwidth to me (when I do run P2P, it easily runs 1.5MB/s).
This might have been my router dying and needing a replacement or something fishy in my wireless drivers, as I've noticed more network freezes lately even at times when the application wasn't running.