Bağlantıyı test etmek için ping google.com'u kullanma


11

Evimizdeki internet bağlantısı zaman zaman koptuğu için küçük bir deney yaptım:

Son iki aydır, makinelerimden biri google.com’a yarım saatte bir ping atıyor. Bir ölçüm 50 ping'den oluşur.

Şimdi günün her saati için kaybedilen paketlerin ortalama yüzdesini hesapladım: kayıp paketlerin yüzdesi

Sorularım:

  1. Akşamları bu zirveye ping hedefi olarak google.com'u seçerek neden olabilir mi?
  2. Başka bir varış noktası kullanmanızı tavsiye eder misiniz?
  3. Bu, bağlantımda bir sorun olduğunu gösteriyor mu?
  4. İnternet bağlantımızdaki sorunun tam olarak nerede olduğunu ölçmek için daha iyi bir strateji ne olurdu? ISS’miz bize iyi çalıştığını söyledi, ben de bazı kanıtları toplamaya çalışıyorum ...

Saygılarımızla!

Düzenleme: Makinenin doğrudan yönlendiriciye bağlı olduğunu belirtmeyi unuttum (WiFi yok). Ve yönlendirici de paketlenmiş ve paket kaybı yaşanmadı.


Tam olarak ne demek "evimizdeki internet bağlantısı zaman zaman bozuluyor"? Eğer "bozulma", "çalışmayı durdur" anlamına gelirse , işe yaradığında paket kaybının izlenmesi size yararlı bir şey söyleyemez.
Isaac Rabinovitch

Doğru, ama benim ilgi olduğu zaman o yıkmak etmez ve ne sıklıkta / ne kadar süre .
Dirk

Yanıtlar:


10

Ne yazık ki, sorunun nerede olduğunu bulmak için gerçekten yeterli bilgi vermediniz. Verilen sınırlı bilgi ile elimden geldiğince cevap vermek için:

  1. Eğer deneyimlerime katlanılacak bir şey varsa, Google’a ping göndermek normalde oldukça iyi bir bahistir, çünkü ağlarını olabildiğince hızlı şekilde tasarlarlar. ICMP'ye öncelik verildiği gibi, akşam zirvesi de muhtemelen 0 olması gerektiğini iddia ettiğim - özellikle paket kaybı açısından - önemli bir fark yaratmıyor.

  2. Google iyi bir destinasyondur, ancak neler olup bittiğiyle ilgili daha iyi bir fikir edinmek için ek olarak ağ geçidinize ping atmayı ve eğer izin verirse, sağlayıcılarınızın DNS, posta veya web sunucusunu denemek isteyebilirsiniz. Bu, paket kaybının nereye süründüğünü göstermeye yardımcı olacaktır. Gerçekte, gördüğünüz paket kaybı düzeyinde, MTR (veya WinMTR) indirmeye bakın ve paket kaybının nereden geldiğine dair daha iyi bir fikir edinmek için peek'te çalıştırın. .

  3. Öznel olarak,% 5 paket kaybı, Wifi tabanlı bir ağ için, ağınızı doyurmadığınızı varsayarsak, kabul edilebilir en üst noktadadır. Kapak tarafında, fiber bağlantılarımda yaklaşık% 0.5'lik paket kaybı üzülüyorum - bir referans noktası olarak, gevşek bir şekilde konuşursak, VOIP için% 1'den daha az sorun
    değil , bunun üzerinde değil. Skype veya Viber'ı kullanabilmeyi düşünüyorsanız veya bağlantınızdakiler arasında% 5 paket kaybı olmaz. Sadece Web'de gezinmek için yeterli olabilir.

  4. Bir ISS olarak, hedef arasındaki gecikmeleri ve paket kaybını gösteren bir MTR sonuçlarını görmek istiyorum - bu, darboğazın nerede olabileceğine ve iyi bir ilk adım olduğuna bakmama yardımcı olur. Testin ne zaman yapıldığını da bilmek istiyorum, böylece müşteriyi diğer kullanımlarla ve sistemde neler olup bittiğini ilişkilendirebilirim. Yaptığınız paket kaybı grafikleri de yararlıdır, ancak bunlar izole değildir.

    Bir müşteri olarak, ISS'm paket kaybını gösteren grafiklerimi mazeret edemedi (bunu pingler için minimum, ortalama ve maksimum gecikmeler ile birlikte saniyede 5 dakikalık aralıklarla 250 ping için yapıyorum). Ayrıca, bağlantıdan yararlandığımı gösteren bir grafiklerim var ve yerel (yani bana çok yakın) gösteren grafikler ve birkaç yüz KM uzağa özel ilgi duydukları başka bir POP'a sahipler.

