Ethtool: как изменить скорость, дуплекс и находить неполадки сетевой карты в Linux
Конфигурация вашей сетевой карты напрямую влияет, насколько эффективно взаимодействуют ваши сервера.
Необходимо понимать, как настройки автосогласования, скорости и дуплекса влияют на передачу данных, чтобы успешно поддерживать сетевое соединение. А также расскажем про дополнительные фичи, которые помогут находить и устранять сетевые неполадки.
В этой статье вы узнаете, как изменить настройки скорости, дуплекса и автосогласования в Linux с помощью команд ethtool .
Что такое полудуплекс, полный дуплекс и автосогласование?
Полудуплексный режим (Half-duplex) позволяет устройству отправлять или получать пакеты по очереди. Устройство, установленное в этот режим, не может выполнять оба действия одновременно.
Когда режим устройства находится в полнодуплексном режиме (Full-duplex), он также может отправлять и получать пакеты одновременно.
Автосогласование (Auto-Negotiation) — это механизм, с помощью которого устройство автоматически выбирает наиболее эффективный режим передачи на основе характеристик своих аналогов. Рекомендуется оставить автосогласование включенным, поскольку оно позволяет устройствам выбирать наиболее эффективные средства для передачи данных.
Что такое дуплексное несоответствие?
Такое происходит когда устройство с включенным автосогласованием подключается к устройству, которое не использует автосогласование. Конец соединения с активным автосогласованием все еще может определить скорость другого конца, но не может правильно определить дуплексный режим. Как правило, конец соединения с автоматическим согласованием будет использовать полудуплекс, тогда как другой конец может быть в дуплексном режиме. Эта ситуация считается дуплексным несоответствием (duplex mismatch).
Несоответствие дуплекса не прекращает связь полностью. Передача отдельных пакетов и небольших объемов данных не вызывают больших проблем. Однако при отправке большого объема данных с любого конца скорость значительно падает. Соединение работает, но производительность снижается, поскольку скорость передачи данных асимметрична и может привести к потере пакетов.
Как использовать команду Ethtool для настройки параметров сетевого адаптера
Ethtool — это команда конфигурации платы сетевого интерфейса, которая позволяет вам получать информацию и изменять настройки сетевого адаптера. Эти настройки включают скорость, дуплекс, автосогласование и многие другие параметры.
Помимо этого, ethtool используется для:
- Получения идентификационной и диагностической информации
- Получения расширенной статистики устройства
- Контроля контрольной суммы
- Контроля размеров кольца DMA и модерации прерываний
- Контроля выбора очереди приема для устройств с несколькими очередями
- Обновления прошивки во флеш-памяти
Для установки ethtool используйте следующие команды:
Чтобы продолжить, вам нужно знать имя вашей сетевой карты.
Чтобы найти имя вашей сетевой карты, введите в командном терминале следующую команду:
Вывод покажет нам имя сетевой карты устройства.
Теперь, когда вы определили имя устройства, проверьте текущие настройки скорости, автосогласования и дуплексного режима с помощью команды: ethtool имя_устройства .
В нашем конкретном примере команда выглядит так:
Выходные данные показывают, что текущая скорость равна 1000 Мбит/с, что дуплекс находится в режиме «Full», и что автосогласование включено.
Изменение настроек сетевого адаптера
Команда ethtool –s может использоваться для изменения текущих настроек путем определения значений скорости speed , дуплекса duplex и автосогласования autoneg в следующем формате:
Например, чтобы установить скорость 1000 Мбит/с, дуплексный режим — «полный», а автоматическое согласование — «включено», команда будет выглядеть так:
Команда ethtool [имя_устройства] необходима для подтверждения того, что изменения были применены.
Сохранение настроек
Изменения, сделанные с помощью Ethtool, по умолчанию отменяются после перезагрузки системы.
Чтобы применить пользовательские настройки при каждой загрузке системы, отредактируйте файл для интерфейса устройства:
Добавьте нужные значения в виде строки в конце файла, используя следующий синтаксис:
Вывод этой команды будет выглядеть так:
Использование приведенной выше команды — отличный способ устранения проблем с конкретной сетевой картой.
Физическое расположение конкретного сетевого адаптера
Вот действительно полезный трюк, который предлагает ethtool : допустим у вас есть сервер с несколькими сетевыми картами, и одна из них работает со сбоями, но вы не уверены, какая именно это карта. Вы можете использовать ethtool , чтобы заставить мигать индикатор сетевого адаптера, чтобы определить, какой сетевой адаптер вам нужен. Скажем, если вы хотите мигать светодиодом устройства Ethernet enp0s3 в течение 15 секунд — команда для этого будет выглядеть так:
Светодиод начнет мигать, чтобы вы знали, с какой картой вы имеете дело.
Тестирование сетевой карты
Команда ethtool предлагает пару удобных тестов, которые вы можете запустить на сетевой карте:
- Online — тесты nvram и тест ссылок
- Offline — тестирует регистр, память, loopback, прерывание
Давайте запустим онлайн-тест на нашей сетевой карте. Эта команда выглядит так:
После выполнения команда покажет нам результаты:
Учтите, что некоторые устройства не поддерживают offline тестирование.
Информация о драйвере
Чтобы узнать имя драйвера и связанную информацию о драйвере используйте:
Заключение
Следуя этому руководству, вы успешно изменили настройки своей сетевой карты с помощью команд ethtool . Вы также лучше поняли, как режимы автосогласования и дуплекса влияют на производительность сервера. И заодно узнали пару интересных функций команды ethtool .
Много dropped пакетов на интерфейсе.[linux]
Господа, подскажите чем может быть вызвано такое кол-во дропнутых пакетов? Я так понимаю что если бы была проблема в физической передаче сигнала (кабель хреновый то было бы много error`ов. Куда вообще копать?
ethtool более подробную статистику показывает
Решил проверить, у меня, оказывается, тоже куча dropped. Присоединяюсь к вопросу.
Из доп. инфы, на этом интерфейсе где-то неделю-две назад кольцо было в прилежащей к нему сети, возможно этим dropped и обусловлено.
Нашёл вроде баг в багзиле редхата. http://bugzilla.redhat.com/show_bug.cgi?id=484667
Но он пофикшен стопицот лет назад. Да и рядом у меня пачка таких же серверов на том же ядре работают без сбоев.
$ uname -a
Linux ***********.ru 2.6.32-220.7.1.el6.x86_64 SMP Wed Mar 7 00:52:02 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux
фильтеред это айпитэйблс. по дроппедам я бегло погуглил — нагуглил тот баг что привёл.
duplex одинаковый с двух сторон?
rx_fw_discards это человеческим языком «no buffers», то есть на момент прихода пакета, все дескрипторы уже были заполнены и не обслужены драйвером. Не справляется твоя машина с нагрузкой.
Странно. Нагрузка ничтожна для такого сервера. Сам видишь, что траффика пару десятков гигабайт. А могут какие-то пакеты создавать такой эффект? Проблема в том что каталист на другом в конце не в моей юриксдиции и посмотреть что там нельзя.
а ты крутил настройки, как по моей ссылке делать предлагали?
убедился, что твой драйвер с фиксом, про который там говорят?
Такая проблема может возникать и при load average 0.01, суть в том, что операционная система по какой-то причине не успевает разгребать дескрипторы. В современных ОС, где гонятся за производительностью, входящие пакеты обрабатываются непосредственно в контексте прерывания. В прошлом прерывание только перекладывало пакет из ринга сетевой карты в софтварную очередь и скедулило софтварное прерывание. Такая обработка гарантировала быструю отработку прерывания, однако перекладывание в очередь, её локинг и переключение в другой контекст всё это давало низкую производительность. Поэтому сейчас непосредственно прерывание заходит в сетевой стек и там работает. Если там оно блокируется на чём-то (а вариантов очень много) даже на непродолжительное время, то сетевая карта переполняется. Классическая проблема — пуржинг каких-то кешей, он может длиться значительное время и держать при этом мьютексы, которые также нужны и тредам осуществляющим обработку входящих пакетов. Это всё общие теории, но я думаю, что в линуксе, скорее всего всё так же.
подскажите, в чем может быть причина огромного числа дропнутых пакетов на rx?
Две точки NanoBeam 5AC 19 работают в режиме моста, расстояние где-то около километра с небольшим.
В какой-то момент вдруг резко просела скорость "интернета", путем легкого ковыряния выяснилось, что пинг от точки до точки теряет порядка 10% пакетов.
вот пример, сейчас трафика почти нет, в мониторе показывается TX/RX около 100-150kbps.
Запускаю скачивать iso с mirror.yandex.ru и получаю такую картину:
wget показывает скорость порядка 1,2-2,0M/s ,
в веб-интерфейсе в то же самое время RX: 15-30Mbps,
пинг с точки на точку:
100 packets transmitted, 79 packets received, 21% packet loss
round-trip min/avg/max = 0.839/47.257/574.844 ms
И это не загруженность процессора точки, поскольку с компа пинг ближней точки:
100 packets transmitted, 100 received, 0% packet loss, time 99004ms
rtt min/avg/max/mdev = 0.132/0.190/1.942/0.241 ms
и пинг дальней точки:
100 packets transmitted, 82 received, 18% packet loss, time 100230ms
rtt min/avg/max/mdev = 1.552/47.777/562.468/93.997 ms
Различия видны сразу. И в потерях, и в лагах.
Статистика по интерфейсам ближней точки показывает следующее (набежало за 4,5 часа)
ath0
RX packets:1312916 errors:0 dropped:0 overruns:0 frame:0
TX packets:842977 errors:12020 dropped:30 overruns:0 carrier:0
collisions:0 txqueuelen:0
eth0
RX packets:919867 errors:0 dropped:3348 overruns:0 frame:0
TX packets:1365119 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
wifi0
RX packets:1823124 errors:0 dropped:578713 overruns:0 frame:0
TX packets:1202825 errors:0 dropped:1424 overruns:0 carrier:0
collisions:0 txqueuelen:447
Device information ближней точки:
Memory: 30%
CPU: 12%
airMAX Quality: 80%
airMAX Capacity: 5%
Frequency: 5785 MHz
Channel Width: 40 MHz
Distance: 0.7 miles (1.1 km)
Signal: -66 dBm
Chain 0 / Chain 1: -69 / -70 dBm
Remote Signal: -70 dBm
Remote Chain 0 / Chain 1: -80 / -70 dBm
Connections: 1
Noise Floor: -93 dBm
TX/RX Bytes: 215M / 1.59G
Remote TX Power: 17 dBm
AMС прыгает от 5% до 30%,
AMQ порядка 80-85%.
Уровни сигнала изменяются в пределах +-1 от указанных.
Хотелось бы понять следующее:
чем вызвано такое недетское число дропнутых пакетов на wifi0 интерфейсе?
что делать с жуткими потерями на радиоканале?
что делать с очень низким AMC?
Мне в голову приходит только два варианта: либо одну из точек свернули в сторону, либо стоящая на крыше многоэтажки точка по нынешней московской погоде на ветру просто обмерзает и это сказывается на сигнале.
Или есть какие-то еще причины?
Типы ошибок (dlink)
Undersize — возникают при получение фрейма размером 61-64 байта.
Фрейм передается дальше, на работу не влияет
Oversize — возникают при получении пакета размером более 1518 байт и правильной контрольной суммой
Jabber — возникает при получении пакета размером более 1518 байт и имеющего ошибки в контрольной сумме
Drop Pkts — пакеты отброшенные в одном из трех случаев:
Какие пакеты входят в Drop Packets при выводе show error ports?
Переполнение входного буфера на порту
Пакеты, отброшенные ACL
Проверка по VLAN на входе
Fragment — количество принятых кадров длиной менее 64 байт (без преамбулы и начального ограничителя кадра, но включая байты FCS — контрольной суммы) и содержащих ошибки FCS или ошибки выравнивания.
Excessive Deferral — количество пакетов, первая попытка отправки которых была отложена по причине занятости среды передачи.
Collision — возникают, когда две станции одновременно пытаются передать кадр данных по общей сред
Late Collision — возникают, если коллизия была обнаружена после передачи первых 64 байт пакета
Excessive Collision — возникают, если после возникновения коллизии последующие 16 попыток передачи пакета окончались неудачей. данный пакет больше не передается