Перейти к содержимому
Калькуляторы

Intel e1000e - потери

Есть грабля на нагруженной сетевухе Intel, вот твкой:

driver: e1000e

version: 0.5.18.3-NAPI

firmware-version: 5.11-2

bus-info: 0000:01:00.0

 

Наблюдаются потери пакетов, и растут дропы на RX:

RX packets:281682443588 errors:2 dropped:11676407 overruns:0 frame:1

TX packets:420950175795 errors:0 dropped:0 overruns:0 carrier:0

 

А вот детальнее:

ethtool -S eth3

NIC statistics:

rx_packets: 281855482030

tx_packets: 421317081964

rx_bytes: 184591863557029

tx_bytes: 312544167665840

rx_broadcast: 26201327

tx_broadcast: 200472

rx_multicast: 12097883

tx_multicast: 202852

rx_errors: 2

tx_errors: 0

tx_dropped: 0

multicast: 12097883

collisions: 0

rx_length_errors: 0

rx_over_errors: 0

rx_crc_errors: 1

rx_frame_errors: 0

rx_no_buffer_count: 21102540

rx_missed_errors: 11676407

tx_aborted_errors: 0

tx_carrier_errors: 0

tx_fifo_errors: 0

tx_heartbeat_errors: 0

tx_window_errors: 0

tx_abort_late_coll: 0

tx_deferred_ok: 65833073

tx_single_coll_ok: 0

tx_multi_coll_ok: 0

tx_timeout_count: 0

tx_restart_queue: 17713119

rx_long_length_errors: 0

rx_short_length_errors: 0

rx_align_errors: 0

tx_tcp_seg_good: 5302

tx_tcp_seg_failed: 0

rx_flow_control_xon: 66462649

rx_flow_control_xoff: 66689453

tx_flow_control_xon: 801606

tx_flow_control_xoff: 928116

rx_long_byte_count: 184591863557029

rx_csum_offload_good: 270490391511

rx_csum_offload_errors: 36560575

rx_header_split: 0

alloc_rx_buff_failed: 0

tx_smbus: 0

rx_smbus: 0

dropped_smbus: 0

rx_dma_failed: 0

tx_dma_failed: 0

 

При этом растут rx_missed_errors:

 

Проц 4 ядра, загружены равномерно на 25-30%, трафика - где-то мегабит 500-800 колеблется.

 

Что бы это могло быть, и как с этим бороться?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Модераторы ! Перенесите тему в "Программное обеспечение" !

 

rx_no_buffer_count: 21102540

rx_missed_errors: 11676407

Вот по англицки написано: нет буфферов. ethtool -g смотреть, ethtool -G ставить.

Если стоит уже максимальное значение - карту менять на igb.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Модераторы ! Перенесите тему в "Программное обеспечение" !

 

rx_no_buffer_count: 21102540

rx_missed_errors: 11676407

Вот по англицки написано: нет буфферов. ethtool -g смотреть, ethtool -G ставить.

разные бывают буфера.

для начала посмотрите что за чип - lspci -v

e1000 - это целое семейство. Встречаются в нем откровенно неудачные поделки

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

разные бывают буфера.
Исходя из мануала на чип:

rx_no_buffer_count - то, что не поместилось в rx ring (ethtool -g)

rx_missed - то, что не поместилось в память (fifo) карты.

 

e1000 - это целое семейство. Встречаются в нем откровенно неудачные поделки
У топикстартера е1000е - pci-express. их что, тоже начали бодяжить ? Я видел только е1000 pci которая более 100мбит не качала (типа fxp, но линк гигабитом горит)

 

igb, конечно, заметно резвей, но, к сожалению, драйвера для этого чипа на данный не являются шедевром стабильности
Где именно ? Вроде работает без нареканий, как в 8.0-STABLE , так и в 2.6.32.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Модераторы ! Перенесите тему в "Программное обеспечение" !

 

rx_no_buffer_count: 21102540

rx_missed_errors: 11676407

Вот по англицки написано: нет буфферов. ethtool -g смотреть, ethtool -G ставить.

разные бывают буфера.

для начала посмотрите что за чип - lspci -v

e1000 - это целое семейство. Встречаются в нем откровенно неудачные поделки

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

-G стоит максимальное (4096). а сама карта -

Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Карту меняйте или включайте flow-control, предвительно изучив что это за собой повлечет - немного полегчает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

включайте flow-control, предвительно изучив что это за собой повлечет - немного полегчает.
Ага, дропы будут на свиче или рутере.

 

Карту менять надо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

или включайте flow-control
судя по
rx_flow_control_xon: 66462649
rx_flow_control_xoff: 66689453
tx_flow_control_xon: 801606
tx_flow_control_xoff: 928116

