7 ms·

And look at these ping times: CloudFlare Google DNS Quad9 OpenDNS NewYork

And look at these ping times: CloudFlare Google DNS Quad9 OpenDNS NewYork 2 msec 1 msec 2 msec 19 msec Toronto 2 msec 28 msec 17 msec 27 msec Atlanta 1 msec 2 msec 1 msec 19 msec Dallas 1 msec 9 msec 1 msec 7 msec San Francisco 3 msec 21 msec 15 msec 20 msec London 1 msec 12 msec 1 msec 14 msec Amsterdam 2 msec 6 msec 1 msec 6 msec Frankfurt 1 msec 9 msec 2 msec 9 msec Tokyo 2 msec 2 msec 81 msec 77 msec Singapore 2 msec 2 msec 1 msec 189 msec Sydney 1 msec 130 msec 1 msec 165 msec Very impressive CloudFlare.

fipple 8y ago
How is this possible from a single location? The speed of light in a vacuum is ~200 miles per millisecond.
- aftbit 8y ago
  Despite using a single IP, this is not served from a single location. Check out Anycast, wikipedia: https://en.wikipedia.org/wiki/Anycast https://en.wikipedia.org/wiki/Anycast
  - tialaramex 8y ago
    Yup, anycast, this is also why: The "backup" IPv4 address is 1.0.0.1 rather than, say, 1.1.1.2, and why they needed APNIC's help to make this work In theory you can tell other network providers "Hi, we want you to route this single special address 1.1.1.1 to us" and that would work. But in practice most of them have a rule which says "The smallest routes we care about are a /24" and 1.1.1.1 on its own is a /32. So what gets done about that is you need to route the entire /24 to make this work, and although you can put other services in that /24 if you _really_ want, they will all get routed together, including failover routing and other practices. So, it's usually best to "waste" an entire /24 on a single anycast service. Anycast is not exactly a cheap homebrew thing, so a /24 isn't _that_ much to use up.
chrissnell 8y ago
Where are you testing from? I'm going to guess: a datacenter. Residential customers won't see anything this fast. I'm in a small town in Kansas, connected by 1 Gbit ATT fiber. I'm getting ~26ms to 1.1.1.1 and ~19ms to my private DNS resolver that I host in a datacenter in Dallas. Google DNS comes in around 19ms. I suspect that Cloudflare and Google DNS both have POPs in Dallas, which accounts for the similar numbers to my private resolver. My point is, low latencies to datacenter-located resolver clients is great but the advantage is reduced when consumer internet users have to go across their ISP's long private fiber hauls to get to a POP. Once you're at the exchange point, it doesn't really matter which provider you choose. Go with the one with the least censorship, best security, and most privacy. For me, that's the one I run myself. Side note: I wish AT&T was better about peering outside of their major transit POPs and better about building smaller POPs in regional hubs. For me, that would be Kansas City. Tons of big ISPs and content providers peer in KC but AT&T skips them all and appears to backhaul all Kansas traffic to DFW before doing any peering.
- hartator 8y ago
  If you are on ethernet, I am able to get 1-2ms pings. On same AT&T Fiber Gigabit. Wifi ruins both bandwidth and latency for me.
  - cthalupa 8y ago
    You should invest in some better wifi gear, it sounds like! On a Unifi nano hd, with moderate signal, my latency only goes up 1ms. Getting ~3.5 ms on wifi to 1.1.1.1, ~2.5ms ethernet
    - hartator 8y ago
      That's impressive. My AT&T wifi router caps bandwidth at 300mb/s (instead of 1gbs on ethernet) and add 10-20 ms to latency. And this is standing next to it and using 5ghz.
    - fudgy73 8y ago
      Out of curiosity, what is your complete Unifi / network setup?
kentonv 8y ago
Keep in mind that ping time isn't the only factor in DNS lookup speed. For me (sonic.net in Palo Alto): ping 1.1.1.1: ~22ms ping 8.8.8.8: ~19ms dig @1.1.1.1: ~45ms dig @8.8.8.8: ~70ms Disclaimer: Eyeballed averages over a few samples. A more rigorous test of DNS lookup times would be cool to see. Disclosure: I work for Cloudflare, but not on DNS.
- joemag 8y ago
  So logging accounts for 25ms ;)
- mgkimsal 8y ago
  how are you pinging 8.8.8.8? EDIT: nevermind - mistake on my end!
