[ aLtipar @ 13.09.2009. 05:21 ] @
Pozdrav svima,

trenutno radim na poredjenju vremena kasnjenja prilikom prenosa podataka (eng. Latency) kod razlicitih broadband tehnologija - ISDN, ADSL, ADSL2+, Wi-Fi, WiMAX, 3G (EDGE, WCDMA, HSDPA), kablovska i satelitska konekcija, itd...

Ko ima vremena i zeli da pomogne u ovom istrazivanju, neka u command promptu ukuca "ping www.google.com", a zatim neka ovde postavi svoje rezultate, uz obavezno navodjenje tipa tehnologije, brzine paketa i naziva Internet provajdera.

Hvala svima koji budu hteli da izdvoje minut vremena...
[ Sleepless_mind @ 13.09.2009. 06:37 ] @
Provider: KBCnet
Paket: Basic+4096
Tehnologija: Wi-Fi 5GHz

Resultati:
Code:
Pinging www.l.google.com [74.125.39.147] with 32 bytes of data:
Reply from 74.125.39.147: bytes=32 time=40ms TTL=239
Reply from 74.125.39.147: bytes=32 time=42ms TTL=239
Reply from 74.125.39.147: bytes=32 time=41ms TTL=239
Reply from 74.125.39.147: bytes=32 time=41ms TTL=239

Ping statistics for 74.125.39.147:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 40ms, Maximum = 42ms, Average = 41ms


Code:
Pinging www.l.google.com [74.125.39.105] with 32 bytes of data:
Reply from 74.125.39.105: bytes=32 time=39ms TTL=48
Reply from 74.125.39.105: bytes=32 time=41ms TTL=48
Reply from 74.125.39.105: bytes=32 time=37ms TTL=48
Reply from 74.125.39.105: bytes=32 time=39ms TTL=48

Ping statistics for 74.125.39.105:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 37ms, Maximum = 41ms, Average = 39ms
[ Jbyn4e @ 13.09.2009. 07:14 ] @
KOd mene priblizno isto. Isto KBCnet, wireless 5GHz, custom paket upload soho 4096, linux masina, vreme oko 8h, 13.09.2009.:
Code:

# ping -c 4 www.google.com
PING www.l.google.com (74.125.39.104) 56(84) bytes of data.
64 bytes from fx-in-f104.google.com (74.125.39.104): icmp_seq=1 ttl=48 time=30.6 ms
64 bytes from fx-in-f104.google.com (74.125.39.104): icmp_seq=2 ttl=48 time=31.7 ms
64 bytes from fx-in-f104.google.com (74.125.39.104): icmp_seq=3 ttl=48 time=29.3 ms
64 bytes from fx-in-f104.google.com (74.125.39.104): icmp_seq=4 ttl=48 time=31.3 ms

--- www.l.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3011ms
rtt min/avg/max/mdev = 29.323/30.774/31.756/0.935 ms



PTT adsl 2048, linux:
Code:

 ping -c 4 www.google.com
PING www.l.google.com (74.125.39.99) 56(84) bytes of data.
64 bytes from fx-in-f99.google.com (74.125.39.99): icmp_seq=1 ttl=52 time=39.6 ms
64 bytes from fx-in-f99.google.com (74.125.39.99): icmp_seq=2 ttl=52 time=38.9 ms
64 bytes from fx-in-f99.google.com (74.125.39.99): icmp_seq=3 ttl=52 time=39.2 ms
64 bytes from fx-in-f99.google.com (74.125.39.99): icmp_seq=4 ttl=52 time=39.7 ms

--- www.l.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3011ms
rtt min/avg/max/mdev = 37.395/40.950/48.200/4.384 ms


PTT adsl 4096, linux:
Code:

 ping -c 4 www.google.com
PING www.l.google.com (74.125.39.147) 56(84) bytes of data.
64 bytes from fx-in-f147.google.com (74.125.39.147): icmp_seq=1 ttl=243 time=37.9 ms
64 bytes from fx-in-f147.google.com (74.125.39.147): icmp_seq=2 ttl=243 time=38.5 ms
64 bytes from fx-in-f147.google.com (74.125.39.147): icmp_seq=3 ttl=243 time=36.3 ms
64 bytes from fx-in-f147.google.com (74.125.39.147): icmp_seq=4 ttl=243 time=36.0 ms

