Assistance With Ping and Jitter

[SilentStorm]

Hi everyone, been having lots of issues with ping and jitter recently, despite having Cake QoS on my router, which leads me to believe this is an ISP issue.

Here's some ping results... when I ping 8.8.8.8, I get no packet loss or any issues like that. I've pinged it several times but couldn't fit it all into the screenshot...

When I ping my ISP's DNS server (which is what my gateway is operating on, I can't change that), I am receiving packet loss.

Is this reason for concern?

 

[ColinTaylor]

When I ping my ISP's DNS server (which is what my gateway is operating on, I can't change that), I am receiving packet loss.

Is this reason for concern?

Probably not. There's no obligation for the DNS server to reply to a ping in a timely manner, or at all. The fact that you can ping the wider internet without issue suggests that there's nothing wrong with your connection.

 

[SilentStorm]

Probably not. There's no obligation for the DNS server to reply to a ping in a timely manner, or at all. The fact that you can ping the wider internet without issue suggests that there's nothing wrong with your connection.

So I'm confused. I'm waiting in a live chat right now to be able to talk to my ISP (Rogers Canada.)

According to Moderators on their forum, I shouldn't be seeing any packet loss when ping their DNS servers... which is why I'm concerned.

 

[ColinTaylor]

According to Moderators on their forum, I shouldn't be seeing any packet loss when ping their DNS servers... which is why I'm concerned.

Well there might be an issue with their DNS servers (e.g. overloaded) in which case configure your router to use someone else's. You said that you have no problems with Google's DNS servers.

 

[SilentStorm]

Well there might be an issue with their DNS servers (e.g. overloaded) in which case use someone else's. You said that you have no problems with Google's DNS servers.

I cannot switch DNS servers, that's the thing. It's configured into the gateway and they do not allow me to change it.

 

[ColinTaylor]

I just edited my previous post to be clearer. It doesn't matter what DNS server your gateway is using, what matters is what DNS servers your router and clients are using. If your ISP's DNS servers are unreliable make sure your router and clients are using another DNS, e.g. Google.

 

[eibgrad]

GRC's | DNS Nameserver Performance Benchmark

DNS Nameserver Performance Benchmark

www.grc.com

 

[Datalink]

@SilentStorm, you're pinging the wrong IP address, unless of course, Rogers established that address specifically for XB6 and XB7 modems. The correct IP address for Rogers IPV4 DNS is:

Primary: 64.71.255.204
Secondary: 64.71.255.198

If I use the same address that you used, I don't end up with any packet loss.

Given the fact that I don't see any packet loss, I'd be looking at the external cable for signal issues. The easiest way to check that cable is to ping the Cable Modem Termination System (CMTS). Run a trace to anywhere, it doesn't matter where, google for example:

tracert www.google.com

If the modem is running in its default Gateway mode, the second hop will be the CMTS address.

If the modem is running in Bridge mode with a router behind it, the second hop will be the CMTS address as the modem, in Bridge mode doesn't show up in the trace.

Ping that second IP address for a period of time, at least an hour, to see what shows up for latency and packet loss. The typical response time on Rogers network is 8 to 13 ms, give or take a milli-second or two. You should not see any packet loss.

That path, from modem to CMTS is:

1. Modem to basement structured wiring panel;
2. Structured wiring panel to external demarcation point;
3. External demarcation point to local tap (ground pedestal or utility pole mounted);
4. Local tap to neighbourhood node;
5. Neighbourhood node to CMTS.

All of this path is via copper cable except for the neighbourhood node to CMTS path which is via fibre.

If you're in an apartment/condo, etc, then the cable path would probably be:

1. Modem to utility closet structured wiring panel;
2. Structured wiring panel to Multiple Dwelling Unit located in the basement utility room;
3. MDU to neighbourhood node via copper cable or CMTS via fibre

This path will be via copper cable, except perhaps for the run from the MDU to the CMTS. If the building is large enough, it might have its own run from the MDU to the CMTS via fibre.

If there is an issue with the copper cabling from the modem to the neighbourhood node or MDU, you will see that in the ping results. You shouldn't see any more than perhaps one or two lost pings over the course of an hour.

There is always the possibility that you're on a heavily loaded neighbourhood node or CMTS, in which case you need to speak with a Tier 2 tech, as the Tier 1 tech that you will be chatting with has no access to the load numbers for either the neighbourhood node or CMTS.

