ฉันเห็นว่าเอาแน่เอานอนไม่ได้และบางครั้งเวลาปิงนานไปที่เราเตอร์ไร้สายของฉันก็แค่กระโดดไปหนึ่งครั้ง การส่ง Ping 192.168.1.1ให้บางครั้งอาจมีความล่าช้า 400-800ms

มีหลายสิ่งให้ลอง (เฟิร์มแวร์การจัดวางเราเตอร์ช่อง AP ฯลฯ ) แต่ฉันต้องการที่จะโจมตีปัญหานี้อย่างเป็นระบบมากขึ้น:

• ครั้งแรกที่ฉันจะได้เห็นภาพการทำงานของเครือข่ายของฉันได้อย่างไร
• จากนั้นฉันจะเปรียบเทียบประสิทธิภาพของการกำหนดค่าที่กำหนดได้อย่างไรเพื่อที่ฉันจะสามารถเปรียบเทียบได้อย่างน่าเชื่อถือหลังจากทำการปรับเปลี่ยน

คำตอบข้อผิดพลาดของเซิร์ฟเวอร์นี้มีคำแนะนำระดับสูงที่ดีเกี่ยวกับสิ่งที่ต้องทำดังนั้นเริ่มต้นด้วยสิ่งนั้น ขั้นตอนสุดท้ายนั้นคือ doozy จริง: สมมุติว่าคุณ (ฉันหมายถึงฉัน) ไม่ต้องการลงทุนในฮาร์ดแวร์เฉพาะสำหรับสิ่งนี้ ...

ด้านล่างเป็นเครื่องมือที่ดีเป็นอย่างแรกเพื่อทำความเข้าใจเกี่ยวกับสุขภาพการเชื่อมต่อภายในเครือข่าย wifi ในพื้นที่จากนั้นไปยังจุดสิ้นสุดอินเทอร์เน็ต

เครื่องมือ Wifi

NetSpot (สำหรับ mac)

มันติดตาม WiFI APs ท้องถิ่นและให้ข้อมูลพื้นฐานเช่น SNR, Channel, Signal Strength นอกจากนี้ยังสามารถทำการสำรวจไซต์พื้นฐานสำหรับพื้นที่ทางกายภาพที่แสดงถึงจุดแข็งและการรบกวน ในโหมดการค้นพบ AP คุณยังสามารถสร้างแผนภูมิความแรงของสัญญาณเมื่อเวลาผ่านไปซึ่งช่วยให้คุณสามารถทดสอบตำแหน่งและปรับความเป็นไปได้ของสัญญาณรบกวน

ทดสอบความเร็ว Wifi สำหรับ Android

มีประโยชน์มาก คุณจะเรียกใช้เซิร์ฟเวอร์หลามอย่างง่ายบนเครื่องของคุณและแอพสามารถทดสอบสถานการณ์สมมติสองสามข้อเพื่อให้คุณได้รับข้อเสนอแนะด้านความเร็วแบบเรียลไทม์

Wifi Analyzerเป็นแอพ Android ที่ยอดเยี่ยมอีกตัวหนึ่ง อาจเป็นเครื่องมือฟรีที่ดีที่สุดสำหรับการเลือกช่อง AP โดยไม่ต้องทำงานมาก

iPerf

เครื่องมือที่ได้รับการยอมรับอย่างดีสำหรับการทำความเข้าใจประสิทธิภาพของเครือข่ายท้องถิ่น คุณต้องมีสองกล่องหนึ่งกล่องเป็นเซิร์ฟเวอร์หนึ่งกล่องเป็นไคลเอ็นต์ คุณสามารถตั้งค่าพารามิเตอร์จำนวนหนึ่งรันการทดสอบและดูผลลัพธ์สำหรับแบนด์วิดท์และ jitter ฉันชอบใช้มันกับjPerf GUIสำหรับการสร้างแผนภูมิผลลัพธ์และปรับแต่งพารามิเตอร์

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

สุขภาพการเชื่อมต่ออินเทอร์เน็ต

mtr (ping & traceroute รวมกัน)

ส่งการกระโดด traceroute ทั้งหมดของคุณ จัดเตรียมข้อมูลแนวโน้ม สุดยอดมาก

brew install mtr
mtr 8.8.4.4

Speedtest-CLI

รุ่น CLI ของ ookla speedtest.net สิ่งทั่วไป ผู้ดูแลโครงการประกาศว่ามันไม่สอดคล้องกัน แต่ก็ยังมีประโยชน์ในการพยายามวัดความแตกต่างขนาดใหญ่

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 : เส้นทางเครือข่ายและการวินิจฉัยแอปพลิเคชัน

เซิร์ฟเวอร์การวินิจฉัยอัตโนมัติสำหรับการแก้ไขปัญหาระบบปลายทางและปัญหาเครือข่ายล่าสุด หลังจากใช้งานแบตเตอรี่ของการทดสอบจะช่วยให้หน้าผลการสรุปเช่นนี้ ฉันแนะนำให้ใช้ลิงก์เปลี่ยนเส้นทางเซิร์ฟเวอร์ NPADนี้เพื่อค้นหาเซิร์ฟเวอร์ NPAD ที่ใกล้ที่สุด (ใกล้หมด) และใช้ชื่อโฮสต์นั้นสำหรับการทดสอบของคุณ

  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

