6 ms·
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
by chrissnell 9y 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 9y agoIf 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 9y agoYou 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 9y agoThat'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 9y agoOut of curiosity, what is your complete Unifi / network setup?
- cthalupa 9y agoGW/Firewall: USG-XG Switches: 2x US-16-XG, 1x US-48, 2x US-8 APs: 2x Nano HD, 2x AC Pro
- snuxoll 9y agoMan, wish I could ever get pings this low - the link from my VDSL2 model to the local CenturyLink CO alone is 8-15ms depending on the day. Sucks that VDSL2 no longer supports fastpath, not that I could use it on an ADSL line due to bonding anyway :/
- chrissnell 9y agoI'm on Ethernet and fiber all the way. This may have to do more with how AT&T has constructed their fiber in this region. Where do you live? https://chrissnell.com/hn/traceroute-1.1.1.1.png https://chrissnell.com/hn/traceroute-1.1.1.1.png
- nodesocket 9y agoAT&T Fiber Gigabit in Nashville TN. iMac ~ 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=64 time=0.688 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.814 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=1.153 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=0.752 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=0.755 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=64 time=0.789 ms 64 bytes from 1.1.1.1: icmp_seq=6 ttl=64 time=0.876 ms 64 bytes from 1.1.1.1: icmp_seq=7 ttl=64 time=0.869 ms 64 bytes from 1.1.1.1: icmp_seq=8 ttl=64 time=0.830 ms 64 bytes from 1.1.1.1: icmp_seq=9 ttl=64 time=1.387 ms --- 1.1.1.1 ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.688/0.891/1.387/0.204 ms Pinging 8.8.8.8 averages 8ms. CloudFlare must have a POP here in Nashville?
- chrissnell 9y agoGiven that they're a CDN, I would expect them to. I'm jealous that BNA has AT&T peering but Kansas City has minimal/no peering.
- mxpxrocks10 9y agohaha, I knew that was you when I read Nashville, nodesocket
- dragonwriter 9y agoThat's probably because AT&T is using 1.1.1.1 for something internal and breaking the public internet for it's users: you get a really fast ping on 1.1.1.1, but it's not the 1.1.1.1 you are trying to reach.
- nodesocket 9y agoIs this just speculation or can anybody confirm? traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets 1 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 1.117 ms 0.710 ms 0.727 ms
- deleted 9y ago
- PeterStuer 9y agoSmall village next to a provincial town in Europe on Cable: getting 11ms avg.
- robarr 9y agofrom Lima, Peru PING 1.0.0.1: 64 data bytes --- 1.0.0.1 ping statistics --- 14 packets transmitted, 14 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 120.784/126.222/128.433/2.036 ms 1.1.1.1 timed out, must be blocked by my iso.
- markbnj 9y agoComcast in Northern NJ USA about 45 MI from NYC $ 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=56 time=10.8 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=11.3 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=10.7 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=10.9 ms 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=60 time=10.7 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=11.3 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=60 time=11.1 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=60 time=10.5 ms
- Nition 9y agoFrom a residential connection in New Zealand: $ ping 1.1.1.1 Pinging 1.1.1.1 with 32 bytes of data: Reply from 1.1.1.1: bytes=32 time=4ms TTL=60 Reply from 1.1.1.1: bytes=32 time=4ms TTL=60 Reply from 1.1.1.1: bytes=32 time=4ms TTL=60 Reply from 1.1.1.1: bytes=32 time=4ms TTL=60 $ ping 8.8.8.8 Pinging 8.8.8.8 with 32 bytes of data: Reply from 8.8.8.8: bytes=32 time=27ms TTL=60 Reply from 8.8.8.8: bytes=32 time=27ms TTL=60 Reply from 8.8.8.8: bytes=32 time=27ms TTL=60 Reply from 8.8.8.8: bytes=32 time=28ms TTL=60 Seems that 1.1.1.1 is even faster than my local ISP's primary DNS: $ ping 202.180.64.10 Pinging 202.180.64.10 with 32 bytes of data: Reply from 202.180.64.10: bytes=32 time=11ms TTL=61 Reply from 202.180.64.10: bytes=32 time=11ms TTL=61 Reply from 202.180.64.10: bytes=32 time=11ms TTL=61 Reply from 202.180.64.10: bytes=32 time=11ms TTL=61
- RantyDave 9y agoFour! I'm getting 14 from fibre in Wellington. Google are 35 ish.
- lancewiggs 9y agoResidential in Auckland, NZ (Vibe, UFB) 64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=0.966 ms Outstanding. 64 bytes from 8.8.8.8: icmp_seq=0 ttl=59 time=25.478 ms Not so great.
- spludge 9y agoFastest Bigpipe residential connection available in the middle of Auckland: $ ping -c 4 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=56 time=29.0 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=27.7 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=30.5 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=28.6 ms --- 1.1.1.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 27.731/28.993/30.573/1.028 ms $ ping -c 4 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=27.7 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=30.7 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=28.5 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=30.6 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 27.772/29.409/30.710/1.280 ms I'm starting to feel I should change ISPs...
- magoghm 9y agoI'm in Mexico: 1.1.1.1 60 ms 8.8.8.8 20 ms
- sesutton 9y agoI think AT&T's fiber modems are using 1.1.1.1. I'm getting < 1ms ping times and according to Cloudflare's website there's no data center close enough to me for that to be possible without violating the speed of light.
- f2n 9y agowhat happens if you go to https://1.1.1.1 https://1.1.1.1 in a browser? It should have a valid TLS cert and have a big banner that says, among other things, "Introducing 1.1.1.1". If your ISP's CPE or anything else is fucking with traffic to that IP, it wont load/display that
- sesutton 9y agoI just get connection refused.
- f2n 9y agoCall your ISP and ask them why they're blocking access to some websites. Ask them if there are any other websites they're blocking. Tweet about it. Etc
- dubya 9y agoI'm getting this on Comcast in Knoxville. https://1.0.0.1 https://1.0.0.1 works fine, and https://1.1.1.1 https://1.1.1.1 works on my phone if I turn off wifi.
- asd 9y agoHere's what I'm seeing. https://i.imgur.com/piisG5D.jpg https://i.imgur.com/piisG5D.jpg
- matthberg 9y agoPing from University of Rochester, over wifi: Cloudflare: 64 bytes from 1.1.1.1: icmp_seq=0 ttl=128 time=2 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=128 time=2 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=128 time=2 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=128 time=9 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=128 time=2 ms Google: 64 bytes from 8.8.8.8: icmp_seq=0 ttl=54 time=12 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=11 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=13 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=45 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=14 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=54 time=11 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=54 time=34 ms Quad9: 64 bytes from 9.9.9.9: icmp_seq=0 ttl=53 time=10 ms 64 bytes from 9.9.9.9: icmp_seq=1 ttl=53 time=69 ms 64 bytes from 9.9.9.9: icmp_seq=2 ttl=53 time=14 ms 64 bytes from 9.9.9.9: icmp_seq=3 ttl=53 time=58 ms 64 bytes from 9.9.9.9: icmp_seq=4 ttl=53 time=52 ms One thing I noticed is that when I first pinged 1.1.1.1 I got 14ms, which then quickly dropped to ~3ms consistently: 64 bytes from 1.1.1.1: icmp_seq=0 ttl=128 time=14 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=128 time=14 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=128 time=2 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=128 time=3 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=128 time=1 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=128 time=4 ms
- Tree1993 9y agoBeijing: PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=52 time=241.529 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=52 time=318.034 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=52 time=337.291 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=52 time=255.748 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=52 time=247.765 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=52 time=235.611 ms 64 bytes from 1.1.1.1: icmp_seq=6 ttl=52 time=239.427 ms 64 bytes from 1.1.1.1: icmp_seq=7 ttl=52 time=247.911 ms 64 bytes from 1.1.1.1: icmp_seq=8 ttl=52 time=260.911 ms 64 bytes from 1.1.1.1: icmp_seq=9 ttl=52 time=281.153 ms 64 bytes from 1.1.1.1: icmp_seq=10 ttl=52 time=300.363 ms 64 bytes from 1.1.1.1: icmp_seq=11 ttl=52 time=234.296 ms
- bgdkbtv 9y agoAustralia :( 64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=17.580 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=18.025 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=17.780 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=18.231 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=17.906 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=18.447 ms
- alwillis 9y agoI’m getting similar ping times from my Digital Ocean droplet in one of their NYC data centers where my website is hosted: PING 1.1.1.1 (1.1.1.1): 56 data bytes --- 1.1.1.1 ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.335/1.431/1.517/0.053 ms
- deathanatos 9y ago> Residential customers won't see anything this fast. The standard Comcast black-box router/modem I have has a mean ping of ~9ms, and a min of ~3ms, so yeah, I'd have to agree. (I get ~28ms to 1.1.1.1.)
- luochen1990 9y agoHangZhou: Pinging 1.1.1.1 with 32 bytes of data: Reply from 1.1.1.1: bytes=32 time=1ms TTL=128 Reply from 1.1.1.1: bytes=32 time=1ms TTL=128 Reply from 1.1.1.1: bytes=32 time=1ms TTL=128 Reply from 1.1.1.1: bytes=32 time=2ms TTL=128 Pinging 8.8.8.8 with 32 bytes of data: Reply from 8.8.8.8: bytes=32 time=91ms TTL=37 Request timed out. Reply from 8.8.8.8: bytes=32 time=66ms TTL=37 Request timed out. Pinging 1.0.0.1 with 32 bytes of data: Reply from 1.0.0.1: bytes=32 time=146ms TTL=50 Reply from 1.0.0.1: bytes=32 time=144ms TTL=50 Reply from 1.0.0.1: bytes=32 time=142ms TTL=50 Reply from 1.0.0.1: bytes=32 time=140ms TTL=50