Почему мой MacBook Pro имеет долгие времена ping по Wi-Fi?
У меня были проблемы при соединении с моим Wi-Fi. Это странно, времена ping к маршрутизатору (<на расстоянии в 30 футов), кажется, растут, часто заканчивая за 10 секунд до медленного возвращения вниз. Вы видите тенденцию ниже. Я нахожусь на MacBook Pro и сделал нормальный материал (сбросьте ДЕТСКУЮ КОЛЯСКУ и SMC, переключил беспроводные каналы, и т.д.). Это происходит через различные маршрутизаторы, таким образом, я думаю, что это должен быть мой ноутбук, но я не знаю, каково это могло быть.
RSSI оценивают парения приблизительно-57, но я видел зеркальное отражение скорости передачи между 0, 48 и 54. Мощность сигнала составляет ~60% с 9%-м шумом. В настоящее время существует 17 других беспроводных сетей в диапазоне, но только один в том же канале.
1 - Как я могу выяснить то, что продолжается?
2 - Как я могу исправить ситуацию?
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=254 time=781.107 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=254 time=681.551 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=254 time=610.001 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=254 time=544.915 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=254 time=547.622 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=254 time=468.914 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=254 time=237.368 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=254 time=229.902 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=254 time=11754.151 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=254 time=10753.943 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=254 time=9754.428 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=254 time=8754.199 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=254 time=7754.138 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=254 time=6754.159 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=254 time=5753.991 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=254 time=4754.068 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=254 time=3753.930 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=254 time=2753.768 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=254 time=1753.866 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=254 time=753.592 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=254 time=517.315 ms
64 bytes from 192.168.1.1: icmp_seq=37 ttl=254 time=1.315 ms
64 bytes from 192.168.1.1: icmp_seq=38 ttl=254 time=1.035 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=254 time=4.597 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=254 time=18010.681 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=254 time=17010.449 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=254 time=16010.430 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=254 time=15010.540 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=254 time=14010.450 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=254 time=13010.175 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=254 time=12010.282 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=254 time=11010.265 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=254 time=10010.285 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=254 time=9010.235 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=254 time=8010.399 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=254 time=7010.144 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=254 time=6010.113 ms
64 bytes from 192.168.1.1: icmp_seq=34 ttl=254 time=5010.025 ms
64 bytes from 192.168.1.1: icmp_seq=35 ttl=254 time=4009.966 ms
64 bytes from 192.168.1.1: icmp_seq=36 ttl=254 time=3009.825 ms
64 bytes from 192.168.1.1: icmp_seq=40 ttl=254 time=16000.676 ms
64 bytes from 192.168.1.1: icmp_seq=41 ttl=254 time=15000.477 ms
64 bytes from 192.168.1.1: icmp_seq=42 ttl=254 time=14000.388 ms
64 bytes from 192.168.1.1: icmp_seq=43 ttl=254 time=13000.549 ms
64 bytes from 192.168.1.1: icmp_seq=44 ttl=254 time=12000.469 ms
64 bytes from 192.168.1.1: icmp_seq=45 ttl=254 time=11000.332 ms
64 bytes from 192.168.1.1: icmp_seq=46 ttl=254 time=10000.339 ms
64 bytes from 192.168.1.1: icmp_seq=47 ttl=254 time=9000.338 ms
64 bytes from 192.168.1.1: icmp_seq=48 ttl=254 time=8000.198 ms
64 bytes from 192.168.1.1: icmp_seq=49 ttl=254 time=7000.388 ms
64 bytes from 192.168.1.1: icmp_seq=50 ttl=254 time=6000.217 ms
64 bytes from 192.168.1.1: icmp_seq=51 ttl=254 time=5000.084 ms
64 bytes from 192.168.1.1: icmp_seq=52 ttl=254 time=3999.920 ms
64 bytes from 192.168.1.1: icmp_seq=53 ttl=254 time=3000.010 ms
64 bytes from 192.168.1.1: icmp_seq=54 ttl=254 time=1999.832 ms
64 bytes from 192.168.1.1: icmp_seq=55 ttl=254 time=1000.072 ms
64 bytes from 192.168.1.1: icmp_seq=58 ttl=254 time=1.125 ms
64 bytes from 192.168.1.1: icmp_seq=59 ttl=254 time=1.070 ms
64 bytes from 192.168.1.1: icmp_seq=60 ttl=254 time=2.515 ms
2 ответа
В более ранних ноутбуках Mac было легко достигнуть карту Wi-Fi (только под легко открытой клавиатурой), я не знаю, верно ли это все еще.
Если бы это, я рекомендовал бы отключить и повторно включить коннектор к той карте. В минувшие годы у других были проблемы как это, которые были решены путем переустановки того коннектора.
Тот вывод ping является сумасшедшим. Это ни на что не похоже, проходит в течение 16-18 секунд, и затем внезапно все это проникает сразу. Даже если бы были проблемы с 802.11n агрегирование кадра и Блок Acks, то я не ожидал бы, что все будет поставлено в очередь, и оставался бы с очередями в течение 18 секунд, и затем внезапно все проникают. Также очень странно видеть неисправные пакеты в сети единственного транзитного участка.
У Вас есть доступ к анализатору спектра, такому как Метафанат Тонким? Если Вы используете полосу на 2,4 ГГц, 99$, Тонкие 2.4i, забавная вещь иметь, и очень полезный для наблюдения, если микроволновая печь Вашего соседа выводит всю полосу из строя в течение нескольких секунд за один раз.
Между прочим, сделайте ifconfig en1 и удостоверьтесь, что Вы не видите PROMISC в списке интерфейсных флагов. Некоторые беспроводные карты не обрабатывают неразборчивый режим очень хорошо. Даже если Вы не выполните вещи как tcpdump и Wireshark, то иногда плохо записанные сетевые приложения случайно установят promscuous режим, когда они действительно не значили для, потому что они выполнили неправильные вызовы к libpcap или BPF.
- Какую версию Mac OS X Вы выполняете?
- Какова делать/моделировать/версия оборудования/версия микропрограммного обеспечения из Вашей точки доступа?
- Актуально встроенное микропрограммное обеспечение на Вашей точке доступа?
- У Вас просто есть одна точка доступа в это время, или у Вас есть несколько APS "расширением сети" с помощью беспроводных технологий?
Я знаю, что Вы попробовали различные каналы, но Вы попробовали различные полосы? Например, при выполнении этого всего в полосе на 2,4 ГГц - каналы 1-11, плюс, возможно, 12, 13, и даже 14 в некоторых регионах - было бы интересно знать, уходит ли проблема при переключении AP на полосу на 5 ГГц (канал 36 и выше).
На Snow Leopard можно выполнить это для включения большого количества журналов отладки AirPort:
sudo /usr/libexec/airportd debug +AllUserland +AllVendor +AllDriver
Затем наблюдайте то, что зарегистрировано к /var/log/kernel.log и /var/log/system.log.
Leopard не имеет такого же входа для этого, но можно включить его как это:
sudo /usr/libexec/airportd -d
Leopard не имеет отдельного kernel.log, таким образом, он будет, вероятно, все переходить к system.log.
Проблема уходит, когда Вы подключены к адаптеру питания переменного тока в противоположность батарее? Современные ноутбуки Mac автоматически включают 802,11 powersave режима когда на батарее. Режим Powersave может увеличить задержку некоторые; обычно на порядке 100 мс, даже целая секунда. Но все еще было бы интересно знать, имеет ли выполнение от питания переменным током значение.