Traceroute, pinging, the internet, and you

nrglg · July 2015

Edit/Note: For some reason the "size" bbcode tag has been disabled and because it's disabled, it's for some reason ruining the color of text as well. I apologize for my guide not looking as nicely formatted as it was before PWE played around with things they probably shouldn't have touched.

In SylenThunder's main troubleshooting issues overview thread it doesn't go very deep into how to actually test and determine where a networking problem lies. So I've decided to teach you. Hopefully I can explain in a clear enough manner that you will understand. I will probably add an update because I'm sure I missed some chunk of information considering I wrote this at 3AM.

Before I get started, make you you know what ISP means.

ISP: Internet Service Provider. The company or government service that provides you your internet connection. Examples of large, well known, ISPs are Cox, Time-Warner, AT&T, Verizon, Charter, and Comcast.

Routers and Modems

I'm sure you've heard the term router and modem. I bet more than half of you can't distinguish between the two or think they are synonyms for one another. However, they are in fact two separate devices with two distinct purposes. Although I will say that there are many combo devices now that don't help understanding that there is a difference.

Routers: Routers are devices that know how to handle data. You can think of them as the GPS guiding system for your data. Data sent anywhere is going to have to be handled by a router at some point so that it is sent to the correct destination. For instance, you want to send a picture you have to another computer on you home network. The only way the data will be sent to the correct destination is when the router gets ahold of it and looks at who you are trying to send it to. If the device you're trying to send it to exists, the router will proceed to forward the data to that device.

Modems: Modems are a way to change the digital data coming from your device into easily transmittable analog signals that can also be reassembled back into digital data once arriving at another modem. Digital signals can't travel very far, which is why they are converted. To put simply, they blindly transmit data to and from long distances, such as from your house to your ISP and vice-versa. I could go into depth how modems work, but it's boring in comparison to everything else.

LAN and WAN

Have you ever heard the term LAN? Local area network; this is a term given to a series of devices, phones, computers, tablets, routers, switches all connected in a local networking ecosystem. That is to say, these devices, if setup properly, can communicate with one another because they are all locally connected on a network.

A typical household LAN setup will look something like this

The devices will all be connected into a router that handles the direction of the data. Data that is not being handled locally is sent through the modem and received by your ISP who will handle getting it out to its destination from there.

A term you're probably not familiar with is WAN. Funny enough, your ability to view this right now is taking place because of the largest WAN on earth, the Internet. Wide area network; is a somewhat loosely defined term that describes large networks all connected together. Such as many other smaller WANs and LANs linked by many nodes. You can think of the internet as a very large version of your LAN.

The Internet

So now that you know that the internet is a WAN; let's talk about how everything is connected. Starting off from the other picture, your ISP has an internal LAN/WAN, called a backbone. Your ISPs backbone is connected to the Internet's backbone which is comprised of many other ISPs, universities, and governments all doing the same. For the sake of simplicity, I will just call the devices we meet along the way nodes.

When attempting to reach any website, or online video game, you must go through this series of devices that are all connected to one another. Even one device having issues could cause you problems. Take this simplistic example above. Imagine if "Node" is failing for an unspecified reason. We don't know why, all we know is that it's failing. Aside from causing your ISP connection issues, it would also cause issues for the other ISP who is connected through the same path.

Many times this is actually a realistic example of what happens when a node is important for connecting two countries together. When it fails the countries could lose some access to one another. There are other pathways, but it's unlikely the ISPs devices will figure out another route. The reason is because they typically look for the shortest path, even if the path is failing.

nrglg · July 2015

Protocols, ICMP, Trace Route, and Pinging

Protocols are a set of rules and standards used to allow all kinds of different devices to communicate. Think of protocols as the English language. It's taught almost worldwide so that everyone around the world can communicate. Protocols are the languages our devices use to speak to one another. There are several layers of protocols. If you wish to learn more about them, look them up.

ICMP; Internet Control Message Protocol is one of many ways to transmit data over the internet. However, it is mainly used for diagnosing issues between you and another place. Trace route and ping both use ICMP to transmit data.

Ping: Pinging is the act of sending a small tidbit of, usually empty, data through ICMP to a destination. The destination can be your router or even Japan. When the data arrives at the destination, if it accepts ICMP pings, it will respond by sending a reply back.

A real example caught with Wireshark can be seen here

Pinging is useful because when it times out it can tell you that a device somewhere along the way is having issues. What is timing out? When you send a ping you can specify how much time it has to respond to you before you quit waiting for it to reply. Devices taking more than 3 seconds is typically too long. So it will give a clue as to what device or devices are having issues because their response time is so long that your system quit waiting.