Diğer gözlemler:

Görünüşe göre gecikme süreniz öğleden sonraları artar - bu, benim arayacağım ilk yerlerin, etrafımdaki herkes kullanırken sorun WIFI olup olmadığıdır. Karar verdikten sonra, ISS'mi bağlantıyı abonelikten çıkarmak konusunda sorgulamaya başlayacağım.


Cevaplarınız için çok teşekkürler. Makine doğrudan yönlendiriciye bağlı ve hiçbir paket losyonu göstermediği için yönlendiriciye de ping atıyor. MTR aradığım şey gibi görünüyor.
Dirk

6

Bu büyük olasılıkla, hat boyunca bir yerde tıkanıklığın sonucudur. Yönlendiriciniz olabilir ancak daha büyük bir yukarı akış sağlayıcı olabilir.

50 ping'i nasıl yaptığınızı, örneğin hangi zaman aralığını yaptığınızı, bir sonrakinden önce başarısız olmayı / başarılı olmayı mı beklediğinizi ya da bir kerede 50'yi ateşlemeyi beklemiyorsunuz (taşkın pingi).

Yüksek tıkanıklık dönemlerinde böyle bir kayıp benim tecrübeme göre sıradışı değil. ICMP trafiği için önceliği düşürmek düşük olabilir, ancak tüm bağlantıların aynı yüzdesi için daha büyük olasılıkla gerçekleşiyor - bu sadece TCP'nin dikkatle yeniden göndermesi ve yeniden sıralaması, böylece fark etmeniz daha az olası.

Durumun daha iyi bir resmini elde etmek için aşağıdakileri uygulamanızı tavsiye ederim:

  1. Ping'leriniz arasındaki süreyi artırın
  2. Alan adına değil, google için bir IP adresine ping gönderin - google.com bir dizi A kaydı döndürür ve siz de bilmeden farklı son IP'ler kullanıyor olabilirsiniz (ve dolayısıyla farklı yönlendirme)
  3. Cevaplamak için ortalama süreyi kaydedin; Bunun kayıpla ilişkili olup olmadığını görün - öyle yaparsa ping gidiş dönüş sürelerinin daha yüksek olduğunu ve daha yüksek kaybın tıkanıklığı gösterdiğini gösterir. Daha sonra, traceroute logları depolayarak araştırabilir ve aniden artmış zamanlar gördüğünüz bir yerde muhtemel bir darboğaz olup olmadığını görebilirsiniz.
  4. Google'dan daha fazla ping atmayı deneyin. Geçmişte ağ performansını kıyasladığımda, 4 veya 5 iyi son nokta kullanarak (yine ana bilgisayar adı değil IP adresiyle) yaptım, böylece sadece Google'ın ağındaki tıkanıklığı veya belirli bir sorunu ortadan kaldırabilirsiniz. tüm bağlantınızı sorgulayın

2

Bu, çoğu konut ISS hesabının tipik bir örneğidir. İnsanlar işten sonra eve döndüklerinde ağ tıkanıklığı nedeniyle bir zirve görüyorsunuz, daha sonra tüm gece için çevrimiçi. Bu tür bir akşam zirvesi özellikle çok sayıda çevrimiçi oyuncunun bulunduğu ileri teknoloji topluluklarda belirgindir (burada yaşadığım yer gibi, burada Microsoft'un evi olan Redmond'da).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.