Realtek уходит в downshift: скорость падает до 100 Мбит
Проводное подключение падает до 100 Мбит, сеть отваливается и возвращается только после нескольких попыток? В журнале видно Link is Up - 100Mbps/Full (downshifted) и череда Link is Down → dhcp4: state changed no lease? Причина физическая: деградировавший кабель или коннектор. Гигабиту нужны все четыре пары жил, а при плохом контакте чип Realtek снижает скорость до 100 Мбит. Если контакт совсем скверный, даже 100 Мбит не держатся. Плюс конфликт двух менеджеров сети мешает DHCP завершиться.
Почему Realtek уходит в downshift: физика вопроса
При старте чип r8169 поднимает гигабит. Ядро проверяет качество линии и видит: одна или несколько пар не работают. PHY снижает скорость до 100 Мбит (ему хватает двух пар). Но контакт настолько плохий, что линк флейпует: Link is Up сменяется Link is Down через секунду. Каждый обрыв отменяет DHCP-транзакцию. Система пытается, обрывается, пытается снова. Иногда сеть «ловится» с пятой-шестой попытки, иногда не ловится вообще.
Типичная картина в journalctl:
Link is Up - 100Mbps/Full (downshifted)
Link is Down
dhcp4 (enp42s0): state changed no lease
Link is Up - 100Mbps/Full (downshifted)
Link is Down
Прогрессия 100M нестабилен → держится только 10M означает линию, которая ухудшается. Тянуть с заменой кабеля нельзя.
Как диагностировать downshift проводной сети
Смотрим историю загрузок
Список последних бутов покажет, когда проблема появлялась:
journalctl --list-boots --no-pager | tail -4
Ищем строки с сетевым интерфейсом в прошлом буте
Забираем логи предыдущей загрузки и фильтруем по имени интерфейса или драйверу:
journalctl -b -1 --no-pager | grep -iE 'enp42s0|r8169'
Если в выводе видны downshifted, Link is Down, check cabling! … корневая причина на поверхности. Проблема физическая, а не программная.
Проверяем скорость линии мимо приложений
Быстрый тест через curl к Cloudflare. Данные гоняются по проводу напрямую, минуя браузер и его расширения:
curl -s -o /dev/null -w "%{speed_download}" --max-time 10 \
"https://speed.cloudflare.com/__down?bytes=80000000"
Результат в байтах/сек. Делим на 1 000 000, получаем мегабайты. Норма для гигабита: ~100–110 МБ/с. Если видите 10–12 МБ/с … линия держит 100 Мбит. Если ещё ниже … 10 Мбит, линия умирает.
Как исправить: замена кабеля и один менеджер сети
Шаг 1. Замените патч-корд
Это физика, и софтом её не почините. Берёте Cat5e или Cat6, меняете кабель ПК → роутер. Запасного нет? Переткните оба конца, попробуйте другой порт на роутере. Часто помогает именно переподключение.
Шаг 2. Оставьте один менеджер сети
На многих Arch-системах одновременно работают NetworkManager и systemd-networkd. Они конфликтуют за DHCP-сокет. Когда линк флейпует, оба хватают интерфейс, и ни один не завершает транзакцию нормально.
Оставляем NetworkManager и глушим systemd-networkd со всеми юнитами:
sudo systemctl disable --now systemd-networkd.service \
systemd-networkd.socket systemd-networkd-resolve-hook.socket \
systemd-networkd-varlink.socket systemd-networkd-varlink-metrics.socket \
systemd-networkd-persistent-storage.service systemd-networkd-wait-online.service
⚠️ Ловушка. Если отключить только systemd-networkd.service, сокеты останутся активными. Статус activating на сокете продолжит мешать. Гасить нужно все юниты одним списком, как выше.
Шаг 3. Проверяем результат
systemctl is-active systemd-networkd # inactive
nmcli -f DEVICE,STATE device
ping -c2 8.8.8.8
systemctl is-active покажет inactive, nmcli покажет состояние интерфейса, ping подтвердит, что пакеты ходят.
Типичные ошибки при диагнозе
«Попробую переустановить драйвер». Драйвер r8169 живёт в ядре, его не надо переустанавливать. Проблема не в нём.
«Настрою static IP, чтобы DHCP не отваливался». Статика уберёт гонку за DHCP, но не решит флейпинг линка. Интерфейс по-прежнему будет падать в Link is Down.
«Пропишу скорость вручную через ethtool». Форсирование скорости не заставит PHY игнорировать плохой контакт. Ядро сбросит обратно на автоматический выбор.
Частые вопросы
Как понять, что проблема именно в кабеле, а не в драйвере?
Строка check cabling! в выводе journalctl -b -1 | grep -iE 'enp42s0|r8169' однозначно указывает на физический уровень. Драйвер r8169 в ядре стабилен, проблемы с ним бывают крайне редко.
Можно ли проверить скорость линии без браузера?
Конечно. Команда curl -s -o /dev/null -w "%{speed_download}" --max-time 10 "https://speed.cloudflare.com/__down?bytes=80000000" гоняет данные по проводу напрямую. Результат покажет реальную пропускную способность линии.
Что значит (downshifted) в логе ядра?
Чип Realtek сообщает: «хотел гигабит, но линия не тянет, переключился на 100 Мбит». Если скорость продолжает падать до 10 Мбит, кабель нужно менять срочно.
Два менеджера сети в системе … это нормально?
Нет. NetworkManager и systemd-networkd конфликтуют за управление интерфейсами и DHCP. Выберите один. Проверить текущую ситуацию: nmcli -f DEVICE,STATE device и systemctl is-active systemd-networkd.
Заключение
Downshift на Realtek r8169 почти всегда физика: кабель, коннектор, порт роутера. Замена патч-корда на Cat5e/Cat6 решает проблему в большинстве случаев. Параллельно убедитесь, что в системе работает только один менеджер сети, а не два одновременно. Команды из статьи помогут отличить аппаратную проблему от программной за пару минут.
Полезные ресурсы
- NetworkManager (ArchWiki): настройка и управление сетью
- Network configuration (ArchWiki): общая настройка сети в Arch Linux
- Wi-Fi через wpa_supplicant: настройка беспроводной сети вручную
- Драйвер NVIDIA в Arch Linux: установка проприетарных драйверов
- Зависания при высокой нагрузке CPU: исправление фризов
Не получилось? Поможем настроить
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии