01-05-2017 11:03 AM - edited 05-02-2017 07:09 AM
*** 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.
Dave
*Edited Labels*
04-25-2017 02:29 PM
@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.
04-25-2017 02:46 PM
04-25-2017 02:56 PM
04-25-2017 03:06 PM
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:
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Signal noise ratio (dB) |
1 | 615000000 | 256QAM | 4.400 | 11 | 37.636 |
2 | 561000000 | 256QAM | 3.900 | 2 | 37.636 |
3 | 567000000 | 256QAM | 4.900 | 3 | 38.983 |
4 | 573000000 | 256QAM | 5.500 | 4 | 38.605 |
5 | 579000000 | 256QAM | 5.200 | 5 | 38.983 |
6 | 585000000 | 256QAM | 5.700 | 6 | 38.983 |
7 | 591000000 | 256QAM | 5.400 | 7 | 38.983 |
8 | 597000000 | 256QAM | 5.100 | 8 | 38.605 |
9 | 603000000 | 256QAM | 5.100 | 9 | 38.605 |
10 | 609000000 | 256QAM | 4.700 | 10 | 38.605 |
11 | 555000000 | 256QAM | 3.800 | 1 | 38.605 |
12 | 621000000 | 256QAM | 4.600 | 12 | 38.605 |
13 | 633000000 | 256QAM | 5.100 | 13 | 37.636 |
14 | 639000000 | 256QAM | 5.100 | 14 | 37.356 |
15 | 645000000 | 256QAM | 5.300 | 15 | 37.636 |
16 | 651000000 | 256QAM | 5.500 | 16 | 37.636 |
17 | 657000000 | 256QAM | 6.000 | 17 | 37.636 |
18 | 663000000 | 256QAM | 6.200 | 18 | 38.605 |
19 | 669000000 | 256QAM | 6.500 | 19 | 37.636 |
20 | 675000000 | 256QAM | 6.600 | 20 | 38.605 |
21 | 681000000 | 256QAM | 6.300 | 21 | 37.636 |
22 | 687000000 | 256QAM | 6.500 | 22 | 37.636 |
23 | 693000000 | 256QAM | 5.700 | 23 | 37.356 |
24 | 699000000 | 256QAM | 6.300 | 24 | 37.636 |
25 | 705000000 | 256QAM | 5.400 | 25 | 37.636 |
26 | 711000000 | 256QAM | 5.000 | 26 | 37.636 |
27 | 717000000 | 256QAM | 5.600 | 27 | 37.356 |
28 | 723000000 | 256QAM | 5.500 | 28 | 37.636 |
29 | 825000000 | 256QAM | 7.800 | 29 | 35.780 |
30 | 831000000 | 256QAM | 7.700 | 30 | 35.595 |
31 | 837000000 | 256QAM | 7.900 | 31 | 36.387 |
32 | 843000000 | 256QAM | 7.700 | 32 | 36.610 |
Receiver | FFT type | Subcarr 0 Frequency(MHz) | PLC locked | NCP locked | MDC1 locked | PLC power(dBmv) |
0 | NA | NA | NO | NO | NO | NA |
1 | 4K | 275600000 | YES | YES | YES | 3.200001 |
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Bandwidth |
1 | 23700000 | ATDMA - 64QAM | 38.000 | 5 | 6400000 |
2 | 38595785 | ATDMA - 64QAM | 40.700 | 6 | 3200000 |
3 | 30596000 | ATDMA - 64QAM | 37.450 | 4 | 6400000 |
Channel Index | State | lin Digital Att | Digital Att | BW (sc's*fft) | Report Power | Report Power1_6 | FFT Size |
0 | DISABLED | 0.5000 | 0.0000 | 0.0000 | -inf | -1.0000 | 4K |
1 | DISABLED | 0.5000 | 0.0000 | 0.0000 | -inf | -1.0000 | 4K |
04-25-2017 03:23 PM
@sdmeller do you have a cable amplifier in your setup? Can you test the situation with the line that comes directly into your residence?
04-25-2017 04:16 PM
|------------------------------------------------------------------------------------------|
| 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
04-25-2017 04:24 PM - edited 04-25-2017 04:24 PM
|------------------------------------------------------------------------------------------|
| 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
04-25-2017 04:51 PM
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 ?
04-25-2017 04:54 PM - edited 04-25-2017 04:55 PM
@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.
04-25-2017 04:56 PM
yeah I tried both these OPEN DNS and also google , and both were not working. I will try to lookup.
04-25-2017 04:58 PM
I am not setting up wrong, Iv'e done this often and it always worked , that's why I asked if Rogers changed anything.
04-25-2017 05:00 PM - edited 04-25-2017 05:03 PM
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.
04-25-2017 05:07 PM
My bad, I forgot to reboot the modem after the change.. Now it's working.
04-25-2017 05:15 PM
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)
04-25-2017 05:17 PM
@JohnBeaudin can you run a tracert before and after the openDNS change to those servers, see what the heck is going on?
04-25-2017 05:19 PM
I will do that when I have a chance later this evening.
04-25-2017 05:20 PM
@JohnBeaudin with an nslookup too, or use the -d option on tracert.
04-25-2017 05:27 PM
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 -_-
04-25-2017 06:33 PM
@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)
04-25-2017 06:40 PM
@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...
04-26-2017 11:03 AM - edited 04-26-2017 11:04 AM
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.