- yborg 8y ago
  I'm guessing Google's resolvers are a little busier than Cloudflare's right now, because pretty much nobody not on HN right now is hitting them. Will be a more interesting comparison in 6 months.
  - kentonv 8y ago
    I'd be surprised if increased load has a negative effect on 1.1.1.1's performance. We run a homogeneous architecture -- that is, every machine in our fleet is capable of handling every type of request. The same machines that currently handle 10% of all HTTP requests on the internet, and handle authoritative DNS for our customers, and serve the DNS F root server, are now handling recursive DNS at 1.1.1.1. These machines are not sitting idle. Moreover, this means that all of these services are drawing from the same pool of resources, which is, obviously, enormous. This service will scale easily to any plausible level of demand. In fact, in this kind of architecture, a little-used service is actually likely to be penalized in terms of performance because it's spread so thin that it loses cache efficiency (for all kinds of caches -- CPU cache, DNS cache, etc.). More load should actually make it faster, as long as there is capacity, and there is a lot of capacity. Meanwhile, Cloudflare is rapidly adding new locations -- 31 new locations in March alone, bringing the current total to 151. This not only adds capacity for running the service, but reduces the distance to the closest service location. In the past I worked at Google. I don't know specifically how their DNS resolver works, but my guess is that it is backed by a small set of dedicated containers scheduled via Borg, since that's how Google does things. To be fair, they have way too many services to run them all on every machine. That said, they're pretty good at scheduling more instances as needed to cover load, so they should be fine too. In all likelihood, what really makes the difference is the design of the storage layer. But I don't know the storage layer details for either Google's or Cloudflare's resolvers so I won't speculate on that.