Ok, so, ping the second hop IP address via ethernet connected pc for an hour, to see what the results look like. After one hour, running the following ping command, the ping test will automatically stop:

ping -n 3600 xxx.xxx.xxx.xxx

Fwiw, running Pingplotter to the same target will graphically show the packet loss. Thats the only thing that I recommend Pingplotter for, to look for packet loss from the modem or from the CMTS. Pingplotter can be used in Pro mode for 14 (?) days before it locks down to a limited freebie mode unless or course you buy a standard or pro licence. From what I remember, the standard licence allows you to see two days worth of data, if you run a ping test for that length of time or longer, and the pro licence allows you to see data across 5 or 7 days.

The major problem with Pingplotter is that the bottom graphical display will average the plot results when there is more than one data point in a horizontal pixel, which would be the situation if you were running a default ping interval of 2.5 seconds for more than a day. So, as the number of data points goes up, the plot flattens out to the point that it becomes a flat line, hiding any high latency results due to the plot averaging. If you run anything less than 2.5 seconds for a ping interval, you can run into that situation for display intervals less than 24 hours.

For packet loss testing, Pingplotter is still usefull.

 

[SilentStorm]

@SilentStorm, you're pinging the wrong IP address, unless of course, Rogers established that address specifically for XB6 and XB7 modems. The correct IP address for Rogers IPV4 DNS is:

Primary: 64.71.255.204
Secondary: 64.71.255.198

If I use the same address that you used, I don't end up with any packet loss.

Given the fact that I don't see any packet loss, I'd be looking at the external cable for signal issues. The easiest way to check that cable is to ping the Cable Modem Termination System (CMTS). Run a trace to anywhere, it doesn't matter where, google for example:

tracert www.google.com

If the modem is running in its default Gateway mode, the second hop will be the CMTS address.

If the modem is running in Bridge mode with a router behind it, the second hop will be the CMTS address as the modem, in Bridge mode doesn't show up in the trace.

Ping that second IP address for a period of time, at least an hour, to see what shows up for latency and packet loss. The typical response time on Rogers network is 8 to 13 ms, give or take a milli-second or two. You should not see any packet loss.

That path, from modem to CMTS is:

1. Modem to basement structured wiring panel;
2. Structured wiring panel to external demarcation point;
3. External demarcation point to local tap (ground pedestal or utility pole mounted);
4. Local tap to neighbourhood node;
5. Neighbourhood node to CMTS.

All of this path is via copper cable except for the neighbourhood node to CMTS path which is via fibre.

If you're in an apartment/condo, etc, then the cable path would probably be:

1. Modem to utility closet structured wiring panel;
2. Structured wiring panel to Multiple Dwelling Unit located in the basement utility room;
3. MDU to neighbourhood node via copper cable or CMTS via fibre

This path will be via copper cable, except perhaps for the run from the MDU to the CMTS. If the building is large enough, it might have its own run from the MDU to the CMTS via fibre.

If there is an issue with the copper cabling from the modem to the neighbourhood node or MDU, you will see that in the ping results. You shouldn't see any more than perhaps one or two lost pings over the course of an hour.

There is always the possibility that you're on a heavily loaded neighbourhood node or CMTS, in which case you need to speak with a Tier 2 tech, as the Tier 1 tech that you will be chatting with has no access to the load numbers for either the neighbourhood node or CMTS.

Ok, so, ping the second hop IP address via ethernet connected pc for an hour, to see what the results look like. After one hour, running the following ping command, the ping test will automatically stop:

ping -n 3600 xxx.xxx.xxx.xxx

Fwiw, running Pingplotter to the same target will graphically show the packet loss. Thats the only thing that I recommend Pingplotter for, to look for packet loss from the modem or from the CMTS. Pingplotter can be used in Pro mode for 14 (?) days before it locks down to a limited freebie mode unless or course you buy a standard or pro licence. From what I remember, the standard licence allows you to see two days worth of data, if you run a ping test for that length of time or longer, and the pro licence allows you to see data across 5 or 7 days.

The major problem with Pingplotter is that the bottom graphical display will average the plot results when there is more than one data point in a horizontal pixel, which would be the situation if you were running a default ping interval of 2.5 seconds for more than a day. So, as the number of data points goes up, the plot flattens out to the point that it becomes a flat line, hiding any high latency results due to the plot averaging. If you run anything less than 2.5 seconds for a ping interval, you can run into that situation for display intervals less than 24 hours.