Trace route: Trace route is a series of pings forcing their TTL to expire, which will give back each device connected along the path to your destination. TTL is Time-to-Live. It describes the max number of hops (movements) the data is allowed to make between connected devices to (as well as from) your destination. However, when you limit it you can get all of the devices that stand between you and your destination. This is called route tracing. When the TTL of your data expires, it means it can go no further and cannot reach the destination. When this occurs, the last device to have your data will send back data saying that the data you sent expired because TTL reached 0.

I will explain how to use ping and trace route in the next section. Just know that whatever is after -i is the TTL. I can do a manual trace route to PW's HT server with ping as such.

C:\Users\Example>ping -i 1 -w 1000 -l 32 -n 1 pwigc4.perfectworld.com

Pinging pwigc4.perfectworld.com [66.151.133.70] with 32 bytes of data:
Reply from 192.168.1.1: TTL expired in transit.

Ping statistics for 66.151.133.70:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

C:\Users\Example>ping -i 2 -w 1000 -l 32 -n 1 pwigc4.perfectworld.com

Pinging pwigc4.perfectworld.com [66.151.133.70] with 32 bytes of data:
Reply from 10.72.80.1: TTL expired in transit.

Ping statistics for 66.151.133.70:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

C:\Users\Example>ping -i 3 -w 1000 -l 32 -n 1 pwigc4.perfectworld.com

Pinging pwigc4.perfectworld.com [66.151.133.70] with 32 bytes of data:
Reply from 72.31.201.216: TTL expired in transit.

Ping statistics for 66.151.133.70:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

C:\Users\Example>ping -i 4 -w 1000 -l 32 -n 1 pwigc4.perfectworld.com

Pinging pwigc4.perfectworld.com [66.151.133.70] with 32 bytes of data:
Reply from 72.31.200.254: TTL expired in transit.

Ping statistics for 66.151.133.70:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

From this you can see what devices it goes through by forcing the devices between us and PW to respond prematurely.
192.168.1.1 -> 10.72.80.1 -> 72.31.201.216 -> 72.31.200.254

This is what trace route does and why it's so great for getting a hint as to what the problem may be. Any pings that timeout will come in the form of asterisks ( * ).

C:\Users\Example>tracert -w 1000 -d pwigc4.perfectworld.com

Tracing route to pwigc4.perfectworld.com [66.151.133.70]
over a maximum of 30 hops:

  1     2 ms     1 ms    <1 ms  192.168.1.1
  2     9 ms     9 ms    12 ms  10.72.80.1
  3    10 ms     8 ms    12 ms  72.31.201.216
  4    11 ms    10 ms    13 ms  72.31.200.254
  5    10 ms    11 ms    11 ms  72.31.200.181
  6    17 ms    20 ms    18 ms  107.14.16.236
  7    18 ms    17 ms    46 ms  107.14.19.56
  8    16 ms    16 ms    17 ms  62.115.36.57
  9    29 ms    29 ms    29 ms  213.155.135.189
 10    32 ms    29 ms    29 ms  213.248.81.134
 11    43 ms    33 ms    33 ms  66.151.144.20
 12    35 ms    30 ms    31 ms  64.95.143.190
 13    31 ms    31 ms    31 ms  66.151.133.70

Trace complete.

An interesting tidbit not usually talked about is that many systems are designed to ignore pings. However, when a ping TTL expires, they will respond telling us that it expired. You can use this method of pinging to force uncooperative devices into telling us their condition. For instance, 72.31.201.216 is part of my ISPs backbone. It didn't want to play nice and tried to convince me it wasn't working right. However, I knew better and got it to reply back.

C:\Users\Example>ping 72.31.201.216

Pinging 72.31.201.216 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 72.31.201.216:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Example>ping -i 3 66.151.133.70

Pinging 66.151.133.70 with 32 bytes of data:
Reply from 72.31.201.216: TTL expired in transit.
Reply from 72.31.201.216: TTL expired in transit.
Reply from 72.31.201.216: TTL expired in transit.
Reply from 72.31.201.216: TTL expired in transit.

Ping statistics for 66.151.133.70:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

nrglg · July 2015

How to Trace Route and Ping Manually

Trace Route

http://forum.arcgames.com/pwi/discussion/comment/2722052#Comment_2722052