jpalmer 8y ago
Using namebench[0], CloudFlare is about the 6th fastest for me. Just ahead of google. 1) Level3 2) DynGuide 3) UltraDNS 4) OpenDNS 5) Quad9 6) CloudFlare 7) Google [0] https://code.google.com/archive/p/namebench/ https://code.google.com/archive/p/namebench/
atmosx 8y ago
I live I Greece, Google’s DNS are 20-30% faster.
szatkus 8y ago
Poznań, Poland 1.1.1.1: ~17ms (the first one took 179ms, but after that it's pretty fast) 8.8.8.8: ~16ms
nodesocket 8y ago
Note, from Google Compute Engine use 8.8.8.8 as it should always be faster. I'm guessing the 8.8.8.8 service exists in every Google Cloud region. Even better use the default GCE autogenered DNS IP that they configure in /etc/resolv.conf to get instance name resolving magic.
- kentonv 8y ago
  Usually best to use 169.254.169.254, which is the magic "cloud metadata address" that talks directly to the local hypervisor (I think?). That will recurse to public DNS as necessary. https://cloud.google.com/compute/docs/internal-dns https://cloud.google.com/compute/docs/internal-dns
  - jkaplowitz 8y ago
    I agree that's usually best, but one exception is worth noting: if you want only publicly resolvable results, don't use 169.254.169.254. That address adds convenient predictable hostnames for your project's instances under the .internal TLD. Also, no need to hardcode that address - DHCP will happily serve it up. It also has the hostname metadata.google.internal and the (disfavored for security reasons) bare short hostname metadata.
LogicX 8y ago
Interestingly having routing problems to China for 1.1.1.1 (but not 1.0.0.1): http://ping.pe/1.1.1.1 http://ping.pe/1.1.1.1
aidenn0 8y ago
I assume a cable modem adds at least 8ms of latency, because I get 8ms of latency to my default router, and about 12-15ms to any of those hosts.
YetAnotherNick 8y ago
It looks like you are testing either from centers where cloudflare has servers or exchanging traffic with, which is likely true in a data center given the traffic it transports. What most users want is the ping time from home/office.
mattlondon 8y ago
From London on a residential ADSL connection: 8.8.8.8 - ping 7ms dig 14ms 8.8.4.4 - ping 7ms dig 16ms 1.1.1.1 - ping 7ms dig 16ms 1.0.0.1 - ping 6ms dig 15ms 9.9.9.9 - ping 6ms dig 17ms CF & Google about the same for me. Good to have an alternative in CF though, and certainly a very memorable IP :)
mmsimanga 8y ago
Cape Town, South Africa, Residential ADSL 1.1.1.1 ~ 26ms 8.8.8.8 ~ 42ms
deleted 8y ago
[deleted]
mattparlane 8y ago
Cafe in Chiang Rai, Thailand: $ ping -n 1.1.1.1 round-trip min/avg/max/stddev = 16.696/18.643/22.571/2.056 ms $ ping -n 8.8.8.8 round-trip min/avg/max/stddev = 38.410/45.663/57.684/8.075 ms
bigiain 8y ago
Pretty sure that google time for Sydney is an outlier This is from my residential ADSL2 connection in Sydney: [Bigs-MacBook-Pro-2:~] bigiain% ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=59 time=21.257 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=25.831 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=22.231 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=21.498 ms ^C --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 21.257/22.704/25.831/1.841 ms [Bigs-MacBook-Pro-2:~] bigiain% ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=59 time=22.481 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=38.814 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=19.923 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=19.911 ms ^C --- 1.1.1.1 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 19.911/25.282/38.814/7.882 ms And this is from an ec2 instance is ap-southeast-2: ubuntu@ip-172-31-xx-xx:~$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=2.24 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=2.27 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=2.30 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=2.26 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=2.31 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=2.25 ms ^C --- 8.8.8.8 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5007ms rtt min/avg/max/mdev = 2.244/2.274/2.310/0.066 ms ubuntu@ip-172-31-xx-xx:~$ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=1.03 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=1.05 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=55 time=1.05 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=55 time=1.01 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=55 time=1.07 ms ^C --- 1.1.1.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms rtt min/avg/max/mdev = 1.015/1.046/1.076/0.035 ms
kalleboo 8y ago
I'm in a city in southern Japan (so most of my traffic needs to go to Tokyo first), on a gigabit fiber connection. --- 1.1.1.1 ping statistics --- rtt min/avg/max/mdev = 30.507/32.155/36.020/1.419 ms --- 8.8.8.8 ping statistics --- rtt min/avg/max/mdev = 19.618/21.572/23.009/0.991 ms The traceroutes are inconclusive but they kind of look like Google has a POP in Fukuoka and CloudFlare are only in Tokyo. edit: Namebench was broken for me, but running GRC's DNS Benchmark my ISP's own resolver is the fastest, then comes Google 8.8.8.8, then Level3 4.2.2.[123], then OpenDNS, then NTT, and then finally 1.1.1.1.
rsync 8y ago
"And look at these ping times ..." I would be interested to hear from google (8.8.8.8) how much ping traffic that address gets ... I know that I will quickly ping 8.8.8.8 as a very quick and dirty test of network up ... its just faster to type than any other address I could test with.
deadlocked 8y ago
ICMP round-trip times don't necessarily prove anything - you need to be examing DNS resolution times. Lots of network hardware (i.e., routers, firewalls if they're not outright blocking) de-prioritise ICMP (and other types of network control/testing traffic) and the likelihood is that Google (and other free DNS providers) are throttling the number of ICMP replies that they send. They're not providing an ICMP reply service, they're providing a DNS service. I'd a situation during the week where I'd to tell one of our engineers to stop tracking 8.8.8.8 as an indicator of network availability for this reason.
MaysonL 8y ago
Pasadena, CA 1.1.1.1 continually timed out. 1.0.0.1 succeeded 18 packets transmitted, 18 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 10.178/11.128/12.585/0.576 ms
Akhi1 8y ago
From Hyderabad, India Cloudflare: Reply from 1.0.0.1: bytes=32 time=119ms TTL=56 Reply from 1.0.0.1: bytes=32 time=74ms TTL=56 Reply from 1.0.0.1: bytes=32 time=74ms TTL=56 Reply from 1.0.0.1: bytes=32 time=74ms TTL=56 Reply from 1.0.0.1: bytes=32 time=74ms TTL=56 GoogleDNS: Reply from 8.8.8.8: bytes=32 time=44ms TTL=55 Reply from 8.8.8.8: bytes=32 time=43ms TTL=55 Reply from 8.8.8.8: bytes=32 time=43ms TTL=55 Reply from 8.8.8.8: bytes=32 time=43ms TTL=55 Reply from 8.8.8.8: bytes=32 time=44ms TTL=55
- prab97 8y ago
  From Hyderabad, another ISP Pinging 1.1.1.1 with 32 bytes of data: Reply from 1.1.1.1: bytes=32 time=45ms TTL=53 Reply from 1.1.1.1: bytes=32 time=45ms TTL=53 Reply from 1.1.1.1: bytes=32 time=45ms TTL=53 Reply from 1.1.1.1: bytes=32 time=45ms TTL=53 Ping statistics for 1.1.1.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 45ms, Maximum = 45ms, Average = 45ms Pinging 1.0.0.1 with 32 bytes of data: Reply from 1.0.0.1: bytes=32 time=46ms TTL=54 Reply from 1.0.0.1: bytes=32 time=46ms TTL=54 Reply from 1.0.0.1: bytes=32 time=46ms TTL=54 Reply from 1.0.0.1: bytes=32 time=46ms TTL=54 Ping statistics for 1.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 46ms, Maximum = 46ms, Average = 46ms Pinging 8.8.4.4 with 32 bytes of data: Reply from 8.8.4.4: bytes=32 time=29ms TTL=56 Reply from 8.8.4.4: bytes=32 time=29ms TTL=56 Reply from 8.8.4.4: bytes=32 time=29ms TTL=56 Reply from 8.8.4.4: bytes=32 time=29ms TTL=56 Ping statistics for 8.8.4.4: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 29ms, Maximum = 29ms, Average = 29ms Pinging 8.8.8.8 with 32 bytes of data: Reply from 8.8.8.8: bytes=32 time=21ms TTL=56 Reply from 8.8.8.8: bytes=32 time=21ms TTL=56 Reply from 8.8.8.8: bytes=32 time=21ms TTL=56 Reply from 8.8.8.8: bytes=32 time=21ms TTL=56 Ping statistics for 8.8.8.8: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 21ms, Maximum = 21ms, Average = 21ms Pinging 208.67.220.220 with 32 bytes of data: Reply from 208.67.220.220: bytes=32 time=45ms TTL=54 Reply from 208.67.220.220: bytes=32 time=46ms TTL=54 Reply from 208.67.220.220: bytes=32 time=45ms TTL=54 Reply from 208.67.220.220: bytes=32 time=50ms TTL=54 Ping statistics for 208.67.220.220: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 45ms, Maximum = 50ms, Average = 46ms Pinging 208.67.222.222 with 32 bytes of data: Reply from 208.67.222.222: bytes=32 time=61ms TTL=54 Reply from 208.67.222.222: bytes=32 time=61ms TTL=54 Reply from 208.67.222.222: bytes=32 time=61ms TTL=54 Reply from 208.67.222.222: bytes=32 time=61ms TTL=54 Ping statistics for 208.67.222.222: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 61ms, Maximum = 61ms, Average = 61ms

