Вопросы Теги

Неустойчивые времена ping на точке доступа Wi-Fi пи малины

Прямая выборка от гну исправляет страницу справочника:

   -p<num>  or  --strip=num
      Strip the smallest prefix containing num leading slashes from each file name found in the patch file.  A sequence of  one  or  more  adjacent
      slashes  is  counted  as  a single slash.  This controls how file names found in the patch file are treated, in case you keep your files in a
      different directory than the person who sent out the patch.  For example, supposing the file name in the patch file was

         /u/howard/src/blurfl/blurfl.c

      setting -p0 gives the entire file name unmodified, -p1 gives

         u/howard/src/blurfl/blurfl.c

      without the leading slash, -p4 gives

         blurfl/blurfl.c

      and not specifying -p at all just gives you blurfl.c.  Whatever you end up with is looked for either in the current directory, or the  direc-
      tory specified by the -d option.
6
12.02.2013, 06:26
3 ответа

Вы получаете то же поведение с ним в сети как просто клиент? Я не протестировал его в таком же количестве деталей, как Вы, но мое пи склонны немного это слишком иногда; я только имел его несколько недель и приписывал его 8192cu драйвер, который является glitchy другими способами - например, это не будет работать над концентратором питания, только при прямом включении в.

Значение аппаратного ключа должно быть на одном из недостаточно мощных USB-портов пи - они поставляют самое большее 140 мА вместо стандарта USB 2.0 500 мА (см. здесь) - то, которое я думаю, должно сделать устройство Wi-Fi подверженным проблемам. У меня есть он проверяющий с помощью ping-запросов маршрутизатор каждые пять секунд и когда ping перестал работать, это снова соединяется (я не использую NetworkManager или любого системного демона, который обычно обрабатывал бы это... так или иначе, если это снова соединяется сразу же, требуется ~15 секунд); при рассмотрении журнала для этого, это произошло 3 раза за прошлые 30 часов, который не так плох, но это ничего не делало также. В пятницу я компилировал на нем через ssh (так, maxing процессор непрерывно в течение долгого времени), и это часто происходило (возможно, каждые 5-10 минут? к счастью, это просто замораживает ssh i/o некоторое время).

Я могу закончить тем, что получил более раскормленный адаптер, который будет работать над концентратором питания, если это останется проблемой. Если Вы хотите использовать его в качестве точки доступа, я думаю, что необходимо определенно использовать концентратор внешнего питания, если Вы уже не. По-видимому, им свойственно не быть отрегулированным внутренне, таким образом, каждый порт может потянуть глубоко способность (2-4 ампера) и не только 500mA, означая, что можно также привести в действие пи от него; некоторые неявные ссылки на это здесь. Я имею один из концентраторов belkin и получаю приблизительно на 0.05-0.1 вольта меньше на концентраторе, чем на зарядном устройстве на 2 А 5 В. Теперь, с адаптером Wi-Fi, включенным пи (и это - крошечное маленькое нано), это получает еще на 0.05-0.1 вольта меньше, который весьма значителен, так как оптимальный диапазон 4.75-5.25V - согласно моему мультиметру, я прав у основания этого на концентраторе с нано адаптером, когда неактивный.

Я предположил бы работу над g требования сети меньше от адаптера Wi-Fi, так как это медленнее, чем n.

О, и BTW там является обменом стопки rpi :)