darthpanda16 wrote:

) In XP, click on Start > click on Run > type in "cmd"
2) On this screen type in (exactly as it is typed here): tracert pwieast1.perfectworld.com (You can use any of the IP addresses to our servers listed below. Try several.)
Please note there is a space between "tracert" and "pwieast1.perfectworld.com"
3) Wait for the traceroute to complete.
4) Right Click on the window
5) Select the "Select all" option
6) Hit "Enter"
7) You will now be able to paste the text into your reply.

1) In Vista/7, click on the Windows icon/Start > click on Search > type in "cmd"
2) On this screen type in (exactly as it is typed here): tracert pwieast2.perfectworld.com (You can also use any of the IP addresses to our servers listed below. Try several.)
Please note there is a space between "tracert" and "pwieast2.perfectworld.com"
3) Wait for the traceroute to complete.
4) Right Click on the window
5) Select the "Select all" option
6) Hit "Enter"
7) You will now be able to paste the text into your reply.

I can't really explain it any better than darthpanda16 did.

Mayfly has provided instructions for Windows 8/8.1 users.

Mayfly - Dreamweaver wrote: »

Move mouse pointer to upper or lower right corners, until a menu appears on the right side. The top choice is "Search", type "cmd" into the edit box, then proceed as for earlier versions of Windows.

Pinging

Follow the same instructions as trace route to open up the command prompt. From here type in "ping pwieast2.perfectworld.com" or any of the addresses provided here...
Twilight Temple = pwigc2.perfectworld.com
Etherblade = pwiwest4.perfectworld.com
Tideswell = pwieast2.perfectworld.com
Dawn Glory = pwieu3.en.perfectworld.eu

You can mimic what I was doing above by using parameters for the command. Parameters are just ways to specify how you want ping to ping things.

ping -i 1 pwigc4.perfectworld.com

-i is the TTL for the ping. You can force back replies from any of the devices along the path with this. If replies fail, that is called packet loss.

ping -n 2 pwigc4.perfectworld.com

-n is the number of times you want to ping a destination. When set to -1 it will ping forever until you click Ctrl+C, which is cancel.

You can combine these parameters together by separating by spaces.

ping -i 3 -n 2 pwigc4.perfectworld.com

This will ping the 3rd device on the route 2 times before stopping.

You can find all of the paramters by typing "ping /?"

