Tôi đang thấy thời gian ping thất thường và đôi khi rất dài đến bộ định tuyến wifi của mình chỉ cách một bước nhảy. Ping 192.168.1.1đôi khi cho độ trễ 400-800ms.

Có rất nhiều thứ để thử (phần sụn, vị trí bộ định tuyến, kênh AP, v.v.), nhưng tôi muốn tấn công vấn đề này một cách có phương pháp hơn một chút:

• Đầu tiên, làm thế nào tôi có thể hình dung hiệu suất của mạng của tôi?
• Sau đó, làm cách nào tôi có thể điểm chuẩn hiệu suất của một cấu hình nhất định để tôi có thể so sánh đáng tin cậy sau khi thực hiện điều chỉnh?

Câu trả lời của serverfault này có hướng dẫn cấp cao về những việc cần làm - vì vậy hãy bắt đầu với điều đó. Bước cuối cùng đó thực sự là một điều khó khăn: có lẽ bạn (ý tôi là tôi) không muốn đầu tư vào phần cứng chuyên dụng cho việc này ...

Dưới đây là một số công cụ tốt, trước tiên để hiểu sức khỏe kết nối trong mạng wifi cục bộ, sau đó đến điểm cuối internet.

Công cụ Wifi

NetSpot (cho mac)

Nó theo dõi các AP WiFI cục bộ và cung cấp dữ liệu cơ bản như SNR, Kênh, Cường độ tín hiệu. Nó cũng có thể thực hiện khảo sát địa điểm cơ bản cho một không gian vật lý chỉ ra điểm mạnh và sự can thiệp. Trong chế độ phát hiện AP, bạn cũng có thể lập biểu đồ cường độ tín hiệu theo thời gian, cho phép bạn kiểm tra các vị trí và điều chỉnh khả năng nhiễu.

Kiểm tra tốc độ wifi cho Android

Rất hữu ích. Bạn sẽ chạy một máy chủ python đơn giản trên máy của mình và ứng dụng có thể kiểm tra một vài tình huống cho bạn phản hồi tốc độ thời gian thực.

Bộ phân tích Wifi , một ứng dụng Android tuyệt vời khác, có một vài lượt xem có giá trị về những gì các kênh wifi AP đang hoạt động. Có thể là công cụ miễn phí tốt nhất để chọn kênh AP mà không phải thực hiện nhiều công việc.

iPerf

Công cụ được tôn trọng để hiểu hiệu suất mạng cục bộ. Bạn cần hai hộp, một là máy chủ, một là máy khách. Bạn có thể thiết lập một số tham số, chạy thử nghiệm và xem kết quả về băng thông và jitter. Tôi thích sử dụng nó với GUI jPerf để lập biểu đồ kết quả và điều chỉnh các tham số.

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

Sức khỏe kết nối Internet

mtr (ping & traceroute kết hợp)

Ping tất cả các bước nhảy của bạn. Cung cấp dữ liệu xu hướng. Điên thật tuyệt vời.

brew install mtr
mtr 8.8.4.4

speedtest-cli

Phiên bản CLI của điều ookla speedtest.net phổ biến. Nhà bảo trì dự án tuyên bố nó không nhất quán, nhưng vẫn có ích để thử đánh giá sự khác biệt lớn.

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 : Chẩn đoán đường dẫn và ứng dụng mạng

Máy chủ chẩn đoán tự động để khắc phục sự cố hệ thống cuối và các sự cố mạng cuối cùng. Sau khi chạy một loạt các bài kiểm tra, đưa ra một trang Tóm tắt kết quả như thế này . Tôi khuyên bạn nên sử dụng liên kết chuyển hướng máy chủ NPAD này để tìm máy chủ NPAD gần nhất (tất cả đều kết thúc) và sử dụng tên máy chủ đó cho các thử nghiệm của bạn.

  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

Kết quả cá nhân của tôi:

Tôi đã dành một vài giờ tốt để làm tất cả những điều này, thử những thứ khác nhau (chuyển từ phần mềm DD-WRT sang Tomato) và đọc. Hóa ra đó không phải là lớp mạng và là nhiễu RF cũ, chủ yếu là từ Bluetooth! Tôi đã có máy tính, chuột bluetooth và bàn phím trong vòng 5 feet từ bộ định tuyến. (Và bộ định tuyến cũ vẫn còn trên 2.4Ghz khi chúng xung đột.)

Đối với điều này, tôi đã tận dụng tối đa Kiểm tra tốc độ Wifi cho Android , chạy thường xuyên trong khi tôi di chuyển mọi thứ trong căn hộ. Vì nó báo cáo cập nhật cứ sau 200ms hoặc lâu hơn, nó thông báo rõ ràng khi nhiễu làm rơi các gói của tôi.

Tôi chắc chắn khuyên bạn nên đọc Hướng dẫn về Nguồn can thiệp chung từ Metageek. (Họ cũng làm cho InSSIDer và các công cụ phân tích Wifi khác có vẻ tốt.)

Một công cụ tôi không có là máy đo phân tích phổ vật lý. Điện thoại và máy tính xách tay chỉ có thể phát hiện các Wifi Wifi, nhưng không thể nhận được sự can thiệp từ Bluetooth hoặc các công nghệ dựa trên RF khác. Metageek có một số giải pháp hay trong không gian này ( Wi-Spy và inSSIDer Office ) và hy vọng chúng ta sẽ thấy nhiều công cụ hơn xuất hiện như AirShark .

Như đã lưu ý trong nhận xét của tôi ở trên: Các công cụ thường được sử dụng để chẩn đoán các sự cố Wi-Fi thực sự có thể gây ra sự cố này. Khi quét các mạng Wi-Fi, radio phải tắt kênh, thông thường, nó sẽ báo cho AP biết các khung đệm cho nó để nó có thể 'ngủ' sau đó chuyển kênh sang quét.

Ngoài ra, iOS và OS X kể từ khi AirDrop được giới thiệu, sẽ tắt kênh Wi-Fi để tìm các dịch vụ khác của AirDrop và vì Yosemite sẽ định kỳ tắt kênh để hỗ trợ chuyển giao.

Vì vậy, tôi cũng có những biến động ping Wi-Fi cho bộ định tuyến.

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

Tôi đã chuyển đổi bộ định tuyến (từ TL-WR743ND sang DIR-815), đã thử một số bộ điều hợp USB Wi-Fi (chủ yếu là TP-LINK, mặc dù tôi nghĩ rằng tôi cũng gặp vấn đề với D-Link DWA-160), từ 2,5 GHz đến 5GHz và quét các kênh. Không có may mắn, vấn đề vẫn tồn tại.

Cho đến khi tôi nhận thấy rằng khi tôi thực hiện kiểm tra tốc độ mạng hoặc chạy ứng dụng khách bittorrent thì ping đều ổn. Nó chỉ dao động khi mạng không hoạt động.

Có thể là sự cố Windows 7 hoặc sự cố với bộ điều hợp TP-LINK của tôi, nhưng khi tôi tải một chút về Wi-Fi, biến động sẽ biến mất và mạng hoạt động tốt.

Cho đến nay tôi đã thực hiện một chương trình Rust nhỏ để duy trì mạng Wi-Fi của mình.

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