--- www.l.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 36.036/37.228/38.560/1.083 ms


PTT adsl 1024, windows 7, ova masina sa koje pisem:
Code:

 ping www.google.com
Pinging www.l.google.com [74.125.43.106] with 32 bytes of data:
Reply from 74.125.43.106: bytes=32 time=73ms TTL=51
Reply from 74.125.43.106: bytes=32 time=72ms TTL=51
Reply from 74.125.43.106: bytes=32 time=73ms TTL=51
Reply from 74.125.43.106: bytes=32 time=75ms TTL=51

Ping statistics for 74.125.43.106:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 72ms, Maximum = 75ms, Average = 73ms


Mislim da je poslednji rezultat losiji zbog centrale/rutera/tel. linije a ne zbog OS-a.


[ Slobodan Milivojevic @ 13.09.2009. 11:04 ] @
Telekom ADSL 4M/256k:
(pingujem isti IP kao u postu gore da bi mogli da se porede rezultati)
Linux masina (debian)

Code:
PING 74.125.39.147 (74.125.39.147) 56(84) bytes of data.
64 bytes from 74.125.39.147: icmp_seq=1 ttl=243 time=47.2 ms
64 bytes from 74.125.39.147: icmp_seq=2 ttl=243 time=45.1 ms
64 bytes from 74.125.39.147: icmp_seq=3 ttl=243 time=43.5 ms
64 bytes from 74.125.39.147: icmp_seq=4 ttl=243 time=49.7 ms
64 bytes from 74.125.39.147: icmp_seq=5 ttl=243 time=47.6 ms
64 bytes from 74.125.39.147: icmp_seq=6 ttl=243 time=46.3 ms
64 bytes from 74.125.39.147: icmp_seq=7 ttl=243 time=50.2 ms
64 bytes from 74.125.39.147: icmp_seq=8 ttl=243 time=46.0 ms
^C
--- 74.125.39.147 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7009ms
rtt min/avg/max/mdev = 43.509/46.986/50.287/2.134 ms


exe-net advertising d.o.o. 5GHz wireless link home flat 8M/1M:
linux masina (debian)