C:\Users\Administrator>ping /?

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
            [-r count] [-s count] [[-j host-list] | [-k host-list]]
            [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name

Options:
    -t             Ping the specified host until stopped.
                   To see statistics and continue - type Control-Break;
                   To stop - type Control-C.
    -a             Resolve addresses to hostnames.
    -n count       Number of echo requests to send.
    -l size        Send buffer size.
    -f             Set Don't Fragment flag in packet (IPv4-only).
    -i TTL         Time To Live.
    -v TOS         Type Of Service (IPv4-only. This setting has been deprecated
                   and has no effect on the type of service field in the IP Header).
    -r count       Record route for count hops (IPv4-only).
    -s count       Timestamp for count hops (IPv4-only).
    -j host-list   Loose source route along host-list (IPv4-only).
    -k host-list   Strict source route along host-list (IPv4-only).
    -w timeout     Timeout in milliseconds to wait for each reply.
    -R             Use routing header to test reverse route also (IPv6-only).
    -S srcaddr     Source address to use.
    -4             Force using IPv4.
    -6             Force using IPv6.

How to Trace Route and Ping with Tools

PingPlotter

I don't know how many tools are out there doing this, but PingPlotter is a well known tool for diagnosing network issues using ping and trace route.

To use, put an IP address or domain name in the "Address To Trace" text box and press enter. This will automatically start a trace.

If you ever see packet loss, that means that the devices failed to respond in time before your device quit caring. When packet loss occurs, it can been seen visually and in the "PL%" column.

Pingy

Pingy is the program I wrote to basically be a completely free version of PingPlotter. I'm not done making it yet. I'm not even in an alpha or beta stage yet. Although the source is open to the public now. However, since I will be releasing compiled binaries soon enough I figured I should give instructions anyways.

To use, put an IP address or domain name in the "Address to Trace" text box and press enter. To start pinging an address, simply click on the input address. Pingy will add an asterisk by the address you're tracing. You can click on as many addresses as you want. Pingy supports monitoring multiple addresses.

nrglg · July 2015

Determining a Cause

Packets: Packets are the data I keep talking about. Packets are used to communicate between devices. Packets are just data with many settings and meta information in them. When you use ping on Windows, by default it sends 32 bytes of data to the destination. However, the packet size is larger than that because of all of the settings and meta info for that packet. Without those, devices wouldn't know how to handle them.

Actual Packet Sent from Pingy

Transit: Transit is the process by which packets are moved between devices over the internet.This is how data is moved from one location to another. When a packet doesn't reach its destination or, for instance, a ping TTL expires, this data is considered lost in transit. A large amount of data is lost in transit daily due to various random circumstances.

Node: Nodes are devices that are connected to one another that allow for transit to occur. Each device along the route to your destination would be considered a node.

Packet Loss: Packet loss occurs when packets in transit do not reach their destination or their destination is unable to respond to the packet in time. This can be caused by random nodes failing to acknowledge a TCP handshake or by those nodes failing to respond to your ICMP ping in time.

Now that I've, hopefully, defined what packet loss actually is; we can move on to solving where a problem lies. So, first, how to locate a problem. In my example I will be using IP 216.92.150.222 because 2 nodes have been on the fritz at the time of writing this. So it's a perfect example. In your case, you will need to use one of the Perfect World server's addresses. Use the server you play on. http://perfectworld.vanillaforums.com/discussion/comment/6675783#Comment_6675783

C:\Users\Example>tracert -d -w 1000 216.92.150.222

Tracing route to 216.92.150.222 over a maximum of 30 hops

  1     1 ms     1 ms     1 ms  192.168.1.1
  2    10 ms    10 ms     9 ms  10.72.80.1
  3    10 ms     9 ms    14 ms  72.31.201.218
  4    11 ms    11 ms    11 ms  72.31.200.146
  5    12 ms    12 ms    11 ms  72.31.200.180
  6    17 ms    19 ms    21 ms  107.14.16.234
  7    18 ms    17 ms    17 ms  66.109.6.135
  8    17 ms    17 ms    23 ms  66.109.9.122
  9     *        *        *     Request timed out.
 10   157 ms   119 ms   108 ms  4.69.135.241
 11    91 ms    91 ms    89 ms  4.34.30.22
 12     *        *        *     Request timed out.
 13   102 ms   101 ms   101 ms  216.92.150.222

Trace complete.

So, from this you can see hop 9 and hop 12 failed to return data in time. This means that some random nodes are failing along the way. This was easy to spot a problem, because they completely failed. If hop 1 had failed, this would mean that your router was having problems. From this you can safely assume that it is not your fault, but that you also cannot do anything about the problem.

Recently, there was a thread where someone had more typical issues that you would see when doing this stuff.

C:\Users\Example>tracert pwiwest4.perfectworld.com

Tracing route to pwiwest4.perfectworld.com [66.151.133.73]
over a maximum of 30 hops:

  1     3 ms     5 ms     3 ms  192.168.0.1
  2    18 ms    17 ms    25 ms  host-78-145-240-1.as13285.net [78.145.240.1]
  3    17 ms    19 ms    18 ms  host-78-151-230-145.as13285.net [78.151.230.145]
  4    18 ms    19 ms    19 ms  host-78-151-230-146.as13285.net [78.151.230.146]
  5    39 ms    26 ms    29 ms  host-78-144-0-69.as13285.net [78.144.0.69]
  6    23 ms    24 ms    34 ms  host-78-144-11-34.as13285.net [78.144.11.34]
  7    24 ms    27 ms    82 ms  xe-10-1-0.lon21.ip4.tinet.net [213.200.78.233]
  8   259 ms   233 ms     *     xe-1-1-6.sjc10.ip4.gtt.net [89.149.186.206]
  9   208 ms     *        *     internap-gw.ip4.gtt.net [77.67.70.26]
 10   204 ms   207 ms   206 ms  border2.t8-1-bbnet2.sje004.pnap.net [66.151.144.80]
 11   209 ms   198 ms   197 ms  perfectworld-10.border2.sje004.pnap.net [64.95.143.190]
 12   207 ms   167 ms   166 ms  66.151.133.73

Trace complete.

Hop 8 and 9 failed. I proceeded to have them ping hop 7 and 8 (no TTL expire trick needed), because between 7 and 8 there was a large gap in latency. It turned out like this.

C:\Users\Example>ping 213.200.78.233 -n -1

Pinging 213.200.78.233 with 32 bytes of data:
Reply from 213.200.78.233: bytes=32 time=34ms TTL=55
Reply from 213.200.78.233: bytes=32 time=25ms TTL=55
Reply from 213.200.78.233: bytes=32 time=23ms TTL=55
Reply from 213.200.78.233: bytes=32 time=26ms TTL=55
Reply from 213.200.78.233: bytes=32 time=26ms TTL=55
Reply from 213.200.78.233: bytes=32 time=25ms TTL=55
Reply from 213.200.78.233: bytes=32 time=24ms TTL=55
Reply from 213.200.78.233: bytes=32 time=25ms TTL=55
Reply from 213.200.78.233: bytes=32 time=25ms TTL=55

Ping statistics for 213.200.78.233:
    Packets: Sent = 9, Received = 9, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 23ms, Maximum = 34ms, Average = 25ms

Hop 7 had 0 packet loss and responded at an average rate of 25 milliseconds.

C:\Users\Example>ping 89.149.186.206 -n -1

Pinging 89.149.186.206 with 32 bytes of data:
Request timed out.
Reply from 89.149.186.206: bytes=32 time=216ms TTL=51
Reply from 89.149.186.206: bytes=32 time=216ms TTL=51
Reply from 89.149.186.206: bytes=32 time=215ms TTL=51
Reply from 89.149.186.206: bytes=32 time=215ms TTL=51
Reply from 89.149.186.206: bytes=32 time=230ms TTL=51
Request timed out.
Reply from 89.149.186.206: bytes=32 time=198ms TTL=51
Reply from 89.149.186.206: bytes=32 time=198ms TTL=51
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 89.149.186.206:
    Packets: Sent = 12, Received = 7, Lost = 5 (41% loss),
Approximate round trip times in milli-seconds:
    Minimum = 198ms, Maximum = 230ms, Average = 212ms

Hop 8 as you can see had 41% packet loss and an average of 212 milliseconds response time. From this you can gather that hop 8 is definately causing problems at the moment, although hop 9 is just as guilty. I didn't have them ping hop 9, but I imagine its packet loss was slightly higher from the first trace route performed.

False Positives

Sometimes you will get results and think you found the cause. This is where things can get a bit tricky. Sometimes nodes will not respond to ICMP packets at all. This will result in it looking as if the node is faulty. As long as the next or next few nodes afterwards respond to ICMP packets, you can determine whether or not that node is having issues.

C:\Users\Administrator>tracert pwieast3.perfectworld.com

Tracing route to pwieast3.perfectworld.com [198.49.243.17]
over a maximum of 30 hops:

  1     1 ms     1 ms     2 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    10 ms     9 ms     9 ms  97-69-176-116.res.bhn.net [97.69.176.116]
  4    13 ms    13 ms     9 ms  ten0-1-0-4.bkfd01-car2.bhn.net [72.31.200.146]
  5    17 ms    19 ms    15 ms  10.bu-ether18.tustca4200w-bcr00.tbone.rr.com [107.14.16.236]
  6    21 ms    71 ms    19 ms  0.ae3.pr0.lax10.tbone.rr.com [66.109.9.26]
  7    16 ms    17 ms    17 ms  te0-4-0-17.ccr23.lax05.atlas.cogentco.com [154.54.11.133]
  8    21 ms    18 ms    19 ms  be2179.ccr22.lax01.atlas.cogentco.com [154.54.41.81]
  9    70 ms    71 ms    71 ms  be2066.ccr22.iah01.atlas.cogentco.com [154.54.7.53]
 10    69 ms    69 ms    72 ms  be2173.ccr42.atl01.atlas.cogentco.com [154.54.29.117]
 11    79 ms    79 ms    79 ms  be2169.ccr22.dca01.atlas.cogentco.com [154.54.31.98]
 12    87 ms    91 ms    87 ms  be2149.ccr42.jfk02.atlas.cogentco.com [154.54.31.126]
 13    91 ms    93 ms    92 ms  be2096.ccr22.bos01.atlas.cogentco.com [154.54.30.42]
 14    93 ms    95 ms    96 ms  te0-0-0-0.rcr11.b002133-1.bos01.atlas.cogentco.com [154.54.46.130]
 15    98 ms   106 ms    93 ms  38.111.40.114
 16     *        *        *     Request timed out.
 17    95 ms    95 ms    93 ms  198.49.243.17

In the example above you can see hop 2 and hop 16 fail to respond to any pings. From hop 1 to hop 3, there is a mere 8 millisecond increase. This would suggest that no issues are occurring from hop 2. If the number if larger than, let's say, 100, you might be a bit concerned. However, it looks like nothing is wrong. So we can safely assume that hop 2 is not responding to ICMP packets. (By the way, the reason hop 2 isn't responding to ICMP packets is because my ISP thought I was DoSing them and turned it off. Meanies.).