fipple 8y ago

How is this possible from a single location? The speed of light in a vacuum is ~200 miles per millisecond.

aftbit 8y ago
Despite using a single IP, this is not served from a single location. Check out Anycast, wikipedia: https://en.wikipedia.org/wiki/Anycast https://en.wikipedia.org/wiki/Anycast
- tialaramex 8y ago
  Yup, anycast, this is also why: The "backup" IPv4 address is 1.0.0.1 rather than, say, 1.1.1.2, and why they needed APNIC's help to make this work In theory you can tell other network providers "Hi, we want you to route this single special address 1.1.1.1 to us" and that would work. But in practice most of them have a rule which says "The smallest routes we care about are a /24" and 1.1.1.1 on its own is a /32. So what gets done about that is you need to route the entire /24 to make this work, and although you can put other services in that /24 if you _really_ want, they will all get routed together, including failover routing and other practices. So, it's usually best to "waste" an entire /24 on a single anycast service. Anycast is not exactly a cheap homebrew thing, so a /24 isn't _that_ much to use up.

chrissnell 8y ago

Where are you testing from? I'm going to guess: a datacenter. Residential customers won't see anything this fast. I'm in a small town in Kansas, connected by 1 Gbit ATT fiber. I'm getting ~26ms to 1.1.1.1 and ~19ms to my private DNS resolver that I host in a datacenter in Dallas. Google DNS comes in around 19ms. I suspect that Cloudflare and Google DNS both have POPs in Dallas, which accounts for the similar numbers to my private resolver. My point is, low latencies to datacenter-located resolver clients is great but the advantage is reduced when consumer internet users have to go across their ISP's long private fiber hauls to get to a POP. Once you're at the exchange point, it doesn't really matter which provider you choose. Go with the one with the least censorship, best security, and most privacy. For me, that's the one I run myself. Side note: I wish AT&T was better about peering outside of their major transit POPs and better about building smaller POPs in regional hubs. For me, that would be Kansas City. Tons of big ISPs and content providers peer in KC but AT&T skips them all and appears to backhaul all Kansas traffic to DFW before doing any peering.

