cancel
Showing results for 
Search instead for 
Did you mean: 

CODA-4582 - Open Issues for Investigation

RogersDave
Retired Support
Retired Support

*** This post was last edited May 2, 2017 ***

 

Good morning Community,

 

As I mentioned in a post two days ago, we have received the next firmware 2.0.10.20 from Hitron. We are currently running initial testing on this version and will push it out to participants in the firmware trial program as soon as it passes initial testing.

 

However, while running these tests, we discovered abnormal behavior with ICMP and are awaiting feedback from Hitron today to asses how this will be addressed. As soon as I this is confirmed, I’ll update the change log with the correct version information and start pushing it out.

 

In parallel, we are still working on the following high priority items. In some cases below, I requested affected customers to reach out to me via private message. If you do so, please include your modem MAC address in the subject line (even if we exchange messages daily) as there are a lot of you reaching out to me daily 🙂

 

UDP Packet Loss

The investigation for what has been reported as UDP packet loss is still ongoing. We have deployed a probe at one fellow forum member on both a CODA-4582 and a CGNM-3552 to collect additional data. We are actively working with Hitron and Intel on the results observed.

 

Based on what we know so far, in most instances UDP packet loss is coupled with higher uplink usage in the area. Although the impact is noticeable in specific logs (League of Legends), the root cause for the perceivable impact (while playing) is likely related to bufferbloat (see next issue).

 

 

Bufferbloat

When comparing the performance of a CODA-4582 to a CGNM-3552 in the same network conditions, the CODA-4582 consistently reports higher bufferbloat when tested on DSLReports.

 

Update April 12: The solution for this problem will come in two folds. It will require a change in software which will possibly be included in 2.0.10.27 but more likely in 2.0.10.28 and a change in network configuration.

 

The network configuration change is not compatible with the current firmware so this change will only come after a vast majority of the modems are running the new code. We are however looking at a way to make the change only for specific modems to support testing in the community.

 

Update April 22: This problem seems resolved in firmware 2.0.10.27

 

 

5 GHz WiFi Low range for channels 36 to 48

Lower WiFi channels on the modem have a much smaller range. This is due in part to the limit imposed by Industry Canada to maximum transmit power.

 

Furthermore, the current automatic channel selection (auto mode) tends to select the lower channels when in similar load conditions.

 

Workaround: manually select higher channels (149-153-157-161)

 

Update April 22: The channel selection algorithm has been improved in firmware 2.0.10.27

 

 

Loss of OFDM Channel Lock

Under some RF conditions, the modem fails to lock properly on the OFDM channel. This typically result in variable performance.

 

Update April 12: This problem is resolved in 2.0.10.26T2

 

 

List of connected device does not get fully populated

This is a known issue that has been tracked since firmware 2.0.10.13. We are making improvements at every firmware but it is not a perfect system.

 

The situation is worst after a reboot or firmware upgrade as the list gets reset and must be repopulated as devices renew their DHCP lease.

 

 

NAT Loopback not working for wired clients

When setting up port forwarding to an internal server, it is possible for a client on WiFi to reach the server using the external IP/port. If the client is on a wired interface, it doesn't work.

 

Update April 12: This problem is resolved in 2.0.10.26T2 (not confirmed)

 

 

LAN Counters not working

Some customers reported that LAN counters (especially in bridge mode) are reporting inaccurate values.

 

This problem has been reported to Hitron for investigation.

 

 

Unexpected modem reboot

Some customers reported their modem reboots unexpectedly. We have also seen this behavior in our lab.

 

Update April 12: This problem is resolved in 2.0.10.26T2

 

 

Missing SC-QAM Channels

After a reboot, some modems are missing SC-QAM channels. A fix has been implemented in 2.0.10.26T2 to address this behavior but it has not corrected all scenarios.

 

Investigation continues with Hitron.

 

 

WiFi Survey

The WiFi Survey functionality in firmware 2.0.10.26T2 (and possibly before) reports incorrect SSID names.

 

 

Guest Network

When connecting to the Guest Network, an error message is displayed "only allow DHCP client to use this wireless".  This has been reported in firmware 2.0.10.26T2.

 

Update April 22: This issue has been resolved in firmware 2.0.10.27