For packet loss testing, Pingplotter is still usefull.

Thank you very much for this detailed information.

Pinged 64.71.255.204 and I'm still getting packet loss, but I did this wireless. I'll give it a try wired tomorrow.

35 percent packet loss.

I'll try the rest tomorrow and let you know.

 

[Datalink]

You have to run this via ethernet to determine if you have a cable problem on the go.

If you're using the XB6 and probably the XB7 with Rogers Ignite TV service, you normally don't have any control over the wifi channels that the modem uses unless you've never used the wifi app or online app to access the modem and set it up. If you've used the wifi app, or online app, or if you're running pods, then you really don't have any control over the wifi channels. As a result, the wifi channels lock down the lower 5 Ghz channels, along with anyone and everyone else who is using the same modem and Ignite TV service. Its important to be aware of this as the Canadian regulations limit the power output depending on which channel range you use. The limits are:

Channels 36 to 48: 50 or 200 milli-watts conducted power depending on when the device was approved by Industry Canada;

Channels 52 to 144: (DFS channels) 250 mw conducted power

Channels 149 to 165: 1 watt conducted power

Those limits are seen in the following chart:

5GHz Band Channel Availability in Canada – SemFio Networks

www.semfionetworks.com

So, the important point here is that the lower channels run a maximum of 200 milli-watts conducted power while the upper channels run a maximum of 1 watt, roughly 5 times the lower power output. That power output difference makes a considerable difference in the maximum operating range from the modem. It makes pod usage almost a requirement for typical homes, just depends on where the modem happens to be placed. And, the follow-on from that is that pod usage cuts down on the data rate (at distance) and that pod placement is very important to obtain the same wifi coverage that you would get using a wifi transmitter which is running a higher 5 Ghz channel.

Fwiw, for a windows pc/laptop, download winfi lite from: https://www.helge-keck.com/

Install that on a wifi pc/laptop. When its running, sort the data via RSSI, using the column title to sort up or down. Sort the RSSI column top to bottom, ie, 0 dBmW at the top, -90 dBmW at the bottom. The RSSI scale is a negative scale, with 0 dBmW at the top. Typically, the best you can do is -30 dBmV. Select the wrench symbol from the second row near the right hand side. That's the tools icon which will display a lower panel. From that panel, select Spectrum to see the graphical representation of the upper text data. Use that to check out your wifi environment and signal levels around your home. See who else you're competing with for the same channels. If you're running a 2.4 Ghz channel, thats probably a write off as I would expect every 2.4 Ghz channel to have multiple wifi networks running on it. So, the better alternative is wired (preferred). If there's no chance of that, then a MoCA adapter, which isn't great for latency, or perhaps a low competition 5 Ghz channel with adequate signal levels. If you can't go via ethernet, any other alternatives might not provide the level of performance that you're looking for.

 

[SilentStorm]

You have to run this via ethernet to determine if you have a cable problem on the go.

If you're using the XB6 and probably the XB7 with Rogers Ignite TV service, you normally don't have any control over the wifi channels that the modem uses unless you've never used the wifi app or online app to access the modem and set it up. If you've used the wifi app, or online app, or if you're running pods, then you really don't have any control over the wifi channels. As a result, the wifi channels lock down the lower 5 Ghz channels, along with anyone and everyone else who is using the same modem and Ignite TV service. Its important to be aware of this as the Canadian regulations limit the power output depending on which channel range you use. The limits are:

Channels 36 to 48: 50 or 200 milli-watts conducted power depending on when the device was approved by Industry Canada;

Channels 52 to 144: (DFS channels) 250 mw conducted power

Channels 149 to 165: 1 watt conducted power

Those limits are seen in the following chart:

5GHz Band Channel Availability in Canada – SemFio Networks

www.semfionetworks.com

So, the important point here is that the lower channels run a maximum of 200 milli-watts conducted power while the upper channels run a maximum of 1 watt, roughly 5 times the lower power output. That power output difference makes a considerable difference in the maximum operating range from the modem. It makes pod usage almost a requirement for typical homes, just depends on where the modem happens to be placed. And, the follow-on from that is that pod usage cuts down on the data rate (at distance) and that pod placement is very important to obtain the same wifi coverage that you would get using a wifi transmitter which is running a higher 5 Ghz channel.