Code:
PING 74.125.39.147 (74.125.39.147) 56(84) bytes of data.
64 bytes from 74.125.39.147: icmp_seq=1 ttl=244 time=38.9 ms
64 bytes from 74.125.39.147: icmp_seq=2 ttl=244 time=33.1 ms
64 bytes from 74.125.39.147: icmp_seq=3 ttl=244 time=34.6 ms
64 bytes from 74.125.39.147: icmp_seq=4 ttl=244 time=32.0 ms
64 bytes from 74.125.39.147: icmp_seq=5 ttl=244 time=29.8 ms
64 bytes from 74.125.39.147: icmp_seq=6 ttl=244 time=31.0 ms
64 bytes from 74.125.39.147: icmp_seq=7 ttl=244 time=39.1 ms
64 bytes from 74.125.39.147: icmp_seq=8 ttl=244 time=38.2 ms
64 bytes from 74.125.39.147: icmp_seq=9 ttl=244 time=39.7 ms
^C
--- 74.125.39.147 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8034ms
rtt min/avg/max/mdev = 29.846/35.215/39.746/3.653 ms
[ Jbyn4e @ 13.09.2009. 12:22 ] @
Pa nisam siguran koliko je to relevantno. Mada je bolje da je ping odavde ka masini sa jednim ip-jem, sto se vidi iz sledeceg primera pinga sa servera koji je u americi (USA, rhode island http://www.dnsstuff.com/tools/...redirect=0&ip=68.15.34.115)

ping -c 4 www.google.com
PING www.l.google.com (64.233.169.99): 56 data bytes
64 bytes from 64.233.169.99: icmp_seq=0 ttl=247 time=19.311 ms
64 bytes from 64.233.169.99: icmp_seq=1 ttl=247 time=20.642 ms
64 bytes from 64.233.169.99: icmp_seq=2 ttl=247 time=21.495 ms
64 bytes from 64.233.169.99: icmp_seq=3 ttl=247 time=20.411 ms

--- www.l.google.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.311/20.465/21.495/0.779 ms


ali i
ping -c 4 74.125.39.147
PING 74.125.39.147 (74.125.39.147): 56 data bytes
64 bytes from 74.125.39.147: icmp_seq=0 ttl=244 time=98.646 ms
64 bytes from 74.125.39.147: icmp_seq=1 ttl=244 time=95.864 ms
64 bytes from 74.125.39.147: icmp_seq=2 ttl=244 time=96.386 ms
64 bytes from 74.125.39.147: icmp_seq=3 ttl=244 time=96.567 ms

--- 74.125.39.147 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 95.864/96.866/98.646/1.060 ms


Razlika od 20 i 90 ms je bas velika... ja bih rekao da ti serveri nisu na istom kontinentu :)
[ optix @ 13.09.2009. 15:26 ] @
Vise puta smo objasnili da ping-ovanje google-a nema previse smisla. Google nema jedan server, vec cele farme u okviru data centra, dalje nema jedan data centar, vec ima vise data-centra na razlicitim kontinentima. DNS serveri mogu u bilo kom trenutku da daju bilo koju od IP adresa hiljade servera. Load balanceri dalje mogu preusmeriti nas ICMP paket na bilo koji server koji oni odluce...
Pingovati google kao nekakav 'etalon' je besmisleno. Eto u rezultatima gore ima barem 5,6 razlicitih adresa google-a. Ne razumem kako ce to autoru teme dati objektivan uvid u latenciju tehnologije pristupa.

Pingovati bilo sta drugo osim default gateway-a, u funkciji merenja latencije tehnologije pristupa, je zapravo besmisleno i daje neupotrebljive rezlutate (neupotrebljive ako se radi zaista o nekom 'istrazivanju').
Cim se pinguje nesto van lokalnog gateway-a, u funkcju kasnjenja ulaze i druge varijable: ukupna latencija od gateway-a do ciljanog host-a, sto zavisi od tehnologije pristupa svakog pojedinacnog linka u lancu veza do tog hosta, stanje zagustenosti svih mreza do ciljanog hosta ukljucujucu i zagusenost samog hosta, fizicka distanca do cilja.

Neko ce se ovde javiti i pingovati google iz Nemacke preko adsl-a i dobiti prosek od recimo 15ms, dok neko iz Srbije, preko identicnog adsl-a, ima prosek 50ms. I sta sad, kako se to poredi? :)



[ aLtipar @ 14.09.2009. 03:31 ] @
Optix u pravu si, ali... ni pingovanje default gatewaya nema puno smisla, jer jedan ADSL korisnik moze da bude udaljen 500 metara od centrale, drugi 12000 metara, dok se treci Wi-Fi korisnik kaci na AP koji je udaljen svega 10 metara.

Latencija je prilicno sirok pojam koji obuhvata: vreme potrebno za komadanje podataka na pakete (eng. Packeting delay), kašnjenje prilikom stavljanja podataka na transportni medijum (eng. Transmission delay), vreme potrebno za prenos paketa od pošiljaoca do primaoca (eng. Propagation delay), kašnjenje prilikom prolaska kroz usputnu mrežnu opremu (eng. Processing delay), vreme čekanja u redu (eng. Queuing delay), kao i vreme potrebno za prijem paketa sa transportnog medijuma i proveru grešaka (eng. Serialization delay).

Pingovanje default gatewaya bi samo prikazalo neke od prethodno navedenih vrednosti, ne sve. Naravno, Internet nije savrsen medijum, pa je gotovo nemoguce da paketi podataka u razlicitom vremenskom periodu koriste identicne putanje do hosta koji je udaljen vise desetina hiljada kilometara. Meni su potrebne prosecne vrednosti, a sa obzirom da www.google.com daje razlicite IP adrese svim korisnicima, to ne predstavlja problem. Problem bi nastao kada bi razlicite IP adrese bile davane samo Wi-Fi korisnicima, ili samo korisnicima ADSL usluge, itd...