Update May 2: It seems this issue is not fully resolved and still experienced by some users


 

Future Planned Improvements

The following are items that we are working on in parallel of the above.

  • Improvement in WiFi speeds
  • Improvement in latency / bufferbloat

 

 

Dave

 

*Edited Labels*

2,620 REPLIES 2,620

Re: CODA-4582 - Open Issues for Investigation

Telek
I plan to stick around

@Datalink right, so I'm very curious about the results of the DNS queries, and if that can be used as a potential fix for those who are experiencing problems.

Re: CODA-4582 - Open Issues for Investigation

Mythen
I plan to stick around
@Datalink. That makes no sense for sure. But I will start using the Google DNS and see if it helps with twitch

Re: CODA-4582 - Open Issues for Investigation

Try running WinMTR, run a few tests with Rogers DNS and then switch to Google DNS and run the same targets to see what turns up, if anything.

Re: CODA-4582 - Open Issues for Investigation

sdmeller
I've been here awhile

Thanks!

Here my log:

 

1 04/25/2017 14:01:09 82000600 critical Unicast Maintenance Ranging attempted - No response - Retries exhausted;CM-MAC=xxxxxxxxxxxxxxxx;CMTS-MAC=xxxxxx;CM-QOS=1.1;CM-VER=3.1;
2 04/25/2017 14:02:54 82000200 critical No Ranging Response received - T3 time-out;CM-MAC=xxxxxx;CMTS-MAC=xxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
3 04/25/2017 14:03:03 82000900 warning B-INIT-RNG Failure - Retries exceeded;CM-MAC=xxxxxxxx;CMTS-MAC=xxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
4 04/25/2017 14:04:36 82000200 critical No Ranging Response received - T3 time-out;CM-MAC=xxxxxxxxxxxx;CMTS-MAC=xxxxxxx;CM-QOS=1.1;CM-VER=3.1;
5 04/25/2017 14:04:44 82000900 warning B-INIT-RNG Failure - Retries exceeded;CM-MAC=xxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
6 04/25/2017 14:06:06 82000200 critical No Ranging Response received - T3 time-out;CM-MAC=xxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
7 04/25/2017 14:06:08 82000900 warning B-INIT-RNG Failure - Retries exceeded;CM-MAC=xxxxxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
8 04/25/2017 14:06:24 82000200 critical No Ranging Response received - T3 time-out;CM-MAC=xxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
9 04/25/2017 14:08:10 90000000 warning MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=xxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
10 04/25/2017 14:09:17 82000200 critical No Ranging Response received - T3 time-out;CM-MAC=xxxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
11 04/25/2017 14:09:18 82000300 critical Ranging Request Retries exhausted;CM-MAC=xxxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
12 04/25/2017 14:09:18 82000600 critical Unicast Maintenance Ranging attempted - No response - Retries exhausted;CM-MAC=xxxxxxxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
13 04/25/2017 14:09:23 82000200 critical No Ranging Response received - T3 time-out;CM-MAC=xxxxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
14 04/25/2017 14:09:24 82000300 critical Ranging Request Retries exhausted;CM-MAC=xxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
15 04/25/2017 14:09:24 82000600 critical Unicast Maintenance Ranging attempted - No response - Retries exhausted;CM-MAC=xxxxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
16 04/25/2017 14:09:24 82000200 critical No Ranging Response received - T3 time-out;CM-MAC=xxxxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
17 04/25/2017 14:09:25 82000300 critical Ranging Request Retries exhausted;CM-MAC=xxxxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
18 04/25/2017 14:09:25 82000600 critical Unicast Maintenance Ranging attempted - No response - Retries exhausted;CM-MAC=xxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
19 04/25/2017 14:09:58 82000200 critical No Ranging Response received - T3 time-out;CM-MAC=xxxxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;
20 04/25/2017 14:10:17 90000000 warning MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=xxxxxxxxxxxxx;CMTS-MAC=xxxxxxxxxxxxx;CM-QOS=1.1;CM-VER=3.1;

 

Signals:

 

