Лаги на адаптере ATH9k

А Ты уверен, что проблема в драйвере, а не в сетевом менеджере?

Ох, ну, скажем так, есть вероятность, что это проблема NM, и я уже пробовал менять его на WICD на этой версии Debian и на connman, но первый выдаёт ещё более долгие лаги, а второй очень медленную скорость соединения.

Я читал, что в случае с NM есть два варианта решить эту проблему - это использовать патченный NM-noscan, до которого у меня не дошли руки, и который я считаю диким костылем. Если уж есть такая проблема с NM, то этот патч давно должен быть в Debian, а нашёл я его в AUR, если не ошибаюсь. И второй - это указать BSSID в настройках точки доступа NM, но я это делал и это не помогает.

Вчера я попробовал установить firmware-atheros из Debian Stretch - лаги остались, но соединение прыгало до 60мс, а не до 500мс. Понаблюдаю ещё - возможно, это решит проблему.

Покажи dmesg. Что-то мне кажется, что проблема в ядре.

Прошу

Пока нашел такую хрень:

 wlp6s0: renamed from wlan0 

Но, похоже, не в этом проблема. Я думаю, стоит попробовать другое ядро.

Дописал параметр в grub, теперь система мучительно запускает интерфейс целых полторы минуты.

К сожалению, не вариант. У меня liquorix-ядро, нужно мне для работы с аудио. У этих ядер проблема со сборкой модулей графики, варьируется от версии к версии. Где-то собирается, где-то нет.

Например, для 5.0 liquorix собирается dkms-ядро невидии, а на 5.2 уже нет.

Но проблема изчезла? Хотя, ценой такого тупняка я бы эту проблему не решал.

Забавно, что интерфейс переименовался в wlan0, но при старте как бы включатся wlp6s0 И не запускается, конечно, потому что его уже нет

Значит, это не вариант. Убирай эту строчку из граба нафиг. На мой взгляд, дело в ядре. Но что же делать со сложностями с заменой ядра? Это же патч, правильно? Посмотри, есть ли он для последних lts-ядер (4.19, 5.4).

У меня liquorix-ядро, нужно мне для работы с аудио.

И прям серьезно есть какой-то профит, ради которого стоит терпеть вот это все?

Мб стоит включить старое именование ?
net.ifnames=0

Кстати, да. Для аудио можно и RT-ядро заюзать. С RT-патчем полегче будет.

Так я это уже сделал, написал выше. Особого результата по лагам это не дало, а система пытается включить интерфейс со старым именем при старте.

На самом деле, да.

Ладно, поищи патч для lts-ядер. И подумай над возможностью переходя на обычное rt-ядро.

Собственно, ситуация следующая - я перебрал несколько разных ядер, и вспомнил, почему остановился на liquorix 5.0. Дело в том, что стандартное rt-ядро Debian (4.19) не работает с дровами nvidia из все тех же репозиториев, и dkms тупо не собирает модуль. Много где писали об этом. Речь именно о проприетарных дровах, не о noveau. В принципе, в игры я не играю, поэтому, возможно, я попробую переключиться на них.

Тем временем, я попробовал запуститься с стандартного ядра 4.19 (не rt) из Debian Buster - лаги есть, но как будто меньше.

Можешь попробовать 5.4. а ситуация, конечно, сложная.

И подумай, все таки, над переходом на RT.

Возможно, тут ситуция, где просто нужно подобрать работающее ядро методом научного тыка.

Я перебрал все доступные для Buster Liquorix, включая 5.4. Невидия заводится только на 5.0.

Ну и кстати, liquorix так-то тоже rt-ядро.

Попробуй обычное ядро. БЕЗ ПАТЧЕЙ! Просто посмотри, что будет.

Пробовал. Результат чуть лучше, хотя небольшие лаги есть.

Какую версию ядра пробовал?

Вот нашел рекомендацию в топике про ath9k

If you are affected by the bug you should check that your AP has unicast rekeying disabled to mitigate the problem. (Group rekeying is fine.)

У меня есть телефон, который каждые 50 секунд терял пакеты. На роутере покрутил сие значение и всё наладилось. Правда не на всех роутерах есть возможность крутить.