hartator 8y ago
If you are on ethernet, I am able to get 1-2ms pings. On same AT&T Fiber Gigabit. Wifi ruins both bandwidth and latency for me.
- cthalupa 8y ago
  You should invest in some better wifi gear, it sounds like! On a Unifi nano hd, with moderate signal, my latency only goes up 1ms. Getting ~3.5 ms on wifi to 1.1.1.1, ~2.5ms ethernet
  - hartator 8y ago
    That's impressive. My AT&T wifi router caps bandwidth at 300mb/s (instead of 1gbs on ethernet) and add 10-20 ms to latency. And this is standing next to it and using 5ghz.
  - fudgy73 8y ago
    Out of curiosity, what is your complete Unifi / network setup?

kentonv 8y ago

Keep in mind that ping time isn't the only factor in DNS lookup speed. For me (sonic.net in Palo Alto): ping 1.1.1.1: ~22ms ping 8.8.8.8: ~19ms dig @1.1.1.1: ~45ms dig @8.8.8.8: ~70ms Disclaimer: Eyeballed averages over a few samples. A more rigorous test of DNS lookup times would be cool to see. Disclosure: I work for Cloudflare, but not on DNS.

joemag 8y ago
So logging accounts for 25ms ;)
mgkimsal 8y ago
how are you pinging 8.8.8.8? EDIT: nevermind - mistake on my end!
yborg 8y ago
I'm guessing Google's resolvers are a little busier than Cloudflare's right now, because pretty much nobody not on HN right now is hitting them. Will be a more interesting comparison in 6 months.
- kentonv 8y ago
  I'd be surprised if increased load has a negative effect on 1.1.1.1's performance. We run a homogeneous architecture -- that is, every machine in our fleet is capable of handling every type of request. The same machines that currently handle 10% of all HTTP requests on the internet, and handle authoritative DNS for our customers, and serve the DNS F root server, are now handling recursive DNS at 1.1.1.1. These machines are not sitting idle. Moreover, this means that all of these services are drawing from the same pool of resources, which is, obviously, enormous. This service will scale easily to any plausible level of demand. In fact, in this kind of architecture, a little-used service is actually likely to be penalized in terms of performance because it's spread so thin that it loses cache efficiency (for all kinds of caches -- CPU cache, DNS cache, etc.). More load should actually make it faster, as long as there is capacity, and there is a lot of capacity. Meanwhile, Cloudflare is rapidly adding new locations -- 31 new locations in March alone, bringing the current total to 151. This not only adds capacity for running the service, but reduces the distance to the closest service location. In the past I worked at Google. I don't know specifically how their DNS resolver works, but my guess is that it is backed by a small set of dedicated containers scheduled via Borg, since that's how Google does things. To be fair, they have way too many services to run them all on every machine. That said, they're pretty good at scheduling more instances as needed to cover load, so they should be fine too. In all likelihood, what really makes the difference is the design of the storage layer. But I don't know the storage layer details for either Google's or Cloudflare's resolvers so I won't speculate on that.

jpalmer 8y ago

Using namebench[0], CloudFlare is about the 6th fastest for me. Just ahead of google. 1) Level3 2) DynGuide 3) UltraDNS 4) OpenDNS 5) Quad9 6) CloudFlare 7) Google [0] https://code.google.com/archive/p/namebench/ https://code.google.com/archive/p/namebench/

atmosx 8y ago

I live I Greece, Google’s DNS are 20-30% faster.

szatkus 8y ago