Uskoro cu da napisem sta korisnicu mogu da urade kako bi smanjili latenciju, kao i na koje segmente latencije korisnici ne mogu da uticu...


[ optix @ 14.09.2009. 04:31 ] @
Cekaj, skroz mi nije jasno, pingovanje default gateway-a nema smisla, ali pingovanje google-a ima?! :) Iako latencija prvog ulazi u ukupan rezultat koji vidimo pingovanjem drugog?

Adsl korisnik ne moze da bude udaljen 12 000m od centrale (bez dodatnih repeater-a). Recimo da je udaljen nekih maksimalnih 5km, razlika pingovanja default gateway-a izmedju njega i fiktivnog korisnika cija je udaljenost 0m od centrale je samo u propagaciji signala kroz paricu (pretpostavljamo da su svi ostali, individualni, parametri isti, jer cela prica tek onda ne bi imala smisla). Ta razlika se meri mikrosekundama. U odnosu na sve ostale greske, ovo je zanemarljivo malo.

Citat:
Pingovanje default gatewaya bi samo prikazalo neke od prethodno navedenih vrednosti, ne sve.
Prikazalo bi sve ono sto zavisi do tehnologije pristupa korisnika, a iskljucilo bi sve ostale 'tehnologije pristupa' inter-provajdera, kasnjenja inter-provajdera, itd. Koliko sam razumeo tvoje istrazivanje je upravo "poredjenje vremena kasnjenja prilikom prenosa podataka (eng. Latency) kod razlicitih broadband tehnologija".

Citat:
Meni su potrebne prosecne vrednosti, a sa obzirom da www.google.com daje razlicite IP adrese svim korisnicima, to ne predstavlja problem. Problem bi nastao kada bi razlicite IP adrese bile davane samo Wi-Fi korisnicima, ili samo korisnicima ADSL usluge, itd...


Ovde pravis sistematsku gresku. Recimo da korisnici adsl-a u odnosu na korisnike wifi pristupa, imaju svi u proseku za 10ms veci odziv (RTT - round trip time) do gateway-a. Kada google ponudi razlicite adrese jednima i drugima, gde se jedna adresa nalazi u recimo Nemackoj a druga u Americi i gde je razlika u rtt-u ~100ms, na koji nacin ces ustanoviti vezu izmedju tehnologije pristupa i latencije? Imas gresku koja je reda 100ms. (recimo wifi ce pingovati usa i imati ~140ms, a adsl ger ~40ms...)

Druga stvar, cak i kada imas slucaj da google daje jednu IP adresu, mislis li da je to uvek ista fizicka masina koja odgovara na zahtev (i uvek ista putanja paketa do nje)? Ja nisam siguran (pogotovu za putanju, to se vrlo lako menja) - razlog vise zbog cega je cela prica oko pingovanja google-a prilicno besmislena.


btw. evo dve adrese koje je Jbyn4e dobio kod mene
c857>ping 74.125.39.147

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 74.125.39.147, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/28/30 ms
c857>ping 74.125.43.106

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 74.125.43.106, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/48/52 ms


~20ms razlika, ista linija...
[ aLtipar @ 14.09.2009. 07:14 ] @
Pa kazem u pravu si, gresaka ce svakako biti, ali pingovanje default gatewaya daje suvise male vrednosti (i to zaokruzene vrednosti), pa bi statisticka greska tek onda bila ogromna. Evo ti primer - korisnik ADSL usluge ima 2 ms do default gatewaya, dok kablovski korisnik ima 1 ms. Da li bi onda bilo realno reci da ADSL ima duplo vecu latenciju od kablovske veze...? Sa druge strane, evo ja trenutno koristim 3G net. Ne mogu da pingujem nista, jer uvek dobijem "request timed out" poruku. Razlog je veoma jednostavan - 3G korisnici imaju privatnu IP adresu, pa se paketi izgleda gube prilikom prolaska kroz NAT... Da li bi i u ovom slucaju pingovanje default gatewaya dalo jasnu sliku o situaciji...? Sumnjam, jer pravo kasnjenje krece tek nakon default gatewaya...



