Я бачу нестабільні та інколи дуже довгі часи пінг-файлу до мого wifi-роутера, це лише один скачок. Пінгінг 192.168.1.1іноді дає затримки в 400-800 мс затримок.

Можна спробувати багато чого (мікропрограмне забезпечення, розміщення маршрутизатора, канал AP тощо), але я хотів би трохи більш методично атакувати цю проблему:

• По-перше, як я можу уявити продуктивність своєї мережі?
• Потім, як я можу порівняти продуктивність заданої конфігурації, щоб я міг надійно порівняти після внесення змін?

Ця відповідь за замовчуванням на сервері має гарне керівництво на високому рівні щодо того, що робити - тому почніть з цього. Цей останній крок є справжнім духом: мабуть, ви (я маю на увазі, я) не хочете вкладати кошти у спеціальне обладнання для цього ...

Нижче наведено кілька хороших інструментів, спочатку для розуміння стану здоров'я підключення в локальній мережі Wi-Fi, а потім до кінцевої точки Інтернету.

Інструменти Wi-Fi

NetSpot (для Mac)

Він відстежує локальні AP-адреси WiFI та надає основні дані, такі як SNR, канал, сила сигналу. Він також може зробити базовий огляд місця для фізичного простору із зазначенням сильних сторін та перешкод. У режимі виявлення AP можна також графікувати силу сигналу з часом, що дозволяє перевірити місця розташування та коригувати можливості перешкод.

Тест швидкості Wifi для Android

Дуже корисний. На вашій машині ви запустите простий сервер python, і додаток може перевірити декілька сценаріїв, що дасть вам зворотній зв'язок у режимі реального часу.

Wifi Analyzer , ще одне чудове додаток для Android, має кілька цінних уявлень про те, які Wi-Fi канали AP є активними. Можливо, це буде найкращим безкоштовним інструментом для вибору каналу AP, не роблячи багато роботи.

iPerf

Добре поважається інструмент для розуміння продуктивності локальної мережі. Вам потрібно два поля, одне як сервер, а одне як клієнт. Ви можете встановити ряд параметрів, провести тест і побачити результати пропускної здатності та тремтіння. Я дозволю використовувати його з графічним інтерфейсом jPerf для графіків результатів та налаштування параметрів.

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 (комбінований пінг і 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) та читаючи. Виявляється, це був не мережевий шар, і це було гарне старе ВЧ-втручання, в основному від Bluetooth! У мене був комп'ютер, Bluetooth-миша та клавіатура в межах 5 футів маршрутизатора. (І старий роутер все ще на 2,4 ГГц, де вони стикаються.)

Для цього я отримав максимальну користь від тестування швидкості Wifi для Android , який регулярно запускався, коли я пересував речі в квартирі. Оскільки він повідомляє про оновлення кожні 200 м або близько того, він чітко повідомляв, коли втручання скидало мої пакети.

Я напевно рекомендую прочитати посібник із загальних джерел перешкод від Metageek. (Вони також роблять InSSIDer та інші інструменти аналізу Wi-Fi, які здаються непоганими.)

Одним із інструментів у мене не був вимірювач фізичного спектру. Телефони та ноутбуки можуть виявляти лише AP-адреси Wifi, але не можуть перешкоджати перешкодам через Bluetooth або інші технології на основі РФ. Metageek має кілька приємних рішень у цьому просторі ( Wi-Spy та inSSIDer Office ), і, сподіваємось, ми бачимо, що з'явиться більше інструментів, таких як AirShark .

Як зазначено в моєму коментарі вище: Інструменти, які зазвичай використовуються для діагностики проблем з Wi-Fi, насправді можуть викликати цю проблему. Під час сканування мереж Wi-Fi радіо повинен вийти з каналу, як правило, він повідомляє AP до буфера кадрів для нього, щоб він міг «спати», а потім перемикав канали на сканування.

Крім того, iOS та OS X з моменту введення AirDrop візьмуть вимкнений канал Wi-Fi для пошуку інших служб AirDrop і оскільки Yosemite періодично буде виходити з каналу для підтримки передачі даних.

Тож у мене були й такі курси коливань Wi-Fi до маршрутизатора.

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 ГГц до 5 ГГц і проскакував канали. Не пощастило, проблема зберігалася.

Поки я не помітив, що коли я роблю тест на швидкість роботи мережі або запускаю бітторент-клієнт, пінг все в порядку. Він коливається лише тоді, коли мережа працює в режимі очікування.

Це може бути проблема 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));}}