Можно чуть более развернуто? Мне реально интересно, потому что я никаких проблем на "стоковом" ядре при работе с аудио не замечаю.

Так это не для решения проблем. ТС бьется за дополнительные пару ms отклика.

Так в чем проблема использовать патч rt и поигратся с частотой таймера?

Экспериментально ТС установил, что ядро без этого стремного патча работает лучше. Знать бы еще версию, которую он пробовал. Опять же, если нужно уменьшать латентность, то можно патчить rt-патчем, игратся с таймером и CPU-sheduler.

Это я понимаю, у меня на лаптопе в самой прям дефолтной конфигурации всего с пульсой задержка 6-7 мс. Ни буферы, ни конфигурацию звуковой подсистемы, ни ядра я не трогал. Этого значения в целом даже для мониторинга будет вполне достаточно, а уж для записи и подавно.

Хм, ну, да, это:

bdfy

ТС бьется за дополнительные пару ms отклика.

И я не для пульсы бьюсь, а для JACK'а.

«Стабильное» ядро в Debian Buster это 4.19. Как обычное, так и rt. Как я писал выше, с rt не получается использовать проприетарные драйверы nvidia. Об этом писали, например, тут (извиняюсь, ссылка на кэш, потому что сам сайт у меня не открывается), еще касательно Debian 9.5

Ради интереса, оставлял соединение влюченным на полтора-два часа в Discord'е, с подключением к российскому серверу - лаги бывают, но до 150мс. То есть не до 300-500мс, как раньше. И реже, что любопытно.

Это ядро 5.0 liquorix и firmware-atheros из Debian Stretch.

Вот это посмотрю, спасибо

Я не исключаю, что проблема в моём микротике, у меня с ним были уже некоторые приколы - тот же телефон, подключаясь, мог ловить очень медленную связь, при том, что подключен к 5гц-сети и никаких дополнительных настроек я в роутере не крутил. Спустя некоторое время проблема исчезала, как ни в чём не бывало.

Твою дивизию, вот я реально что-то не понятно пишу, или это тайна такая сказать сколько реально миллисекунд ты выиграл на кастомном ядре?!

Нет, я тупо не замерял просто =)

Я этими ядрами начал пользоваться еще на Debian 8, и тогда это уменьшило количество xrun’ов в сессиях Ardour. Только вот сейчас я переехал с Ardour на REAPER и не особо ощущаю выйгрыш от использования ядра, а пользуюсь по-инерции. Ну и да, руки не доходят проверить работу JACK’а с REAPER’ом на обычном ядре.

Микротик это хорошо. Крутилок там полно. Ath9k по 5GHz цепляется ?

Ath9k по 5GHz цепляется ?

Верно

Да, крутилок там так много, что чёрт ногу сломит, пытаясь настроить.

Но ничего, поищу еще. Пока что нашел Unicast Ciphers.

«Стабильное» ядро в Debian Buster это 4.19. Как обычное, так и rt.

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

В общем, в бекпортах в buster ядро 5.4 и похоже именно его надо использовать, если нет каких-то веских причин остановиться на 4.19

Правда ath9k - это уже совсем не новое железо, просто регрессия похоже.

У меня еще есть TP-Link Archer T9E, который на BCM4360 основан, вот его можно попробовать завести, но в последний раз, когда я пробовал, дрова к нему были таким лютым говном, что я воткнул обратно свой адаптер на ath9k (не помню как сам адаптер зовётся) и успокоился.

https://i.imgur.com/vPH7R0C.png
тут значение час, например, поставьте.

А, ну у меня и так там 45 минут было.

тогда хз. мб стоит пошаманить с регионом, например включив US.

Итак, проблема не решилась, поэтому, я решил, что это не проблема. Лаги в подключении так и не исчезли, но, поскольку я не играю в игры и не пользуюсь голосовыми чатами, то, в принципе, жить можно.

Однако, я все-таки решил сменить старый адаптер на новый, который основан на чипе Broadcom (о чем я писал тут, но ошибся моделью адаптера - не T9E а T6E), и потерпел неудачу, потому что драйвер оказался ужасен. К сожалению, я вынужден создать еще одну тему, потому что разруливать эти проблемы тут смысла нет.

Ссылка на продолжение истории