Between hop 15 and hop 17, there is almost no change in ping respond time. So we can also safely assume that hop 16 is working as expected and is simply not responding to ICMP packets.

nrglg · July 2015

Terminology (Extended)

IP Address (or abbreviated as simply "address"): These are the identify given to devices on a network to allow the connectivity of different devices. There are two (major and supported) types of IP, version 4 and version 6. Most devices at the time of this writing still use IPv4.

MAC Address: This is the unique network device identification number.

DNS: The Domain Name System is a system of large tables (or lists) which translate a domain name like "perfectworld.com" to an IP address so that you know where to go to reach a device. Whenever you ping a non-IP address like "pwieast3.perfectworld.com", it has to first ask DNS to lookup the IP address before it knows where to ping. Windows, by default, will cache many DNS entries and sometimes will require purging of the cached list if it is no longer translating to the correct IP address. This can be done with "ipconfig /flushdns".

I hope I've covered this topic fairly completely. I will return to write more segments if needed.

Samples (and notes)

General Note: The second hop is my ISP. They started blocking my ping expired requests some time back. Probably when I was harassing them about an issue that has since been resolved.

Twilight Temple

  1     1 ms    <1 ms    <1 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    12 ms     9 ms    10 ms  97-69-176-116.res.bhn.net [97.69.176.116]
  4     9 ms    12 ms    10 ms  ten0-3-0-4.bkfd01-car2.bhn.net [72.31.201.160]
  5    20 ms    18 ms    19 ms  10.bu-ether18.tustca4200w-bcr00.tbone.rr.com [107.14.16.236]
  6    23 ms    17 ms    21 ms  0.ae2.pr1.lax10.tbone.rr.com [107.14.19.54]
  7    20 ms    19 ms    18 ms  las-b21-link.telia.net [62.115.36.57]
  8    21 ms    26 ms    20 ms  las-b3-link.telia.net [213.155.137.59]
  9    32 ms    32 ms    30 ms  sjo-b21-link.telia.net [62.115.138.108]
 10    45 ms    29 ms    51 ms  internap-ic-140172-sjo-b21.c.telia.net [213.248.81.134]
 11    31 ms    29 ms    29 ms  border2.t7-1-bbnet1.sje004.pnap.net [66.151.144.20]
 12    29 ms    29 ms    29 ms  perfectworld-10.border2.sje004.pnap.net [64.95.143.190]
 13    31 ms    35 ms    35 ms  66.151.133.71