[ djricky @ 14.09.2009. 08:42 ] @
ufff........ default gw je prvi host van tvoje mreze, znaci ne tvoj (adsl/kablovski) ruter, vec uredjaj koji je njemu default gw... paketi se ne gube pri prolasku kroz NAT, vec ih telenor (namerno ili slucajno) sece... probaj mts 3G, videces da radi i ping i traceroute...

malo si pomesao neke stvari...
[ aLtipar @ 14.09.2009. 12:20 ] @
I meni je palo na pamet da namerno vrse filtriranje, verovatno zbog VoIP-a... A sto se default gatewaya tice, zar nije Telenorov NAT server moj default gateway, sa obzirom da on povezuje internu mrezu mobilne telefonije (172.x.x.x) sa eksternom mrezom tj. Internetom, ili gresim?
[ djricky @ 14.09.2009. 13:17 ] @
zbog voip-a? tesko... da ne pominjem da je voip skoro pa neupotrebljiv kroz 3G...

telenorov NAT router jeste tvoj default gw i do njega i treba da meris ping... ovo sa google-om nema puno smisla...
[ xtraya @ 14.09.2009. 14:25 ] @
haha voip udp over 3g/edge :P ... eto shale :)
[ Slobodan Milivojevic @ 14.09.2009. 16:52 ] @
Citat:
xtraya: haha voip udp over 3g/edge :P ... eto shale :)


Radi bre VoIP na HSDPA.
[ djricky @ 14.09.2009. 17:59 ] @
da, ali koliko kvalitetno?
[ aLtipar @ 15.09.2009. 09:29 ] @
Bila je vec rasprava na tu temu. Ako imas WCDMA ili HSDPA signal, VoIP ce raditi veoma dobro... Za VoIP nije toliko bitna latencija, koliko QoS podrska. Ja licno koristim EyeBeam program koji moze da se nakaci na bilo koji SIP server, a podrzava i G.729 kodek (koji odlicno radi cak i preko 56K modema). Ko ne veruje, neka proba... :))
[ djricky @ 16.09.2009. 10:16 ] @
Citat:
aLtipar: Za VoIP nije toliko bitna latencija, koliko QoS podrska.


hm.... pa sad..... ako mozes da se naviknes na ono kasnjenje od realnih 300-500 ms (tzv. half-duplex pricu) sto da ne...
[ djricky @ 16.09.2009. 10:19 ] @
btw, kad smo vec tu, evo mojih pingova do one 2 adrese...

root@master:/media/cdrom# ping -A -c 100 -q 74.125.43.106
PING 74.125.43.106 (74.125.43.106) 56(84) bytes of data.

--- 74.125.43.106 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 3651ms
rtt min/avg/max/mdev = 34.388/36.273/40.307/1.686 ms, pipe 2, ipg/ewma 36.883/36.446 ms

root@master:/media/cdrom# ping -A -c 100 -q 74.125.39.147
PING 74.125.39.147 (74.125.39.147) 56(84) bytes of data.

--- 74.125.39.147 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 2555ms
rtt min/avg/max/mdev = 23.715/25.473/28.463/1.178 ms, pipe 2, ipg/ewma 25.809/25.774 ms
[ legija @ 16.09.2009. 14:10 ] @
Pathping je mnogo bolja aplikacija za "istrazivanja".

Code:
C:\Documents and Settings\Administrator>pathping google.com