Poznań, Poland 1.1.1.1: ~17ms (the first one took 179ms, but after that it's pretty fast) 8.8.8.8: ~16ms

nodesocket 8y ago

Note, from Google Compute Engine use 8.8.8.8 as it should always be faster. I'm guessing the 8.8.8.8 service exists in every Google Cloud region. Even better use the default GCE autogenered DNS IP that they configure in /etc/resolv.conf to get instance name resolving magic.

kentonv 8y ago
Usually best to use 169.254.169.254, which is the magic "cloud metadata address" that talks directly to the local hypervisor (I think?). That will recurse to public DNS as necessary. https://cloud.google.com/compute/docs/internal-dns https://cloud.google.com/compute/docs/internal-dns
- jkaplowitz 8y ago
  I agree that's usually best, but one exception is worth noting: if you want only publicly resolvable results, don't use 169.254.169.254. That address adds convenient predictable hostnames for your project's instances under the .internal TLD. Also, no need to hardcode that address - DHCP will happily serve it up. It also has the hostname metadata.google.internal and the (disfavored for security reasons) bare short hostname metadata.

LogicX 8y ago

Interestingly having routing problems to China for 1.1.1.1 (but not 1.0.0.1): http://ping.pe/1.1.1.1 http://ping.pe/1.1.1.1

aidenn0 8y ago

I assume a cable modem adds at least 8ms of latency, because I get 8ms of latency to my default router, and about 12-15ms to any of those hosts.

YetAnotherNick 8y ago

It looks like you are testing either from centers where cloudflare has servers or exchanging traffic with, which is likely true in a data center given the traffic it transports. What most users want is the ping time from home/office.

mattlondon 8y ago

From London on a residential ADSL connection: 8.8.8.8 - ping 7ms dig 14ms 8.8.4.4 - ping 7ms dig 16ms 1.1.1.1 - ping 7ms dig 16ms 1.0.0.1 - ping 6ms dig 15ms 9.9.9.9 - ping 6ms dig 17ms CF & Google about the same for me. Good to have an alternative in CF though, and certainly a very memorable IP :)

mmsimanga 8y ago

Cape Town, South Africa, Residential ADSL 1.1.1.1 ~ 26ms 8.8.8.8 ~ 42ms

deleted 8y ago

[deleted]

mattparlane 8y ago

Cafe in Chiang Rai, Thailand: $ ping -n 1.1.1.1 round-trip min/avg/max/stddev = 16.696/18.643/22.571/2.056 ms $ ping -n 8.8.8.8 round-trip min/avg/max/stddev = 38.410/45.663/57.684/8.075 ms

bigiain 8y ago

Pretty sure that google time for Sydney is an outlier This is from my residential ADSL2 connection in Sydney: [Bigs-MacBook-Pro-2:~] bigiain% ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=59 time=21.257 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=25.831 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=22.231 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=21.498 ms ^C --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 21.257/22.704/25.831/1.841 ms [Bigs-MacBook-Pro-2:~] bigiain% ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=59 time=22.481 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=38.814 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=19.923 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=19.911 ms ^C --- 1.1.1.1 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 19.911/25.282/38.814/7.882 ms And this is from an ec2 instance is ap-southeast-2: ubuntu@ip-172-31-xx-xx:~$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=2.24 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=2.27 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=2.30 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=2.26 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=2.31 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=2.25 ms ^C --- 8.8.8.8 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5007ms rtt min/avg/max/mdev = 2.244/2.274/2.310/0.066 ms ubuntu@ip-172-31-xx-xx:~$ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=1.03 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=1.05 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=55 time=1.05 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=55 time=1.01 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=55 time=1.07 ms ^C --- 1.1.1.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms rtt min/avg/max/mdev = 1.015/1.046/1.076/0.035 ms

kalleboo 8y ago

I'm in a city in southern Japan (so most of my traffic needs to go to Tokyo first), on a gigabit fiber connection. --- 1.1.1.1 ping statistics --- rtt min/avg/max/mdev = 30.507/32.155/36.020/1.419 ms --- 8.8.8.8 ping statistics --- rtt min/avg/max/mdev = 19.618/21.572/23.009/0.991 ms The traceroutes are inconclusive but they kind of look like Google has a POP in Fukuoka and CloudFlare are only in Tokyo. edit: Namebench was broken for me, but running GRC's DNS Benchmark my ISP's own resolver is the fastest, then comes Google 8.8.8.8, then Level3 4.2.2.[123], then OpenDNS, then NTT, and then finally 1.1.1.1.

rsync 8y ago

"And look at these ping times ..." I would be interested to hear from google (8.8.8.8) how much ping traffic that address gets ... I know that I will quickly ping 8.8.8.8 as a very quick and dirty test of network up ... its just faster to type than any other address I could test with.

deadlocked 8y ago