Etherblade

  1     1 ms    <1 ms     1 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    11 ms    10 ms     9 ms  97-69-176-114.res.bhn.net [97.69.176.114]
  4    10 ms    11 ms    19 ms  ten0-0-0-7.bkfd01-car1.bhn.net [72.31.213.6]
  5    13 ms    10 ms    15 ms  ten0-2-0-0.bkfd01-car2.bhn.net [72.31.200.181]
  6    17 ms    18 ms    24 ms  10.bu-ether18.tustca4200w-bcr00.tbone.rr.com [107.14.16.236]
  7    18 ms    32 ms    18 ms  0.ae2.pr1.lax10.tbone.rr.com [107.14.19.54]
  8    21 ms    18 ms    20 ms  las-b21-link.telia.net [62.115.36.57]
  9    30 ms    32 ms    31 ms  sjo-b21-link.telia.net [213.155.137.61]
 10    30 ms    28 ms    29 ms  internap-ic-140172-sjo-b21.c.telia.net [213.248.81.134]
 11    30 ms    33 ms    30 ms  border2.t7-1-bbnet1.sje004.pnap.net [66.151.144.20]
 12    30 ms    30 ms    30 ms  perfectworld-10.border2.sje004.pnap.net [64.95.143.190]
 13    31 ms    32 ms    42 ms  66.151.133.73