ผลลัพธ์ส่วนตัวของฉัน:

ฉันใช้เวลาสองสามชั่วโมงในการทำสิ่งนี้ลองสิ่งต่าง ๆ (เปลี่ยนจาก DD-WRT เป็นเฟิร์มแวร์ Tomato) และการอ่าน ปรากฎว่ามันไม่ใช่เลเยอร์เครือข่ายและเป็นสัญญาณรบกวน RF ที่ดีซึ่งส่วนใหญ่มาจาก Bluetooth! ฉันมีคอมพิวเตอร์เมาส์และคีย์บอร์ดบลูทู ธ อยู่ห่างจากเราเตอร์ไม่เกิน 5 ฟุต (และเราเตอร์เก่ายังคงใช้ความถี่ 2.4 กิกะเฮิร์ตซ์เมื่อพวกเขาปะทะกัน)

สำหรับเรื่องนี้ฉันได้รับประโยชน์สูงสุดจากWifi Speed ​​Test สำหรับ Androidใช้งานเป็นประจำในขณะที่ฉันย้ายสิ่งต่าง ๆ ในอพาร์ทเมนท์ เนื่องจากรายงานอัปเดตทุก ๆ 200ms หรือมากกว่านั้นจึงมีการสื่อสารอย่างชัดเจนเมื่อสัญญาณรบกวนลดลงแพ็คเก็ตของฉัน

ฉันขอแนะนำให้อ่านคู่มือแหล่งที่มาทั่วไปของการแทรกแซงจาก Metageek (พวกเขายังสร้าง InSSIDer และเครื่องมือวิเคราะห์ Wifi อื่น ๆ ที่ดูดีอีกด้วย)

เครื่องมืออย่างหนึ่งที่ฉันไม่ได้มีคือเครื่องวัดวิเคราะห์สเปกตรัม โทรศัพท์และแล็ปท็อปสามารถตรวจจับ Wifi AP ได้เท่านั้น แต่ไม่สามารถรับสัญญาณรบกวนจาก Bluetooth หรือเทคโนโลยี RF อื่น ๆ MetaGeek มีการแก้ปัญหาที่ดีบางอย่างในพื้นที่นี้ ( Wi-SpyและinSSIDer สำนักงาน ) และหวังว่าเราจะเห็นเครื่องมือเพิ่มเติมโผล่ออกมาเหมือนAirShark

ตามที่ระบุไว้ในความคิดเห็นของฉันด้านบน: เครื่องมือที่ใช้โดยทั่วไปเพื่อวินิจฉัยปัญหา Wi-Fi อาจทำให้เกิดปัญหานี้ได้ เมื่อทำการสแกนหาเครือข่าย Wi-Fi วิทยุจะต้องปิดช่องสัญญาณโดยปกติแล้วมันจะบอก AP ให้ใส่เฟรมบัฟเฟอร์เพื่อให้มันสามารถ 'หลับ' จากนั้นสลับช่องเพื่อสแกน

นอกจากนี้ iOS และ OS X ตั้งแต่ AirDrop เปิดตัวจะนำวิทยุ Wi-Fi ออกจากช่องเพื่อค้นหาบริการ AirDrop อื่น ๆ และเนื่องจากโยเซมิตีจะออกจากช่องเป็นระยะเพื่อสนับสนุนการแฮนด์ออฟ

ดังนั้นฉันจึงมีความผันผวนของ Wi-Fi ping กับเราเตอร์ด้วย

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

ฉันเปลี่ยนเราเตอร์ (จาก TL-WR743ND เป็น DIR-815) ลองใช้อะแดปเตอร์ Wi-Fi USB หลายตัว (ส่วนใหญ่เป็น TP-LINK แม้ว่าฉันคิดว่าฉันมีปัญหากับ D-Link DWA-160 เช่นกัน) เปลี่ยนจาก 2.5 GHz เป็น 5GHz และ scoured ช่อง ไม่มีโชคปัญหายังคงอยู่

จนกระทั่งฉันสังเกตเห็นว่าเมื่อฉันทำการทดสอบความเร็วเครือข่ายหรือเรียกใช้ไคลเอ็นต์ bittorrent การ ping นั้นถูกต้อง มันผันผวนเฉพาะเมื่อเครือข่ายไม่ได้ใช้งาน

อาจเป็นปัญหาของ Windows 7 หรือสิ่งที่มีอะแดปเตอร์ TP-LINK ของฉัน แต่เมื่อฉันให้บิตของ Wi-Fi เล็กน้อยความผันผวนจะหายไปและเครือข่ายทำงานได้ดี

จนถึงตอนนี้ฉันได้สร้างโปรแกรม Rust เล็กน้อยเพื่อรักษาเครือข่าย Wi-Fi ของฉัน

// 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));}}