ICMP round-trip times don't necessarily prove anything - you need to be examing DNS resolution times. Lots of network hardware (i.e., routers, firewalls if they're not outright blocking) de-prioritise ICMP (and other types of network control/testing traffic) and the likelihood is that Google (and other free DNS providers) are throttling the number of ICMP replies that they send. They're not providing an ICMP reply service, they're providing a DNS service. I'd a situation during the week where I'd to tell one of our engineers to stop tracking 8.8.8.8 as an indicator of network availability for this reason.

MaysonL 8y ago

Pasadena, CA 1.1.1.1 continually timed out. 1.0.0.1 succeeded 18 packets transmitted, 18 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 10.178/11.128/12.585/0.576 ms

Akhi1 8y ago

From Hyderabad, India Cloudflare: Reply from 1.0.0.1: bytes=32 time=119ms TTL=56 Reply from 1.0.0.1: bytes=32 time=74ms TTL=56 Reply from 1.0.0.1: bytes=32 time=74ms TTL=56 Reply from 1.0.0.1: bytes=32 time=74ms TTL=56 Reply from 1.0.0.1: bytes=32 time=74ms TTL=56 GoogleDNS: Reply from 8.8.8.8: bytes=32 time=44ms TTL=55 Reply from 8.8.8.8: bytes=32 time=43ms TTL=55 Reply from 8.8.8.8: bytes=32 time=43ms TTL=55 Reply from 8.8.8.8: bytes=32 time=43ms TTL=55 Reply from 8.8.8.8: bytes=32 time=44ms TTL=55

prab97 8y ago
From Hyderabad, another ISP Pinging 1.1.1.1 with 32 bytes of data: Reply from 1.1.1.1: bytes=32 time=45ms TTL=53 Reply from 1.1.1.1: bytes=32 time=45ms TTL=53 Reply from 1.1.1.1: bytes=32 time=45ms TTL=53 Reply from 1.1.1.1: bytes=32 time=45ms TTL=53 Ping statistics for 1.1.1.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 45ms, Maximum = 45ms, Average = 45ms Pinging 1.0.0.1 with 32 bytes of data: Reply from 1.0.0.1: bytes=32 time=46ms TTL=54 Reply from 1.0.0.1: bytes=32 time=46ms TTL=54 Reply from 1.0.0.1: bytes=32 time=46ms TTL=54 Reply from 1.0.0.1: bytes=32 time=46ms TTL=54 Ping statistics for 1.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 46ms, Maximum = 46ms, Average = 46ms Pinging 8.8.4.4 with 32 bytes of data: Reply from 8.8.4.4: bytes=32 time=29ms TTL=56 Reply from 8.8.4.4: bytes=32 time=29ms TTL=56 Reply from 8.8.4.4: bytes=32 time=29ms TTL=56 Reply from 8.8.4.4: bytes=32 time=29ms TTL=56 Ping statistics for 8.8.4.4: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 29ms, Maximum = 29ms, Average = 29ms Pinging 8.8.8.8 with 32 bytes of data: Reply from 8.8.8.8: bytes=32 time=21ms TTL=56 Reply from 8.8.8.8: bytes=32 time=21ms TTL=56 Reply from 8.8.8.8: bytes=32 time=21ms TTL=56 Reply from 8.8.8.8: bytes=32 time=21ms TTL=56 Ping statistics for 8.8.8.8: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 21ms, Maximum = 21ms, Average = 21ms Pinging 208.67.220.220 with 32 bytes of data: Reply from 208.67.220.220: bytes=32 time=45ms TTL=54 Reply from 208.67.220.220: bytes=32 time=46ms TTL=54 Reply from 208.67.220.220: bytes=32 time=45ms TTL=54 Reply from 208.67.220.220: bytes=32 time=50ms TTL=54 Ping statistics for 208.67.220.220: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 45ms, Maximum = 50ms, Average = 46ms Pinging 208.67.222.222 with 32 bytes of data: Reply from 208.67.222.222: bytes=32 time=61ms TTL=54 Reply from 208.67.222.222: bytes=32 time=61ms TTL=54 Reply from 208.67.222.222: bytes=32 time=61ms TTL=54 Reply from 208.67.222.222: bytes=32 time=61ms TTL=54 Ping statistics for 208.67.222.222: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 61ms, Maximum = 61ms, Average = 61ms