Fwiw, for a windows pc/laptop, download winfi lite from: https://www.helge-keck.com/

Install that on a wifi pc/laptop. When its running, sort the data via RSSI, using the column title to sort up or down. Sort the RSSI column top to bottom, ie, 0 dBmW at the top, -90 dBmW at the bottom. The RSSI scale is a negative scale, with 0 dBmW at the top. Typically, the best you can do is -30 dBmV. Select the wrench symbol from the second row near the right hand side. That's the tools icon which will display a lower panel. From that panel, select Spectrum to see the graphical representation of the upper text data. Use that to check out your wifi environment and signal levels around your home. See who else you're competing with for the same channels. If you're running a 2.4 Ghz channel, thats probably a write off as I would expect every 2.4 Ghz channel to have multiple wifi networks running on it. So, the better alternative is wired (preferred). If there's no chance of that, then a MoCA adapter, which isn't great for latency, or perhaps a low competition 5 Ghz channel with adequate signal levels. If you can't go via ethernet, any other alternatives might not provide the level of performance that you're looking for.

Thanks for this, will give this a try tomorrow.

Also, one thing I am noticing, is once all this ping and jitter starts happening, my upload speeds start sinking, (instead of 20 mb upload, starts going down to single digits.)

They want to replace my modem, so I said sure, might as well. It's free anyways.

Something in me says this is node congestion because this all started happening once we entered lockdown, but if it was node congestion, wouldn't download speeds sink too? I'm getting the expected 500 download speed.

 

[Datalink]

I agree with your thoughts on node congestion. Upload data rates are a problem due to the limited number of upstream channels (3 or 4) that Rogers uses.

Having said that, look at your modem signal data which should show 32 downstream Quadrature Amplitude Modulation (QAM) channels and most likely one active Orthogonal Frequency Division Multiplex (OFDM) channel. That downstream OFDM channel has greatly improved the downstream latency since it was enabled in March 2017. Rogers is now enabling an upstream Orthogonal Frequency Division Multiple Access (OFDMA) channel across the network. That is probably being slowed down due to issues with the white Hitron CODA-4582 modem, so, you may or may not see an OFDMA channel enabled in the upstream channel group. If its enabled, I'd expect you to see higher performance as a result. If its not there, I'm not surprised. That means that you're subject the upstream congestion that most Rogers users are suffering from. If you see an OFDMA channel enabled, given the problems that you're seeing, I'd say that your node congestion call is right on. In that case, the only tech who can give you any indication of it will be a Tier 2 or Level 2 tech. Usually you have to twist the Level 1 tech's arm to be transferred over the a Level 2 tech. Even if you find out that the neighbourhood node load is somewhere over 85%, there's probably no plans in the works to split the node, but, the only way to find out is to chat with a Level 2 tech.

 

[MarkyPancake]

A popular ISP here in the UK has been getting lots of questions about latency on their community forum and the general consensus is it's due to the increased utilisation caused by everyone being in lockdown.

 

[SilentStorm]

I agree with your thoughts on node congestion. Upload data rates are a problem due to the limited number of upstream channels (3 or 4) that Rogers uses.

Having said that, look at your modem signal data which should show 32 downstream Quadrature Amplitude Modulation (QAM) channels and most likely one active Orthogonal Frequency Division Multiplex (OFDM) channel. That downstream OFDM channel has greatly improved the downstream latency since it was enabled in March 2017. Rogers is now enabling an upstream Orthogonal Frequency Division Multiple Access (OFDMA) channel across the network. That is probably being slowed down due to issues with the white Hitron CODA-4582 modem, so, you may or may not see an OFDMA channel enabled in the upstream channel group. If its enabled, I'd expect you to see higher performance as a result. If its not there, I'm not surprised. That means that you're subject the upstream congestion that most Rogers users are suffering from. If you see an OFDMA channel enabled, given the problems that you're seeing, I'd say that your node congestion call is right on. In that case, the only tech who can give you any indication of it will be a Tier 2 or Level 2 tech. Usually you have to twist the Level 1 tech's arm to be transferred over the a Level 2 tech. Even if you find out that the neighbourhood node load is somewhere over 85%, there's probably no plans in the works to split the node, but, the only way to find out is to chat with a Level 2 tech.

For upload, I don't see any OFDMA channels enabled... so I think you're right there.

