s...@g...com napisał:

>> Przy okazji ciekawostka, apropos 8.8.8.8, do którego
>> "zewsząd blisko":
>>
>> $ 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=0.757 ms
>> 64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=0.771 ms
>> 64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=0.860 ms
>> 64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=0.780 ms
>>
>> Komputer w Warszawie. Jakby kto nie wiedział, 1.1.1.1
>> to taki młodszy brat 8.8.8.8, poniekąd konkurencyjny.
>
> Zalezy gdzie sie siedzi:
>
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=27.0 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=25.6 ms
> 64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=23.0 ms
[...]
>
> 64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=32.9 ms
> 64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=31.6 ms
> 64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=28.5 ms

Jasne, że zależy -- tego właśnie dotyczy ta budująca uczona dysputa.
Różnica jest taka, że dość stare technologicznie podejście Google'a
stawia na szybkie łącza i minimalizację węzłów pośrednich. Droga
ode mnie do dns.google ma ostatni przystanek w Tokio. Mam tam ping
około 5 ms, co z grubsza odpowiada fizycznemu dystansowi. W nowym
wydaniu jest inaczej -- usługa DNS jest mocno rozproszona po świecie,
a pliki stref są mirrorowane w każdym z tych punktów. Ostatni węzęł
przed one.one.one.one to dla mnie cloudflare.plix.pl, a ten ponad
wszelką wątpliwośc stoi we Warszawie. Lokalna instancja 1.1.1.1
ani chybi jest kilka metrów obok.

--
Jarek