Tideswell
Note: Hop 17 & 18 do not respond to expired pings as a DDoS protection precaution.

  1     1 ms     1 ms     1 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    10 ms    10 ms     8 ms  97-69-176-116.res.bhn.net [97.69.176.116]
  4    10 ms    11 ms    15 ms  ten0-3-0-4.bkfd01-car2.bhn.net [72.31.201.160]
  5    23 ms    28 ms    26 ms  10.bu-ether18.tustca4200w-bcr00.tbone.rr.com [107.14.16.236]
  6    20 ms    22 ms    16 ms  0.ae3.pr0.lax10.tbone.rr.com [66.109.9.26]
  7    18 ms    17 ms    19 ms  te0-0-0-29.ccr23.lax05.atlas.cogentco.com [154.54.10.249]
  8    23 ms    20 ms    23 ms  be2180.ccr21.lax01.atlas.cogentco.com [154.54.41.57]
  9    71 ms    69 ms    73 ms  be2065.ccr21.iah01.atlas.cogentco.com [154.54.5.65]
 10    68 ms    70 ms    70 ms  be2687.ccr41.atl01.atlas.cogentco.com [154.54.28.69]
 11    80 ms    80 ms    83 ms  be2112.ccr41.dca01.atlas.cogentco.com [154.54.7.157]
 12    91 ms    87 ms    91 ms  be2148.ccr41.jfk02.atlas.cogentco.com [154.54.31.118]
 13    93 ms    95 ms    95 ms  be2094.ccr21.bos01.atlas.cogentco.com [154.54.30.14]
 14    98 ms    96 ms    95 ms  te0-0-1-0.rcr11.b002133-1.bos01.atlas.cogentco.com [154.54.46.134]
 15    98 ms    95 ms    98 ms  38.111.40.114
 16    95 ms    95 ms    93 ms  198.49.243.253
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19    93 ms    92 ms    95 ms  198.49.243.16

Dawn Glory
Note: This goes across the ocean for me, so it has to make a lot of visits along the way.

  1     1 ms    <1 ms     1 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    12 ms     9 ms    12 ms  97-69-176-114.res.bhn.net [97.69.176.114]
  4    10 ms    10 ms     9 ms  ten0-3-0-4.bkfd01-car1.bhn.net [72.31.200.150]
  5    14 ms    11 ms    11 ms  ten0-2-0-0.bkfd01-car2.bhn.net [72.31.200.181]
  6    20 ms    17 ms    19 ms  10.bu-ether18.tustca4200w-bcr00.tbone.rr.com [107.14.16.236]
  7    17 ms    17 ms    16 ms  0.ae0.pr0.lax10.tbone.rr.com [66.109.6.129]
  8    17 ms    22 ms    17 ms  te0-4-0-17.ccr23.lax05.atlas.cogentco.com [154.54.11.133]
  9    25 ms    22 ms    22 ms  be2179.ccr22.lax01.atlas.cogentco.com [154.54.41.81]
 10    73 ms    68 ms    67 ms  be2066.ccr22.iah01.atlas.cogentco.com [154.54.7.53]
 11    68 ms    66 ms    69 ms  be2690.ccr42.atl01.atlas.cogentco.com [154.54.28.129]
 12    79 ms    79 ms    82 ms  be2113.ccr42.dca01.atlas.cogentco.com [154.54.24.221]
 13    86 ms    87 ms    85 ms  be2149.ccr42.jfk02.atlas.cogentco.com [154.54.31.126]
 14   169 ms   168 ms   174 ms  be2490.ccr42.lon13.atlas.cogentco.com [154.54.42.86]
 15   165 ms   170 ms   165 ms  be12488.ccr42.ams03.atlas.cogentco.com [130.117.51.42]
 16   167 ms   165 ms   165 ms  be2447.rcr21.b021535-1.ams03.atlas.cogentco.com [130.117.50.250]
 17   166 ms   161 ms   162 ms  149.6.60.74
 18   161 ms   161 ms   162 ms  border4.ae2-bbnet2.ams004.pnap.net [95.172.78.71]
 19   163 ms   163 ms   163 ms  edge2.ae1-edgenet.ams004.pnap.net [208.146.38.22]
 20   173 ms   164 ms   162 ms  perfectworldent-7.edge2.ams004.pnap.net [95.172.88.94]
 21   166 ms   167 ms   167 ms  95.172.91.1
 22   164 ms   162 ms   164 ms  95.172.91.10

~~~~~~~~
Questions, Suggestions, Fixes, post them. I will update if needed.

sylenthunder · September 2015

More interesting information...
http://gizmodo.com/for-decades-the-public-was-not-allowed-to-view-maps-of-1731650394

sylenthunder · January 2016

Just another interesting oberservation on Wired VS. Wifi.

I recently upgraded my internet from AT&T's "fastest available" 16Mbps/1.5Mbps to Comcasts latest upgrade in my area 75Mbps/10Mbps.
Along with this upgrade, I went all out and got the most badass cable modem I could.

Some of it's basic specs are...

