Sadece bir atlama uzakta olan wifi yönlendiricime düzensiz ve bazen çok uzun ping süreleri görüyorum. Ping işlemi 192.168.1.1bazen 400-800ms gecikme süresi sağlar.

Denenecek çok şey var (ürün yazılımı, yönlendirici yerleşimi, AP kanalı, vb.), Ancak bu soruna biraz daha düzenli bir şekilde saldırmak istiyorum:

• İlk olarak, ağımın performansını nasıl görselleştirebilirim ?
• Öyleyse, ayarlamalar yaptıktan sonra güvenilir bir şekilde karşılaştırabilmem için belirli bir yapılandırmanın performansını nasıl kıyaslayabilirim ?

Bu sunucu hatası cevabı ne yapılması gerektiğine dair üst düzey bir rehbere sahiptir - bu yüzden bununla başla. Bu son adım gerçekte tam bir sarhoşluktur: Muhtemelen sen (yani ben), bunun için özel bir donanıma yatırım yapmak istemezsin ...

Aşağıda, önce yerel wifi ağındaki bağlantı sağlığını ve sonra da bir internet uç noktasını anlamak için bazı iyi araçlar bulunmaktadır.

Wifi Araçları

NetSpot (mac için)

Yerel WiFI AP'leri izler ve SNR, Kanal, Sinyal Gücü gibi temel verileri sağlar. Ayrıca, güçlü ve enterferansı belirten fiziksel bir alan için basit bir saha araştırması yapabilir. AP keşif modunda, zaman içinde sinyal gücünü grafik olarak göstererek yerleşimleri test etmenize ve parazit olasılıklarını ayarlamanıza olanak tanır.

Android için Wifi Hız Testi

Çok yararlı. Makinenizde basit bir python sunucusu çalıştıracaksınız ve uygulama size gerçek zamanlı hız geri bildirimi veren birkaç senaryoyu test edebilir.

Wifi Analyzer , başka bir harika android uygulaması, AP wifi kanallarının aktif olduğu şeylerin birkaç değerli görüşüne sahip. Çok fazla iş yapmadan AP kanalını seçmek için en iyi ücretsiz araç olabilir.

Iperf

Yerel ağ performansını anlamak için saygın bir araç. Biri sunucu, diğeri istemci olarak iki kutuya ihtiyacınız var. Bir dizi parametre ayarlayabilir, bir test çalıştırabilir ve bant genişliği ve titreme için sonuçları görebilirsiniz. Sonuçları grafik ve ince ayar parametreleri için jPerf GUI ile kullanmayı düşünüyorum .

brew install iperf
iperf -s # on server, next one on client
iperf -c 192.168.1.XXX -P 1 -i 1 -p 5001 -f m -t 60

İnternet Bağlantısı Sağlığı

mtr (ping & traceroute birleştirilmiş)

Tüm traceroute şerbetçilere ping at. Trend verisi sağlar. Çılgın harikaydı.

brew install mtr
mtr 8.8.4.4

SpeedTest-cli

Ortak ookla speedtest.net şeyinin CLI sürümü. Proje sorumlusu tutarlı olmadığını açıkladı, ancak yine de büyük farklılıkları ölçmeye çalışmak kullanışlı.

wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
chmod +x speedtest-cli
speedtest-cli --list | head # and chose a top server (sorted by distance)
speedtest-cli --server 2761 # re-use the same server

NPAD : Ağ Yolu ve Uygulama Teşhisi

Uç sistemler ve son mil ağ sorunlarını gidermek için otomatik tanılama sunucusu. Bir test bataryası çalıştırdıktan sonra, bunun gibi bir Sonuç Özeti sayfası görüntülenir . En yakın NPAD sunucusunu bulmak için (hepsi bitti) bu NPAD sunucusu yönlendirme bağlantısını kullanmanızı ve bu ana bilgisayar adını testleriniz için kullanmanızı öneririm.

  wget http://netspeed.usc.edu:8000/diag-client.c
  cc diag-client.c -o diag-client
# ./diag-client <server_name> <port> <target_RTT> <target_data_rate_in_MB/S>
  ./diag-client ps.psc.xsede.org 8001 30 5

Kişisel sonuçlarım:

Bunları yapmak için birkaç saat harcadım, farklı şeyler denemek (DD-WRT'den Domates ürün yazılımına geçmek) ve okumak. Ağ katmanı olmadığı ve çoğunlukla Bluetooth'lu eski RF paraziti olduğu ortaya çıktı! Bilgisayarım, bir bluetooth fare ve yönlendiricinin 5 feet içinde klavye vardı. (Ve eski yönlendirici hala çatışmada oldukları 2.4GHz'de.)

Bunun için , dairede dolaşırken düzenli olarak çalıştıran Android için Wifi Hız Testinden en iyi şekilde yararlandım. Her 200ms'de bir güncelleme bildirdiği için, parazitlerimi paketlerime atarken açıkça haberleşiyordu.

Ortak Girişim Kaynakları rehberini Metageek'ten okumanı kesinlikle tavsiye ederim . (Ayrıca, InSSIDer ve iyi görünen diğer Wifi analiz araçlarını da yaparlar.)

Sahip olmadığım bir araç fiziksel bir spektrum analizi ölçüm cihazıydı. Telefonlar ve dizüstü bilgisayarlar yalnızca Wifi AP'leri algılayabilir, ancak Bluetooth veya diğer RF tabanlı teknolojilerden gelen girişimi algılayamaz. Metageek'in bu alanda bazı güzel çözümleri var ( Wi-Spy ve inSSIDer Office ) ve umarım AirShark gibi daha fazla araç ortaya çıkmaktadır .

Yukarıdaki yorumumda belirtildiği gibi: Wi-Fi sorunlarını teşhis etmek için yaygın olarak kullanılan araçlar aslında bu soruna neden olabilir. Wi-Fi şebekelerini tararken, telsiz kanaldan çıkmak zorunda kalır, tipik olarak AP'ye çerçeveler tamponlamasını söyler, böylece 'uyuyabilir' ve sonra kanalları taramaya geçirir.

Ek olarak, AirDrop piyasaya sunulduğundan beri iOS ve OS X, diğer AirDrop servislerini aramak için Wi-Fi telsiz kanalını kullanacak ve Yosemite devir teslimini desteklemek için periyodik olarak kanaldan çıkacak.

Bu yüzden yönlendiricide bu Wi-Fi ping dalgalanmaları oldu.

PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=63 time=2.334 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=63 time=1.813 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=63 time=2749.664 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=63 time=1748.912 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=63 time=748.162 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=63 time=1.796 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=63 time=1.806 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=63 time=1.991 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=63 time=1.797 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=63 time=1.832 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=63 time=1.713 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=63 time=1.819 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=63 time=1.616 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=63 time=1.748 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=63 time=1.677 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=63 time=3427.213 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=63 time=2426.371 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=63 time=1425.634 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=63 time=424.834 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=63 time=1.829 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=63 time=1.691 ms
64 bytes from 192.168.0.1: icmp_seq=21 ttl=63 time=2.038 ms
64 bytes from 192.168.0.1: icmp_seq=22 ttl=63 time=1.679 ms
^C--- 192.168.0.1 ping statistics ---
23 packets transmitted, 23 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.616/564.346/3427.213/1015.102 ms

Yönlendiriciyi değiştirdim (TL-WR743ND'den DIR-815'e), birkaç Wi-Fi USB adaptörünü denedim (çoğunlukla TP-LINK'ler, D-Link DWA-160 ile de ilgili sorunum olduğunu düşünmeme rağmen) 2.5 GHz'den ... 5 GHz ve kanalları taradı. Şans yok, sorun devam etti.

Bir ağ hızı testi yaptığımda veya bir bittorrent istemcisi çalıştırdığımda, ping işleminin tamam olduğunu fark edene kadar. Yalnızca ağ boştayken dalgalanır.

TP-LINK adaptörleri ile bir Windows 7 sorunu veya sorunu olabilir, ancak Wi-Fi'ye biraz yük verdiğimde dalgalanma kayboluyor ve ağ düzgün çalışıyor.

Şimdiye kadar Wi-Fi ağımı yüksek tutmak için küçük bir Rust programı yaptım.

// Need a constant wifi load in order not to have the ping drops.
fn wifi_load() {
  // This *might* be useful if the router suddenly supports Keep-Alive.
  // Not the case with DIR-815 though, we'll keep making new connections to it.
  let config = hyper::client::pool::Config {max_idle: 1};

  let client = hyper::client::Client::with_pool_config (config);
  loop {
    let url = "http://192.168.0.1/css/init.css";
    if let Err (err) = client.get (url) .send() {
      log! ("wifi_load] Error fetching {}: {}", url, err);
      sleep (Duration::from_secs (9));}
    sleep (Duration::from_millis (100));}}