EDIT: Nevermind, I must've been looking at the wrong thing.. for upstream it's showing 4 QAM and 1 OFDMA. I'll try and see if I can request a level II tech...

For download, they're all, as you said, QAM with one being OFDM.

Pardon my lack of knowledge with these channel types... is this something I can request them to change? Is this difficult to do?

Also, I managed to have a chat with them yesterday. The live agent said there's "several devices down in our area, leading to node congestion." They've escalated the issue to an "Engineering team" (is this the level II tech?), in which they sent us a message this morning saying "there's nothing wrong."

Also, is changing the channels a software thing that they can do from their end?

Appreciate your help thus far. I'll report back today with some numbers today.

The main issue is when gaming (hardwired, of course). Usually, everyone else who is using WiFi is web browsing or such, so these issues are likely negligible to them...

I'm HIGHLY doubtful that it is a modem issue as they wanted to make it... and even then, I had 9 devices connected to the gateway when the issue was happening again on a 500/20 package.

 

[SilentStorm]

I agree with your thoughts on node congestion. Upload data rates are a problem due to the limited number of upstream channels (3 or 4) that Rogers uses.

Having said that, look at your modem signal data which should show 32 downstream Quadrature Amplitude Modulation (QAM) channels and most likely one active Orthogonal Frequency Division Multiplex (OFDM) channel. That downstream OFDM channel has greatly improved the downstream latency since it was enabled in March 2017. Rogers is now enabling an upstream Orthogonal Frequency Division Multiple Access (OFDMA) channel across the network. That is probably being slowed down due to issues with the white Hitron CODA-4582 modem, so, you may or may not see an OFDMA channel enabled in the upstream channel group. If its enabled, I'd expect you to see higher performance as a result. If its not there, I'm not surprised. That means that you're subject the upstream congestion that most Rogers users are suffering from. If you see an OFDMA channel enabled, given the problems that you're seeing, I'd say that your node congestion call is right on. In that case, the only tech who can give you any indication of it will be a Tier 2 or Level 2 tech. Usually you have to twist the Level 1 tech's arm to be transferred over the a Level 2 tech. Even if you find out that the neighbourhood node load is somewhere over 85%, there's probably no plans in the works to split the node, but, the only way to find out is to chat with a Level 2 tech.

So update again, they opened a maintenance ticket and I asked them to take a look at the node congestion. This time, I requested that they specifically take a look at the congestion between 5-9 PM, since that's when it's horrible.

I wasn't able to speak with the Level 2 technician, what they told me is they open a ticket to the level 2 technicians and they forward any and all information for them to take a look..

They told me to expect an update within 4-6 business days.

 

[SilentStorm]

@SilentStorm, you're pinging the wrong IP address, unless of course, Rogers established that address specifically for XB6 and XB7 modems. The correct IP address for Rogers IPV4 DNS is:

Primary: 64.71.255.204
Secondary: 64.71.255.198

If I use the same address that you used, I don't end up with any packet loss.

Given the fact that I don't see any packet loss, I'd be looking at the external cable for signal issues. The easiest way to check that cable is to ping the Cable Modem Termination System (CMTS). Run a trace to anywhere, it doesn't matter where, google for example:

tracert www.google.com

If the modem is running in its default Gateway mode, the second hop will be the CMTS address.

If the modem is running in Bridge mode with a router behind it, the second hop will be the CMTS address as the modem, in Bridge mode doesn't show up in the trace.

Ping that second IP address for a period of time, at least an hour, to see what shows up for latency and packet loss. The typical response time on Rogers network is 8 to 13 ms, give or take a milli-second or two. You should not see any packet loss.

That path, from modem to CMTS is:

1. Modem to basement structured wiring panel;
2. Structured wiring panel to external demarcation point;
3. External demarcation point to local tap (ground pedestal or utility pole mounted);
4. Local tap to neighbourhood node;
5. Neighbourhood node to CMTS.

All of this path is via copper cable except for the neighbourhood node to CMTS path which is via fibre.

If you're in an apartment/condo, etc, then the cable path would probably be:

1. Modem to utility closet structured wiring panel;
2. Structured wiring panel to Multiple Dwelling Unit located in the basement utility room;
3. MDU to neighbourhood node via copper cable or CMTS via fibre

This path will be via copper cable, except perhaps for the run from the MDU to the CMTS. If the building is large enough, it might have its own run from the MDU to the CMTS via fibre.