8 download & 4 upload channels (Max spec for DOCSIS 3.0)
3×3 MIMO antennas for 802.11ac
2×2 MIMO antennas for 802.11bgn
Wi-Fi® speeds up to 1800 Mbps (450Mbps for 802.11bgn, 1.3Gbps for 802.11ac )

So for my test, I'm using my work laptop with dual 802.11n antennas. I don't have an 802.11ac device to test with, but that wouldn't make any significant difference overall anyway.

Wired speed test gets the following results.
Ping: 16ms
Download: 89.92 Mb/s
Upload: 12.14 Mb/s
My wired connection is a 30 foot CAT-6 cable going from my modem, through the floor into the basement, across to the next room, then back up through the floor into a managed switch, and finally through a 3-foot CAT-5 cable to my laptop.

Now we switch to wireless, and perform the same test.
Ping: 72ms
Download: 38.51 Mb/s
Upload: 6.37 Mb/s
For the Wifi connection, I am about 15-18 feet away from the router. There are two walls with a set of stairs, and a closet full of coats and PC parts in between the laptop and the router.

This is with absolutely the most optimal settings possible (except for the walls), and you can clearly see a significant increase in ping, and a decrease in the overall speed. This does not include the additional encapsulation of the packets from the encrypted stream of the client, which would degrade the Wifi data stream even further.

So once again, you can see why you would want to avoid using Wifi if you can. These test conditions are on what would be optimal gear for the average consumer in the US. There is better gear out there, but the majority of you likely only dream of having data speeds like this. (I know, I was one of you until three days ago.) With smaller available data streams, the impact will be even greater.

nrglg · February 2016

You may want to get a better wireless NIC. Specifically, one that's installed into a PCI or PCIe slot if possible, but if not, then one by Hawking Tech. I get better speeds over wifi than wired nowadays.

I get downloads of 150-160Mb/s and uploads of 13-15Mb/s. Which is about right because that's the speeds I have. My wired connection is 95Mb/s down, and 15 Mb/s up. And my wireless data has to go through two rather thick walls and various electrical interference (well, it was interference when I was on the 2.4ghz ISM band). I'm using a router that supports both the 2.4ghz and 5.0ghz (lower) bands simultaneously with a wireless N card by Hawking Technology. I previously had a PCI wireless NIC, but it expired [img]http://asterpw.github.io/pwicons/emotes/tiger-13.gif[/img].

The reason I brought up this specific company is because they are, put bluntly, the only company I've seen make a decent USB wireless NIC. I've had their products before and each iteration is a great as the last. All of those other companies boast their amazing devices, but they always performed far worse overall and had a tendency to die quickly in my experience.

shaedan#4747 · November 2018

Just an FYI and, a thank you here -

PWI does play well over satellite internet. For those that don't have it or aren't familiar with it, between your modem and router (if you have one) and the Backbone Node for your ISP is a satellite that's roughly 22,000 miles from earth, in a geostationary orbit.

Satellite inernet uses KAband ( like FM radio sort of) not digital, so, the modems for satellite internet have to modulate the digital signal form your computer to the correct band for the satellite to understand, then the satellite sends your signal to a big gateway, ground station with servers and, remodulators to translate it back to digital like the internet understands.

Since it is a wireless system, we are limited to the speed of light and, with all of the demodulation and modulation that has to happen for it to work at all, latency (echo/ping) is going to be 600 ms at BEST and, often 700-800 ms. Not every game can be played that way but PWI can and, that's a credit to the dev team behind the game.

I would suggest a ranged or partially ranged class for those with high latency connection and, please don't try to be a healer, that 1/2 to 3/4 second lag you have will get the tank and others killed.

minniemousessss#4995 · November 2018

Hi what the funk up with you all😍😭🐹💩

jessica#0563 · December 2021

Okay for starters. before you guys added this wildmaker class this net ran this game just fine even with a bit high ping in game. downloaded it fine ran fine could multi log clients without any problems . after you added the new class and its many updates. i have had none stop login disconnects but if i log the new class it never disconnects yet u all telling me its my net? if that was so why dont it disconnect on the new class loging in????? only disconnects on loging any old toons made... and so i fully took out all pwi /arc and redownloaded it. and now on day 4 it is still verifying..... what are you guys doing to the game that makes it take so long to Verify a client? if it was this net like u all say then it sould do it on all toons logged... not just the old classes. what i thank. you all doing this to make us have to buy multi absencent notes getting us to spend money in this game for gold.....

Traceroute, pinging, the internet, and you

Comments

Categories