Downstream Overview
Port IDFrequency (MHz)ModulationSignal strength (dBmV)Channel IDSignal noise ratio (dB)
1615000000256QAM4.4001137.636
2561000000256QAM3.900237.636
3567000000256QAM4.900338.983
4573000000256QAM5.500438.605
5579000000256QAM5.200538.983
6585000000256QAM5.700638.983
7591000000256QAM5.400738.983
8597000000256QAM5.100838.605
9603000000256QAM5.100938.605
10609000000256QAM4.7001038.605
11555000000256QAM3.800138.605
12621000000256QAM4.6001238.605
13633000000256QAM5.1001337.636
14639000000256QAM5.1001437.356
15645000000256QAM5.3001537.636
16651000000256QAM5.5001637.636
17657000000256QAM6.0001737.636
18663000000256QAM6.2001838.605
19669000000256QAM6.5001937.636
20675000000256QAM6.6002038.605
21681000000256QAM6.3002137.636
22687000000256QAM6.5002237.636
23693000000256QAM5.7002337.356
24699000000256QAM6.3002437.636
25705000000256QAM5.4002537.636
26711000000256QAM5.0002637.636
27717000000256QAM5.6002737.356
28723000000256QAM5.5002837.636
29825000000256QAM7.8002935.780
30831000000256QAM7.7003035.595
31837000000256QAM7.9003136.387
32843000000256QAM7.7003236.610
OFDM Downstream Overview
ReceiverFFT typeSubcarr 0 Frequency(MHz)PLC lockedNCP lockedMDC1 lockedPLC power(dBmv)
0NANANONONONA
14K275600000YESYESYES3.200001
Upstream Overview
Port IDFrequency (MHz)ModulationSignal strength (dBmV)Channel IDBandwidth
123700000ATDMA - 64QAM38.00056400000
238595785ATDMA - 64QAM40.70063200000
330596000ATDMA - 64QAM37.45046400000
OFDM/OFDMA Overview
Channel IndexStatelin Digital AttDigital AttBW (sc's*fft)Report PowerReport Power1_6FFT Size
0DISABLED0.50000.00000.0000-inf-1.00004K
1DISABLED0.50000.00000.0000-inf-1.00004K

 

Re: CODA-4582 - Open Issues for Investigation

Telek
I plan to stick around

@sdmeller do you have a cable amplifier in your setup? Can you test the situation with the line that comes directly into your residence?

Re: CODA-4582 - Open Issues for Investigation

Mythen
I plan to stick around

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| hitronhub.home - 8 | 79 | 73 | 0 | 0 | 3 | 0 |

| 67.231.222.253 - 0 | 102 | 102 | 6 | 14 | 22 | 11 |
| 69.63.250.201 - 0 | 102 | 102 | 33 | 39 | 52 | 40 |
| 209.148.229.241 - 0 | 102 | 102 | 53 | 61 | 68 | 61 |
| 209.148.229.225 - 0 | 102 | 102 | 60 | 66 | 76 | 67 |
| 209.148.230.14 - 0 | 102 | 102 | 58 | 64 | 88 | 65 |
| No response from host - 100 | 20 | 0 | 0 | 0 | 0 | 0 |
| 209.85.242.109 - 0 | 102 | 102 | 58 | 65 | 120 | 64 |
| 216.239.46.160 - 0 | 102 | 102 | 68 | 85 | 108 | 90 |
| 72.14.232.48 - 0 | 102 | 102 | 69 | 84 | 109 | 72 |
| 108.170.243.193 - 52 | 33 | 16 | 0 | 84 | 88 | 87 |
| 216.239.42.33 - 0 | 102 | 102 | 68 | 80 | 93 | 70 |
| ord38s04-in-f3.1e100.net - 0 | 102 | 102 | 68 | 73 | 83 | 76 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Re: CODA-4582 - Open Issues for Investigation

Mythen
I plan to stick around

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| hitronhub.home - 8 | 82 | 76 | 0 | 0 | 3 | 0 |

| 67.231.222.253 - 0 | 107 | 107 | 6 | 12 | 19 | 10 |
| 69.63.250.201 - 0 | 107 | 107 | 31 | 38 | 49 | 33 |
| 209.148.229.241 - 0 | 106 | 106 | 53 | 59 | 67 | 63 |
| 209.148.229.225 - 0 | 106 | 106 | 56 | 65 | 78 | 69 |
| 209.148.230.14 - 0 | 106 | 106 | 58 | 62 | 101 | 64 |
| No response from host - 100 | 21 | 0 | 0 | 0 | 0 | 0 |
| 209.85.242.109 - 0 | 106 | 106 | 56 | 63 | 110 | 62 |
| 72.14.235.34 - 0 | 106 | 106 | 67 | 83 | 94 | 89 |
| 72.14.237.131 - 0 | 106 | 106 | 68 | 83 | 114 | 83 |
| 108.170.243.193 - 57 | 32 | 14 | 82 | 85 | 90 | 82 |
| 216.239.42.33 - 0 | 106 | 106 | 66 | 78 | 90 | 69 |
| ord38s04-in-f3.1e100.net - 0 | 106 | 106 | 66 | 71 | 79 | 69 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

 

The 1st post was using rogers DNS. this one is using googles DNS.  2nd hop removed.  both to www.google.ca

Re: CODA-4582 - Open Issues for Investigation

JohnBeaudin
I'm a senior contributor

I am trying to setup OpenDNS on my router.. but my devices can't browse, is Rogers forcing default DNS?

 

I tried to update it computer by computer going on ipv4 and ipv6 adapter, but same result can't browse as soon as I change it.

 

Seems like only Rogers DNS is allowed, anyt thought @RogersDave @Datalink @Telek ?

Re: CODA-4582 - Open Issues for Investigation

Telek
I plan to stick around

@JohnBeaudin wrote:

I am trying to setup OpenDNS on my router.. but my devices can't browse, is Rogers forcing default DNS?

 

I tried to update it computer by computer going on ipv4 and ipv6 adapter, but same result can't browse as soon as I change it.

 

Seems like only Rogers DNS is allowed, anyt thought @RogersDave @Datalink @Telek ?


You must be setting it up wrong.  Without changing anything from defaults, use nslookup on your computer, and "server 208.67.222.222" then type in www.google.com.  See what you get.

 

The servers should be 208.67.222.222 and 208.67.220.220.

 

You can also use 8.8.8.8 and 8.8.4.4 for google's DNS. Easier to remember.

 

Re: CODA-4582 - Open Issues for Investigation

JohnBeaudin
I'm a senior contributor

yeah I tried both these OPEN DNS and also google , and both were not working. I will try to lookup.

Re: CODA-4582 - Open Issues for Investigation

JohnBeaudin
I'm a senior contributor

I am not setting up wrong, Iv'e done this often and it always worked , that's why I asked if Rogers changed anything.

Re: CODA-4582 - Open Issues for Investigation

If you're referring to the modem DNS settings, log into the modem, navigate to BASIC .... DNS.  Change the DNS Obtain from Auto (Rogers DNS) to Manual.  When you change to manual, you will see two entry windows displayed below that selection.  The entry windows are DNS1 and DNS2.  Fill those in, save the data and reboot the modem.  

 

The same would apply to a router, although you will have to find the DNS1 and DNS2 equivalents.  Fill those in and reboot the router. 

 

I set the DNS in the ethernet and wifi adapters and haven't had any issues with that. 

 

Just for the heck of it, try pinging the OpenDNS and Google DNS addresses.  If you can see a response, then you should be able to set the same addresses in the modem, router or pc without any issue, although, you probably have to reboot the device after the address has been added. 

Re: CODA-4582 - Open Issues for Investigation

JohnBeaudin
I'm a senior contributor

My bad, I forgot to reboot the modem after the change.. Now it's working.

Re: CODA-4582 - Open Issues for Investigation

JohnBeaudin
I'm a senior contributor

Now funny thing, my ping decreased from 10-12 ms in CSGO after chaning to OpenDns, I know that DNS should not make a difference with the ping but still funny.. went down from 63-65ms to 50-54ms (Chicago Location)

Re: CODA-4582 - Open Issues for Investigation

Telek
I plan to stick around

@JohnBeaudin can you run a tracert before and after the openDNS change to those servers, see what the heck is going on?

Re: CODA-4582 - Open Issues for Investigation

JohnBeaudin
I'm a senior contributor

I will do that when I have a chance later this evening.

Re: CODA-4582 - Open Issues for Investigation

Telek
I plan to stick around

@JohnBeaudin with an nslookup too, or use the -d option on tracert.

Re: CODA-4582 - Open Issues for Investigation

JohnBeaudin
I'm a senior contributor

strange thing route is similar

 

3 18 ms 16 ms 19 ms 69.63.255.113
4 20 ms 24 ms 21 ms 24.156.157.46
5 30 ms 31 ms 22 ms 209.148.229.145
6 51 ms 44 ms 46 ms 209.148.229.241
7 56 ms 53 ms 55 ms 209.148.229.225
8 54 ms 54 ms 47 ms 209.148.232.154
9 64 ms 64 ms 69 ms 69.63.249.26
10 63 ms 64 ms 62 ms eqnx-v4-1.iad.valve.net [206.126.237.32]
11 85 ms 556 ms 83 ms 208.78.164.1

 

so the mystery remain

 

However I ran a tracert from my neighbor on Bell

 

3 7 ms 6 ms 6 ms ae13-184.cr02.mctn.nb.aliant.net [142.166.129.245]
4 19 ms 18 ms 18 ms ae9.bx01.mtrl.pq.aliant.net [207.231.227.126]
5 25 ms 25 ms 25 ms bx2-montreal01_tengige0-1-0-4 [184.150.181.158]
6 35 ms 31 ms 31 ms tcore3-montreal01_bundle-ether1.net.bell.ca [64.230.94.168]
7 31 ms 31 ms 31 ms tcore3-newyorkaa_hundredgige0-3-0-0.net.bell.ca [64.230.79.136]
8 28 ms 28 ms 28 ms bx7-newyork83_hundredgige0-6-0-0.net.bell.ca [64.230.79.89]
9 28 ms 28 ms 27 ms te-0-6-0-20-pe03.111eighthave.ny.ibone.comcast.net [173.167.56.109]
10 30 ms 30 ms 28 ms hu-1-4-0-0-cr02.newyork.ny.ibone.comcast.net [68.86.84.249]
11 29 ms 29 ms 29 ms be-10203-cr01.newark.nj.ibone.comcast.net [68.86.85.185]
12 35 ms 35 ms 35 ms be-10102-cr02.ashburn.va.ibone.comcast.net [68.86.85.161]
13 33 ms 33 ms 33 ms hu-0-11-0-2-pe04.ashburn.va.ibone.comcast.net [68.86.88.58]
14 33 ms 33 ms 33 ms as32590-1-c.ashburn.va.ibone.comcast.net [173.167.56.170]
15 57 ms 56 ms 70 ms 208.78.164.1

 

I have to admit Bell's routing is amazing -_-

Re: CODA-4582 - Open Issues for Investigation

VivienM
I'm an advisor

@Telek wrote:

@Datalink wrote:

@Telek, fwiw, I use OpenDNS and find that my routing to various targets can be reduced by 50% in some cases, thats in the number of servers and ping time to the target.  Doesn't make any sense at all, but that is what I've noticed.  


That is very interesting! I wonder if, in the event where DNS is setup with multiple addresses (as almost all sites are), some DNS servers will geographically prioritize the order of the results?

 

Routing has absolutely nothing to do with DNS, so it must be the way that the results are returned.

 

It would be useful to compare the DNS lookup results of servers which do result in differnet routing.

 

FWIW, I've always used Google's DNS servers.  One of the first things that I change.


CDNs typically play tricks with DNS - indeed, DNS tricks are what enable the magic of CDNs.

 

e.g. if DNS server A asks for the IP for a given hostname, the CDN's DNS will give it 1.2.3.4. If DNS server B asks for the IP for the same hostname, the CDN's DNS will give it 2.3.4.5. Etc.

 

That means that, if the destination is hosted by a CDN that does this, different DNS servers will get different IPs, with resulting totally different routing.

 

If you want to see this in action, try tracerouting to a CDN hostname. I've often used a96.g.akamai.net as an example. From Rogers (running my own DNS) I get:

Tracing route to a96.g.akamai.net [209.148.192.41]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  [192.168.22.1]
  2    28 ms    11 ms    10 ms  99.245.80.1
  3    10 ms     7 ms    15 ms  67.231.221.49
  4    10 ms    26 ms    10 ms  69.63.252.250
  5    24 ms    11 ms     9 ms  209.148.231.6
  6    10 ms    10 ms     3 ms  209.148.192.41

 

C:\Users\Vivien>nslookup a96.g.akamai.net
Server:  [removed]
Address:  192.168.22.1

Non-authoritative answer:
Name:    a96.g.akamai.net
Addresses:  209.148.192.41
          209.148.192.43

 

Run the same thing from a VPS in Toronto, and I get:

vivienm@vps2:~$ traceroute a96.g.akamai.net
traceroute to a96.g.akamai.net (184.84.243.201), 30 hops max, 60 byte packets
 1  69.28.82.2 (69.28.82.2)  0.474 ms  0.446 ms  0.404 ms
 2  unknown.static.tor01.cologlobal.com (69.42.56.234)  1.187 ms  1.222 ms  1.223 ms
 3  69.90.153.138 (69.90.153.138)  6.514 ms  6.468 ms  6.446 ms
 4  10ge.tor-20p1ops-dis-1.peer1.net (216.187.113.66)  0.451 ms  0.442 ms  0.399 ms
 5  10ge.xe-1-1-1.tor-fr709-cor-1.peer1.net (216.187.88.33)  0.903 ms 10ge.xe-11-2-0.tor-fr709-cor-1.peer1.net (216.187.118.242)  1.469 ms 10ge.xe-1-2-1.tor-fr709-cor-1.peer1.net (216.187.115.64)  0.855 ms
 6  akamai.ip4.torontointernetxchange.net (206.108.34.24)  0.905 ms  0.887 ms  1.198 ms
 7  a184-84-243-201.deploy.static.akamaitechnologies.com (184.84.243.201)  0.836 ms  1.069 ms *

 

Go to traceroute.org and run a bunch of traceroutes from random places, and you'll see completely different results. E.g. from Australia:

 1  gigabitethernet3-3.exi2.melbourne.telstra.net (203.50.77.53)  0.291 ms  0.221 ms  0.244 ms
 2  bundle-ether3-100.win-core10.melbourne.telstra.net (203.50.80.129)  1.993 ms  1.486 ms  2.370 ms
 3  bundle-ether12.ken-core10.sydney.telstra.net (203.50.11.122)  12.862 ms  11.982 ms  12.613 ms
 4  bundle-ether1.ken-edge901.sydney.telstra.net (203.50.11.95)  11.863 ms  11.856 ms  11.863 ms
 5  203.50.12.105 (203.50.12.105)  11.988 ms  11.858 ms  11.989 ms
 6  a72-247-223-177.deploy.akamaitechnologies.com (72.247.223.177)  11.488 ms  11.482 ms  11.488 ms

 

 

The key thing to remember with this is that the IP you get is based on your DNS server, not your own IP... (and btw, this is why I would be hesitant to use something like OpenDNS/Google Public DNS because I would expect you'd get CDN results further away)

Re: CODA-4582 - Open Issues for Investigation


@Datalink wrote:

@Telek, yup, absolutely agree, "Routing has absolutely nothing to do with DNS".  But, when I ran Pingplotter or WinMTR with OpenDNS or Rogers DNS, I would see a large reduction in the number of servers and final time to the target when OpenDNS was used, as opposed to using the Rogers DNS.  Makes no sense to me at the moment.


Was the target resolving to the same IP? As explained in greater detail in my other post a few minutes ago, it probably wasn't. Most large web sites these days use CDNs that play DNS tricks...

 

Re: CODA-4582 - Open Issues for Investigation

Telek
I plan to stick around

Very interesting, and yes, that makes perfect sense!

 


VivienM wrote: 

The key thing to remember with this is that the IP you get is based on your DNS server, not your own IP... (and btw, this is why I would be hesitant to use something like OpenDNS/Google Public DNS because I would expect you'd get CDN results further away) 

Right, but I would assume that companies like Google and OpenDNS probably are smart enough to be able to figure out proper geographic DNS lookup to support the most efficient routing.

 

FWIW I've been using Google DNS pretty much since it came out, and can't think of any complaints that I've had.  Mind you, I don't play games.

 

Keep in mind, as well, that for 99% of things, a 15ms latency to a site and a 30ms latency to a site is going to have zero impact on the end user.  As I explained with the streaming post a little bit ago here, I cannot see how that would have any impact on the ability to stream properly.