он уже был включен.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А куда подключен eth3? Судя по rx_flow_control_xon, на том конце не справляются с трафиком, который уходит с eth3.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А куда подключен eth3? Судя по rx_flow_control_xon, на том конце не справляются с трафиком, который уходит с eth3.

В свитч подключен, там транспорт гигабитный, еще один свитч и еще один комп-роутер аналогичный.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Где именно ? Вроде работает без нареканий, как в 8.0-STABLE , так и в 2.6.32.
К сожалению, таким же позитивом не обладаю.

Вот так выглядит наш опыт для FBSD (семёрка, а потом и восьмёрка):

aluminium:~$ last | grep reboot

reboot ~ чт 18 фев 01:22

reboot ~ чт 18 фев 00:25

reboot ~ чт 18 фев 00:14

reboot ~ ср 17 фев 17:47

reboot ~ пн 15 фев 15:46

reboot ~ вс 14 фев 15:45

reboot ~ сб 13 фев 21:40

reboot ~ пт 12 фев 15:39

reboot ~ пт 12 фев 15:33

reboot ~ пт 12 фев 00:01

reboot ~ чт 11 фев 20:51

reboot ~ чт 11 фев 17:18

reboot ~ ср 10 фев 16:40

reboot ~ вт 9 фев 13:42

reboot ~ пн 8 фев 06:09

reboot ~ чт 4 фев 09:58

reboot ~ ср 3 фев 20:59

reboot ~ ср 3 фев 20:20

reboot ~ пн 1 фев 23:38

reboot ~ пн 1 фев 23:06

aluminium:~$ last -f /var/log/wtmp.0 | grep reboot

reboot ~ вс 31 янв 07:06

reboot ~ чт 28 янв 11:16

reboot ~ ср 27 янв 09:26

reboot ~ сб 23 янв 22:55

reboot ~ сб 23 янв 22:42

reboot ~ сб 23 янв 20:04

reboot ~ сб 23 янв 19:50

reboot ~ сб 23 янв 19:19

reboot ~ сб 23 янв 18:49

reboot ~ пт 22 янв 19:22

reboot ~ пт 22 янв 19:15

reboot ~ пт 22 янв 12:13

reboot ~ пт 22 янв 12:09

reboot ~ пт 22 янв 11:51

reboot ~ пт 22 янв 11:24

reboot ~ чт 21 янв 22:16

reboot ~ чт 21 янв 11:39

reboot ~ вт 19 янв 15:04

reboot ~ вт 19 янв 14:48

reboot ~ пн 18 янв 19:42

reboot ~ пн 18 янв 17:45

reboot ~ пт 15 янв 19:29

reboot ~ пт 15 янв 10:41

reboot ~ чт 14 янв 12:45

reboot ~ ср 13 янв 20:21

reboot ~ вт 12 янв 22:48

reboot ~ вт 12 янв 20:55

reboot ~ вт 12 янв 08:18

reboot ~ пн 11 янв 04:07

reboot ~ вс 10 янв 02:13

reboot ~ вс 10 янв 02:08

reboot ~ вс 10 янв 01:58

reboot ~ вс 10 янв 01:18

reboot ~ вс 10 янв 00:05

reboot ~ сб 9 янв 15:15

reboot ~ сб 9 янв 01:26

reboot ~ сб 9 янв 01:21

reboot ~ пт 8 янв 22:51

reboot ~ чт 7 янв 23:16

reboot ~ чт 7 янв 23:12

reboot ~ чт 7 янв 23:07

reboot ~ чт 7 янв 23:04

reboot ~ чт 7 янв 19:11

reboot ~ чт 7 янв 19:04

reboot ~ чт 7 янв 18:57

reboot ~ чт 7 янв 18:49

reboot ~ чт 7 янв 18:43

reboot ~ чт 7 янв 18:37

reboot ~ чт 7 янв 18:33

reboot ~ чт 7 янв 18:26

reboot ~ чт 7 янв 18:21

reboot ~ чт 7 янв 16:26

reboot ~ чт 7 янв 16:21

reboot ~ чт 7 янв 16:17

reboot ~ чт 7 янв 16:01

reboot ~ ср 6 янв 00:12

reboot ~ сб 2 янв 19:16

 

на днях Интел выкатил более стабильный драйвер, но "гоп" говорить пока не хочется.

В Линуксе в 2.6.31 оно как-то заработало. Но тоже как-то слишком недавно и - в нашем случае - только, если отключить scatter-gather.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

wawa

Может не в драйвере проблема?

$ ethtool -i eth2
driver: igb
version: 1.3.28.5
firmware-version: 1.13-1
bus-info: 0000:01:00.1

$ ethtool -k eth2
Offload parameters for eth2:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: on

$ uptime 
19:38:20 up 120 days,  1:57,  1 user,  load average: 0.00, 0.00, 0.00

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.