If there is an issue with the copper cabling from the modem to the neighbourhood node or MDU, you will see that in the ping results. You shouldn't see any more than perhaps one or two lost pings over the course of an hour.

There is always the possibility that you're on a heavily loaded neighbourhood node or CMTS, in which case you need to speak with a Tier 2 tech, as the Tier 1 tech that you will be chatting with has no access to the load numbers for either the neighbourhood node or CMTS.

Ok, so, ping the second hop IP address via ethernet connected pc for an hour, to see what the results look like. After one hour, running the following ping command, the ping test will automatically stop:

ping -n 3600 xxx.xxx.xxx.xxx

Fwiw, running Pingplotter to the same target will graphically show the packet loss. Thats the only thing that I recommend Pingplotter for, to look for packet loss from the modem or from the CMTS. Pingplotter can be used in Pro mode for 14 (?) days before it locks down to a limited freebie mode unless or course you buy a standard or pro licence. From what I remember, the standard licence allows you to see two days worth of data, if you run a ping test for that length of time or longer, and the pro licence allows you to see data across 5 or 7 days.

The major problem with Pingplotter is that the bottom graphical display will average the plot results when there is more than one data point in a horizontal pixel, which would be the situation if you were running a default ping interval of 2.5 seconds for more than a day. So, as the number of data points goes up, the plot flattens out to the point that it becomes a flat line, hiding any high latency results due to the plot averaging. If you run anything less than 2.5 seconds for a ping interval, you can run into that situation for display intervals less than 24 hours.

For packet loss testing, Pingplotter is still usefull.

Here's my tracert to google. You're going to have to help me with this one because no clue what I'm looking at.

"Request timed out" doesn't look pretty though.

Called Rogers AGAIN today after internet was HORRIBLE. Constant lagging and what not. Spoke to a supervisor. They're going to monitor the node over the next 2 days apparently and place some sort of RPP device? Don't know if that's what it's called, but I'm guessing it's to monitor the node.

I'm not a person who tends to threaten companies with "service cancellation," but I may have to do it if this issue persists...

 

[ColinTaylor]

"Request timed out" doesn't look pretty though.

That's perfectly normal. Some intermediate hops may not respond to pings, or respond slowly. The only result that really matters is the final destination. You would have to run the test while you are experiencing the problems on your line to stand a chance of pinpointing the problem.

He's my traceroute for comparison.

Tracing route to www.google.com [216.58.213.100]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    11 ms    10 ms     9 ms  80.3.64.81
  4     *        *        *     Request timed out.
  5    12 ms    14 ms    11 ms  62.253.175.34
  6    14 ms    11 ms    11 ms  212.250.14.74
  7    28 ms    16 ms    21 ms  108.170.246.161
  8    12 ms    12 ms    11 ms  216.239.57.121
  9    19 ms    31 ms    17 ms  216.58.213.100

Trace complete.

 

[dave14305]

There’s an interesting utility called mtr available in Entware that I first heard about at OpenWRT. It runs pings to all the hops along a traceroute to a destination.

 

[ColinTaylor]

There’s an interesting utility called mtr available in Entware that I first heard about at OpenWRT. It runs pings to all the hops along a traceroute to a destination.

There's a Windows equivalent that I've used for years. It hasn't been updated for 10 years (not that there's anything that needs updating), and the company that hosted it doesn't exist any more, but it still works.

WinMTR - Browse /Latest at SourceForge.net

WinMTR is a free MS Windows visual application that combines the functionality of the traceroute and ping in a single network diagnostic tool.

sourceforge.net

 

[SilentStorm]

That's perfectly normal. Some intermediate hops may not respond to pings, or respond slowly. The only result that really matters is the final destination. You would have to run the test while you are experiencing the problems on your line to stand a chance of pinpointing the problem.

He's my traceroute for comparison.

Tracing route to www.google.com [216.58.213.100]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    11 ms    10 ms     9 ms  80.3.64.81
  4     *        *        *     Request timed out.
  5    12 ms    14 ms    11 ms  62.253.175.34
  6    14 ms    11 ms    11 ms  212.250.14.74
  7    28 ms    16 ms    21 ms  108.170.246.161
  8    12 ms    12 ms    11 ms  216.239.57.121
  9    19 ms    31 ms    17 ms  216.58.213.100

Trace complete.

Thanks. What exactly should I be looking for? Don't want to bombard you with results that aren't useful.