Tracing route to google.com [74.125.127.100]
over a maximum of 30 hops:
  0  desktop [10.0.0.100]
  1  10.0.0.3
  2  91.191.4.141
  3  91.191.4.129
  4  91.191.0.189
  5  gst12-gtr11.ip.t-com.hr [195.29.252.209]
  6  hdr01-gdr01-3.ip.t-com.hr [195.29.240.173]
  7  gdr10-hdr01.ip.t-com.hr [195.29.241.114]
  8  po2-0.core01.vie01.atlas.cogentco.com [149.6.174.29]
  9  te1-4.ccr01.vie01.atlas.cogentco.com [130.117.48.41]
 10  te1-7.ccr01.muc01.atlas.cogentco.com [130.117.3.21]
 11  te2-2.ccr01.fra03.atlas.cogentco.com [130.117.0.65]
 12  74.125.50.233
 13  209.85.255.170
 14  209.85.250.140
 15  209.85.248.81
 16  216.239.43.192
 17  216.239.46.14
 18  209.85.249.19
 19  72.14.239.12
 20  209.85.250.126
 21  209.85.250.144
 22  64.233.174.127
 23  pz-in-f100.google.com [74.125.127.100]

Computing statistics for 575 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           desktop [10.0.0.100]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  10.0.0.3
                                0/ 100 =  0%   |
  2    2ms     0/ 100 =  0%     0/ 100 =  0%  91.191.4.141
                                0/ 100 =  0%   |
  3    3ms     0/ 100 =  0%     0/ 100 =  0%  91.191.4.129
                                0/ 100 =  0%   |
  4    4ms     0/ 100 =  0%     0/ 100 =  0%  91.191.0.189
                                0/ 100 =  0%   |
  5  ---     100/ 100 =100%   100/ 100 =100%  gst12-gtr11.ip.t-com.hr [195.29.25
2.209]
                                0/ 100 =  0%   |
  6   11ms     0/ 100 =  0%     0/ 100 =  0%  hdr01-gdr01-3.ip.t-com.hr [195.29.
240.173]
                                0/ 100 =  0%   |
  7  ---     100/ 100 =100%   100/ 100 =100%  gdr10-hdr01.ip.t-com.hr [195.29.24
1.114]
                                0/ 100 =  0%   |
  8   18ms     0/ 100 =  0%     0/ 100 =  0%  po2-0.core01.vie01.atlas.cogentco.
com [149.6.174.29]
                                0/ 100 =  0%   |
  9   30ms     0/ 100 =  0%     0/ 100 =  0%  te1-4.ccr01.vie01.atlas.cogentco.c
om [130.117.48.41]
                                0/ 100 =  0%   |
 10   35ms     0/ 100 =  0%     0/ 100 =  0%  te1-7.ccr01.muc01.atlas.cogentco.c
om [130.117.3.21]
                                0/ 100 =  0%   |
 11   35ms     0/ 100 =  0%     0/ 100 =  0%  te2-2.ccr01.fra03.atlas.cogentco.c
om [130.117.0.65]
                                0/ 100 =  0%   |
 12   33ms     0/ 100 =  0%     0/ 100 =  0%  74.125.50.233
                                0/ 100 =  0%   |
 13   37ms     0/ 100 =  0%     0/ 100 =  0%  209.85.255.170
                                0/ 100 =  0%   |
 14   43ms     0/ 100 =  0%     0/ 100 =  0%  209.85.250.140
                                0/ 100 =  0%   |
 15   51ms     0/ 100 =  0%     0/ 100 =  0%  209.85.248.81
                                0/ 100 =  0%   |
 16  129ms     0/ 100 =  0%     0/ 100 =  0%  216.239.43.192
                                0/ 100 =  0%   |
 17  147ms     0/ 100 =  0%     0/ 100 =  0%  216.239.46.14
                                0/ 100 =  0%   |
 18  165ms     0/ 100 =  0%     0/ 100 =  0%  209.85.249.19
                                0/ 100 =  0%   |
 19  202ms     0/ 100 =  0%     0/ 100 =  0%  72.14.239.12
                                0/ 100 =  0%   |
 20  200ms     0/ 100 =  0%     0/ 100 =  0%  209.85.250.126
                                0/ 100 =  0%   |
 21  200ms     1/ 100 =  1%     1/ 100 =  1%  209.85.250.144
                                0/ 100 =  0%   |
 22  203ms     0/ 100 =  0%     0/ 100 =  0%  64.233.174.127
                               51/ 100 = 51%   |
 23  204ms    51/ 100 = 51%     0/ 100 =  0%  pz-in-f100.google.com [74.125.127.
100]

Trace complete.