1
27.01.2020, 20:27
  • 1
    Спасибо за подсказку относительно обмена стека rpi - я попробую оба форума теперь, когда я запустил здесь. –  Ivo 12.02.2013, 00:34
  • 2
    я не верю проблеме, связан с питанием. Мне действительно включали адаптер Wi-Fi непосредственно в USB-порт пи, однако пи предоставляется через хорошее предоставление, и я изменил проводное соединение так, чтобы входная мощность к пи была также направлена непосредственно к контактам питания на коннекторах usb. Но быть уверенным я попробовал включенным, и результаты, кажется, существенно не отличаются. Я не думаю, что у меня были те же проблемы, когда у меня было пи, действующее в качестве клиента в нашей сети. Трудно знать наверняка, потому что наш маршрутизатор подвергается регулярному сбросу по некоторым причинам. –  Ivo 12.02.2013, 01:05
  • 3
    я действительно намереваюсь возвратиться и загрузить мое изображение, которое имело клиентскую конфигурацию для наблюдения то, что я могу изучить с тестами ping, но я это будет менее очевидно как больше 'блоков', вовлечен в схему ping. В данный момент все, что я имею, является моим клиентом ноутбука и пи с приводимым в действие концентратором и Digitech привет аппаратный ключ питания. У меня даже нет соединения Ethernet. Я замечаю, что, если у меня нет ssh, выполнение типичных ответов 2-4ms с пакетами обычно 80-110-90ms влияние на 3 или 4 последовательных 1 второй ping. К тому же будет случайный тайм-аут - который я думаю, приблизительно 5 секунд. вышеупомянутое –  Ivo 12.02.2013, 01:05
  • 4
    все работает в режиме g. Если я запускаю сессию оболочки, нет никакого различия. Однако, если я затем загружаю процессор рабочей вершиной в интервалах 0,01 секунд, типичная задержка ping снижается приблизительно до 1 мс. Конечно, это варьируется, но Вы получаете довольно хорошее впечатление, что задержка приблизительно сократилась наполовину. Наложенный к тому же 3 или 4 последовательных пакета, как описано выше. Мое чувство состоит в том, что существует своего рода продолжение конфликта; пакеты более длительного появления задержки, когда ping прибывает, когда некоторая другая конфликтующая задача работает. –  Ivo 12.02.2013, 01:05
  • 5
    @man Ivo: взгляните на man nice если Вы не знаете о нем: en.wikipedia.org/wiki/Nice_%28Unix%29. Запустите hostapd вручную в-10; если это работает, можно вставить init сценарий. ползунки –  goldilocks 12.02.2013, 14:52

У меня были те же проблемы с различными палками Wi-Fi на моей малине. Я попробовал различные источники питания, другой Raspberrys и также активный концентратор USB. Таким образом, мне посчастливилось видеть Ваше наблюдение, тот Wi-Fi отключения 'n' режим, wmm и ht_capab мог привести к лучшим результатам. Я отключил n-режим и wmm на моем маршрутизаторе Wi-Fi RT-N66U Asus (выполнение openwrt/tomato), и время ping уменьшается от 10-100ms до 1-3ms, и соединение было очень стабильно. Перед этим соединение понижалось очень часто (после 30-60min) и, где очень медленный в целом.

Но отключение n-режима для полной сети Wi-Fi не могло быть решением, таким образом, я нахожу другую рекомендацию (https://github.com/xbianonpi/xbian/issues/217):

  • Создайте файл /etc/modprobe.d/8192cu.conf который содержит строку:

    options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

  • Перезагрузка

Это выключает экономию электроэнергии палки Wi-Fi, и USB автоприостанавливают.

  • Можно проверить, выключен ли режим экономии электроэнергии:

    cat /sys/module/8192cu/parameters/rtw_power_mgnt

С 24 часов соединение Wi-Fi стабильно теперь на двух различных Ягодах малины. Времена ping немного больше (5-6 мс), чем отключение n-режима и wmm на маршрутизаторе Wi-Fi, но очень стабильны и только с маленькими изменениями.

6
27.01.2020, 20:27

У меня была такая же проблема с моим Pi и модулем 8192cu , и я не мог получить ни одного из этих предложений по устранению проблемы.

В конце концов, отчаявшись, я проверил, какие еще точки доступа Wi-Fi были активны в этом районе, и, к моему удивлению, сосед установил новую сеть Wi-Fi на том же канале, что и мой. Переключение на другой канал устранило проблему!

Нет больше 20 000 мс пингов или 40% потери пакетов, отлично! Иногда самые простые решения оказываются самыми сложными: -)

0
27.01.2020, 20:27

Теги

Похожие вопросы