[Dark_Angel]

Ваш вопрос изначально не имеет ответа, потому что не понятно что вы собираетесь на нем роутить. И вообще, только роутить ли.

 

Поэтому уточняйте что вы хотите делать и, возможно, будет возможность ответить на ваш вопрос. На тупом роутинге, с размером пакета 500-600 байт, вы забьете двухпортовую 82576 без проблем. За broadcom не скажу. Это примерно 800 Кpps во все стороны ( 4 Гбита ).

 

Вот только это конь в вакууме.

Изменено 13 апреля, 2012 пользователем Dark_Angel

[QWE]

Ваш вопрос изначально не имеет ответа, потому что не понятно что вы собираетесь на нем роутить. И вообще, только роутить ли.

 

Сервер будет только роутить - BIRD c FV + ipt_netflow

[Dark_Angel]

За АМД и Броадком не скажу, но на Интеле и 82576 должны пропихнуть до 800Кpps. Тут еще зависит от настроек ipt_netflow. На таком трафике ipt_netflow может скушать 10-15% от процессора.

[spectrum]

Собираемся взять на сервер BRAS pppoe вторую сетевую карту 4-х головую Гигабит. Задачи - bonding + vlan + pppoe терминация + шейпинг. На выбор есть карта E1G44HT (I340-T4), как я понял она на чипе Intel 82580, и вторая E1G44ET2 Gigabit ET2 на чипе Intel 82576. Первая 10 т.р., вторая 13 т.р. Для работы в указанных задачах разницы между ними не увидел. Спрашивается - нужно ли платить больше, у кого-нибудь стоят в указанных задачах карты на чипе 82580?

[SoulDivider]

Здравствуйте, коллеги.

Прошу помощи в следующей проблеме. Имеется сервер с 82576 и 2 Xeon 5650:

# uname -r

2.6.36.3

# ethtool -i eth0

driver: igb

version: 3.4.7

firmware-version: 1.8-2

bus-info: 0000:05:00.0

прерывания разбросаны по ядрам

  
64:          1          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0
 65:         91          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-0
 66:         28         20          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-1
 67:         36          0         20          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-2
 68:         34          0          0         14          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-3
 69:         38          0          0          0         11          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-4
 70:         41          0          0          0          0          7          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-5
 71:         44          0          0          0          0          0          4          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-6
 72:         47          0          0          0          0          0          0          1          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-7

 

Проблема в следующем. Не распределяются исходящие пакеты по всем очередям, а льются все в одну

# ethtool -S eth0 | grep tx_queue | grep packets

tx_queue_0_packets: 0

tx_queue_1_packets: 0

tx_queue_2_packets: 3

tx_queue_3_packets: 0

tx_queue_4_packets: 0

tx_queue_5_packets: 1210115

tx_queue_6_packets: 0

tx_queue_7_packets: 0

Уж не знаю куда копать, ставил для теста Debian 2.6.32, драйвер менял (проблема как на ядерном igb, так и на новых версиях), разносил tx и rx по разным векторам. Прошу помощи.

UPD. tc qdisc add dev eth0 root handle 1: multiq так же ничего не меняет.

Изменено 12 мая, 2012 пользователем SoulDivider

[NiTr0]

Не распределяются исходящие пакеты по всем очередям, а льются все в одну

Ну и фиг с ним, нагрузка-то мизерная от tx...

 

у нас на одной машине все ок:

# ethtool -S eth0 | grep tx_queue | grep packets
    tx_queue_0_packets: 5534731940
    tx_queue_1_packets: 5694937962
# ethtool -i eth0
driver: igb
version: 2.4.12
firmware-version: 1.2-1
bus-info: 0000:04:00.0
# uname -r
2.6.35.13-i686

 

на другой - хуже:

# ethtool -S eth0 | grep tx_queue | grep packets
    tx_queue_0_packets: 20027799858
    tx_queue_1_packets: 146477329759
    tx_queue_2_packets: 889867321
    tx_queue_3_packets: 16547517
# ethtool -i eth0
driver: igb
version: 2.4.12
firmware-version: 1.2-1
bus-info: 0000:03:00.0
# uname -r
2.6.35.13-i686

 

на третьей - еще хуже:

 

# uname -r
2.6.35.8-i686
# ethtool -i eth0
driver: igb
version: 2.1.0-k2
firmware-version: 1.2-1
bus-info: 0000:01:00.0
border# # ethtool -S eth0 | grep tx_queue | grep packets
# ethtool -S eth0 | grep tx_queue | grep packets
    tx_queue_0_packets: 269544
    tx_queue_1_packets: 186479
    tx_queue_2_packets: 19650
    tx_queue_3_packets: 2615
    tx_queue_4_packets: 16029371831
    tx_queue_5_packets: 3144

 

С чем связано - неведомо.

[Умник]

SoulDivider, что это за трафик? Транзит или порожден самой машиной? Много соединений?

[SoulDivider]

Умник, порожден. Соединений не много, грубо говоря в качестве теста генерировал спуфленый icmp echo request. На rx все распределялось равномерно, а вот reply лился в одну очередь.

Ну и фиг с ним, нагрузка-то мизерная от tx...

Не уверен на 100%, но мне кажется что 1 ядро(core5 в моем случае), к которому привязана единственная задействованная очередь может быть тонким местом. Плюс, как мне кажется, будут частые копирования данных с ядер в ядро(core5).

[QWE]

собрал сервер на http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8.cfm + Intel EXPI9402PT (на шине PCIe) чип Intel 82576, решаемые задачи BGP fv + ipt_netflow + будут VLANы

планирую поставить CentOS6.2 (2.6.32) x86_64 + ipt_netflow под эту систему (на наг есть ссылка на репозиторий) + igb последний драйвер 3.4.7

 

1. Насколько лучше с точки зрения производительности системы (маршрутизация, прерывания CPU), остаться на этой версии ядра или обновить его то до какой? Или перейти на другой дистр linux если лучше менять версию ядра?

2. Насколько будет эффективнее поднять bonding (eth0+eth1) с точки зрения раходования прерываний CPU и маршрутизации? Есть ли в нем необходимость?

3. В системе 8 ядер, как лучше распределить прерывания и сколько сделать очередей RX,TX от каждого интерфейса?

Изменено 16 мая, 2012 пользователем QWE

[NiTr0]

Делаете по 8 комбо очередей, бондинг - думаю не обязателен, дистр - я бы ставил какой-то embedded. LEAF к примеру. Не нужно винт держать (дорогой и ненадежный), нет отказов при внезапном ребуте (если только в конфигах сами не накосячили ессно), ФС в рид-онли.

И, думается, железка гораздо больше 1 гбита пережует.

Хотя все же эта платформа более подходит для каких-то вычислительных задач, в качестве молотилки траффика ИМХО лучше будет себя показывать какой-то десктопный i5... При меньшем энергопотреблении.

[QWE]

Делаете по 8 комбо очередей

так ?

 

eth0-txrx-0 cpu0-0

eth0-txrx-1 cpu0-1

eth0-txrx-2 cpu0-2

eth0-txrx-3 cpu0-3

eth0-txrx-4 cpu1-0

eth0-txrx-5 cpu1-1

eth0-txrx-6 cpu1-2

eth0-txrx-7 cpu1-3

 

eth1-txrx-0 cpu0-0

eth1-txrx-1 cpu0-1

eth1-txrx-2 cpu0-2

eth1-txrx-3 cpu0-3

eth1-txrx-4 cpu1-0

eth1-txrx-5 cpu1-1

eth1-txrx-6 cpu1-2

eth1-txrx-7 cpu1-3

 

а вместо Zebra bird установить можно на LEAF?

Изменено 16 мая, 2012 пользователем QWE

[NiTr0]

так ?

да

а вместо Zebra bird установить можно на LEAF?

в комплекте есть, в боевых условиях не испытывал.

[QWE]

а кто чем мониторит/собирает статистику на бордере?

[Shrim]

Ситуация: HP DL360G7 и HP DL180G6, на первом установлен ESXi 5.0, второй под завязку набит дисками и на нём установлен debian 6.0.5. В обеих серверах установлены 10Gb сетевухи HP NC552SFP , соединены DAC SFP+ , DL180G6 выступает в роли СХД (на NetApp денег не хватило) раздавая массив дисков по iSCSI. Хорошая новость - всё работает. Вот только производительность оставляет желать лучшего - в виртуальной машине CrystalDiskMark выдаёт 550-600MB/s на чтение/запись, а ожидалось примерно 800 (локально блочное устройство выдаёт больше 1000 и на чтение и на запись). Логично, первым делом, включил Jumbo Frames, ожидая прироста производительности, но не тут то было - на чтение производительность увеличилась, а на запись просела до 50MB/s. Начал разбираться в чём дело и пока пришёл только к одному выводу. В debian драйвер сетевухи be2net и как оказалось он не поддерживает lro (по умолчанию выключена и включить не удаётся). Любые манипуляци с ethtool и sysctl не дают ни какого результата. Драйвер предоставляет всего две очереди обработки прерываний, на rx и на tx, распределение прерываний на разные ядра так же не дало результатов. Вот некоторая статистика:

# ifconfig eth0

eth0 Link encap:Ethernet HWaddr b4:99:ba:26:37:90

inet addr:192.168.7.7 Bcast:192.168.7.255 Mask:255.255.255.0

inet6 addr: fe80::b699:baff:fe26:3790/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1

RX packets:324222045 errors:3822419471 dropped:0 overruns:267385334 frame:3439909610

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

collisions:0 txqueuelen:10000

RX bytes:393782237788 (366.7 GiB) TX bytes:446418780688 (415.7 GiB)

# ethtool -S eth0

NIC statistics:

rx_packets: 324222596

tx_packets: 319982219

rx_bytes: 393782844718

tx_bytes: 446418859994

rx_errors: 3823113432

tx_errors: 0

rx_dropped: 0

tx_dropped: 0

be_tx_reqs: 144824470

be_tx_stops: 0

be_fwd_reqs: 0

be_tx_wrbs: 582718462

be_polls: 0

be_tx_events: 104726012

be_rx_events: 0

be_tx_compl: 144824470

be_rx_compl: 324222598

be_ethrx_post_fail: 0

be_802_3_dropped_frames: 0

be_802_3_malformed_frames: 0

be_tx_rate: 0

be_rx_rate: 0

rx_unicast_frames: 0

rx_multicast_frames: 0

rx_broadcast_frames: 0

rx_crc_errors: 1292011755

rx_alignment_symbol_errors: 95

rx_pause_frames: 3593254895

rx_control_frames: 93

rx_in_range_errors: 0

rx_out_range_errors: 0

rx_frame_too_long: 2148591072

rx_address_match_errors: 111

rx_vlan_mismatch: 334413890

rx_dropped_too_small: 334411119

rx_dropped_too_short: 2612

rx_dropped_header_too_small: 159

rx_dropped_tcp_length: 0

rx_dropped_runt: 0

rx_fifo_overflow: 374126

rx_input_fifo_overflow: 19576043

rx_ip_checksum_errs: 0

rx_tcp_checksum_errs: 0

rx_udp_checksum_errs: 48096620

rx_non_rss_packets: 19651525

rx_ipv4_packets: 983659

rx_ipv6_packets: 1182224

tx_unicastframes: 0

tx_multicastframes: 0

tx_broadcastframes: 0

tx_pauseframes: 0

tx_controlframes: 0

rx_drops_no_pbuf: 247435211

rx_drops_no_txpb: 1663

rx_drops_no_erx_descr: 20244

rx_drops_no_tpre_descr: 1077187

rx_drops_too_many_frags: 0

rx_drops_invalid_ring: 0

forwarded_packets: 0

rx_drops_mtu: 0

rx_drops_no_fragments: 0

[NiTr0]

Собрать свежий драйвер религия не позволяет, коли в репозиториях нет?

[QWE]

Настроил таки сервер

Ядро вот отсюда http://alex-at.ru/linux/centos-6-2-rps

[root@testrouter ~]# uname -a

Linux testrouter.mservice 2.6.32-220.7.1.el6.alex.rps.2.x86_64 #1 SMP Sat Mar 24 11:36:12 MSK 2012 x86_64 x86_64 x86_64 GNU/Linux

[root@testrouter ~]#

 

Сетевая

06:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

06:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

 

Драйвер по умолчанию который шел с ядром

 

[root@testrouter ~]# ethtool -i eth0

driver: igb

version: 3.0.6-k

firmware-version: 1.2-1

bus-info: 0000:06:00.0

[root@testrouter ~]#

 

Драйвер грузится по умолчанию, хотя поиграться можно всего только одним параметром

[root@testrouter src]# modinfo igb | grep parm

parm: max_vfs:Maximum number of virtual functions to allocate per physical function (uint)

[root@testrouter src]#

хотя в исходниках более нового драйвера параметров для тюнинга очень много.

 

Очереди создаются как надо. но во время тестов картина по рерываниям такая

 

58: 0 0 0 1 0 0 0 0 PCI-MSI-edge eth1

59: 4388 4368 4462 4469 4449 4370 4394 4409 PCI-MSI-edge eth1-TxRx-0

60: 4434 4353 4377 4393 4449 4457 4355 4374 PCI-MSI-edge eth1-TxRx-1

61: 4568 4573 4481 4502 4507 4513 4465 4560 PCI-MSI-edge eth1-TxRx-2

62: 4377 4393 4352 4434 4356 4374 4457 4449 PCI-MSI-edge eth1-TxRx-3

63: 4354 4379 4456 4449 4353 4430 4393 4378 PCI-MSI-edge eth1-TxRx-4

64: 4354 4430 4395 4378 4456 4450 4379 4355 PCI-MSI-edge eth1-TxRx-5

65: 2062948 2066143 2076223 2075504 2049662 2053214 2060639 2057563 PCI-MSI-edge eth1-TxRx-6

66: 4384 4396 4445 4351 4363 4350 4439 4464 PCI-MSI-edge eth1-TxRx-7

 

Все пакеты обрабатываются одной очередью eth1-TxRx-6 но равномерно размазываются по всем ядрам. Какой смысл тогда в таком количестве очередей или както по особенному грузить модуль сетевой карты? Или это глюки?

Во время тестов в одну сторону 465k PPS на интерфейсе появились overruns:1002943

[root@testrouter ~]# ifconfig eth0

eth0 Link encap:Ethernet HWaddr 90:E2:BA:06:FF:50

inet6 addr: fe80::92e2:baff:fe06:ff50/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:332723284 errors:0 dropped:0 overruns:1002943 frame:0

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

collisions:0 txqueuelen:1000

RX bytes:80117618310 (74.6 GiB) TX bytes:429633 (419.5 KiB)

Memory:d8520000-d8540000

 

[root@testrouter ~]#

 

[root@testrouter ~]# ethtool -S eth0 | grep rx_queue_6

rx_queue_6_packets: 332723161

rx_queue_6_bytes: 80117611254

rx_queue_6_drops: 1002943 совпадает с overruns:1002943

rx_queue_6_csum_err: 0

rx_queue_6_alloc_failed: 0

[root@testrouter ~]#

[root@testrouter ~]# ethtool -g eth0

Ring parameters for eth0:

Pre-set maximums:

RX: 4096

RX Mini: 0

RX Jumbo: 0

TX: 4096

Current hardware settings:

RX: 256

RX Mini: 0

RX Jumbo: 0

TX: 256

 

[root@testrouter ~]#

[root@testrouter ~]# ethtool -c eth0

Coalesce parameters for eth0:

Adaptive RX: off TX: off

stats-block-usecs: 0

sample-interval: 0

pkt-rate-low: 0

pkt-rate-high: 0

 

rx-usecs: 3

rx-frames: 0

rx-usecs-irq: 0

rx-frames-irq: 0

 

tx-usecs: 0

tx-frames: 0

tx-usecs-irq: 0

tx-frames-irq: 0

 

rx-usecs-low: 0

rx-frame-low: 0

tx-usecs-low: 0

tx-frame-low: 0

 

rx-usecs-high: 0

rx-frame-high: 0

tx-usecs-high: 0

tx-frame-high: 0

 

Нагрузка ядер по top во время тестов показывала нагрузку на SI 0,3-0,7% процы были совсем не нагружены.

При нагрузке в 300к PPS на каждое ядро высыпалось по 700-800 прерываний в секунду т.е. 6000 (Но мог и ошибиться, по доке драйвер по умолчанию генерит 8000) прерываний при 300к PPS.

 

 

 

Чем лечить?

Изменено 14 июня, 2012 пользователем QWE

[telecom]

Драйвер по умолчанию который шел с ядром

Соберите дрова с http://sourceforge.net/projects/e1000/files/igb%20stable/3.4.7/

потом поговорим)))

[QWE]

ок, установил модуль

[root@testrouter src]# modinfo igb | grep -E "version|parm"

version: 3.4.7

srcversion: 84D0F70C7DF9FC65710D5E8

vermagic: 2.6.32-220.7.1.el6.alex.rps.2.x86_64 SMP mod_unload modversions

parm: InterruptThrottleRate:Maximum interrupts per second, per vector, (max 100000), default 3=adaptive (array of int)

parm: IntMode:Change Interrupt Mode (0=Legacy, 1=MSI, 2=MSI-X), default 2 (array of int)

parm: Node:set the starting node to allocate memory on, default -1 (array of int)

parm: LLIPort:Low Latency Interrupt TCP Port (0-65535), default 0=off (array of int)

parm: LLIPush:Low Latency Interrupt on TCP Push flag (0,1), default 0=off (array of int)

parm: LLISize:Low Latency Interrupt on Packet Size (0-1500), default 0=off (array of int)

parm: RSS:Number of Receive-Side Scaling Descriptor Queues (0-8), default 1=number of cpus (array of int)

parm: VMDQ:Number of Virtual Machine Device Queues: 0-1 = disable, 2-8 enable, default 0 (array of int)

parm: max_vfs:Number of Virtual Functions: 0 = disable, 1-7 enable, default 0 (array of int)

parm: MDD:Malicious Driver Detection (0/1), default 1 = enabled. Only available when max_vfs is greater than 0 (array of int)

parm: QueuePairs:Enable TX/RX queue pairs for interrupt handling (0,1), default 1=on (array of int)

parm: EEE:Enable/disable on parts that support the feature (array of int)

parm: DMAC:Disable or set latency for DMA Coalescing ((0=off, 1000-10000(msec), 250, 500 (usec)) (array of int)

parm: LRO:Large Receive Offload (0,1), default 0=off (array of int)

parm: debug:Debug level (0=none, ..., 16=all) (int)

[root@testrouter src]#

 

гружу с одним параметром

modprobe igb RSS=8,8

сдвоенных очередей на каждый интерфейс получилось по 8

overruns ошибки исчезли.

Проблема с тем что драйвер разгребает пакеты одной очередью остается

тестирую программой iperf

сервер клиент включен в интерфейс eth0 тестируемого сервера

iperf -c 192.168.20.1 -i 5 --format k -u -l64 -b6200k -p 5002 -P 40 -t 1800

сервер - сервер включен в интерфейс eth1 тестируемого сервера

iperf -B 192.168.20.1 -u -s -i5 -p 5002

 

при этом на eth0 тестируемого сервера влетает 483к пакетов в секунду

далее идут непонятные мне цифры

очередь (через которую пакеты прилетают) eth0-TxRx-6 генерит на каждое ядро 130/1с прерываний, а очередь (через которую пакеты улетают) eth1-TxRx-3 2200/1с на каждое ядро. На отправку прерываний больше почему то чем на прием!!!

top

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

 

13 root 20 0 0 0 0 R 12.3 0.0 3:49.33 ksoftirqd/2

21 root 20 0 0 0 0 S 3.7 0.0 0:43.14 ksoftirqd/4

25 root 20 0 0 0 0 S 3.7 0.0 1:15.39 ksoftirqd/5

29 root 20 0 0 0 0 S 3.3 0.0 1:26.70 ksoftirqd/6

33 root 20 0 0 0 0 S 3.0 0.0 0:57.72 ksoftirqd/7

17 root 20 0 0 0 0 S 2.7 0.0 2:37.13 ksoftirqd/3

9 root 20 0 0 0 0 S 1.7 0.0 1:13.25 ksoftirqd/1

4 root 20 0 0 0 0 S 0.3 0.0 0:53.82 ksoftirqd/0

стоит увеличить полосу с -b6200k до -b6500k как в топе залипает 100% загрузка одного ядра, т.е. 483к PPS предел для 8 ядерной системы с супер интеловыми сетевухами ((( это с модулем ipt_NETFLOW но без FV

единственный положительный момент как уже писал - на интерфейсах отсутствуют какие либо ошибки

че делать то?

 

и еще заметил в отчете iperf много вот таких пакетов 49011 datagrams received out-of-order

 

[ 31] Server Report:

[ 31] 0.0-1344.0 sec 1012975 KBytes 6174 Kbits/sec 0.062 ms 96974/16304569 (0.59%)

[ 31] 0.0-1344.0 sec 49011 datagrams received out-of-order

 

выгрузил ipt_NETFLOW система стала прокачивать 575к PPS количество прерываний не увеличилось где то 20000/сек

 

если добавить еще пакетов опять вылезает ksoftirqd

 

perf top

701.00 6.8% _spin_lock /usr/lib/debug/lib/modules/2.6.32-220.7.1.el6.alex.rps.2.x86_64/vmlinux

605.00 5.9% __alloc_skb /usr/lib/debug/lib/modules/2.6.32-220.7.1.el6.alex.rps.2.x86_64/vmlinux

568.00 5.5% igb_poll /lib/modules/2.6.32-220.7.1.el6.alex.rps.2.x86_64/kernel/drivers/net/igb/igb.ko

529.00 5.1% igb_xmit_frame_ring /lib/modules/2.6.32-220.7.1.el6.alex.rps.2.x86_64/kernel/drivers/net/igb/igb.ko

417.00 4.0% igb_tx_ctxtdesc /lib/modules/2.6.32-220.7.1.el6.alex.rps.2.x86_64/kernel/drivers/net/igb/igb.ko

342.00 3.3% ipt_do_table /lib/modules/2.6.32-220.7.1.el6.alex.rps.2.x86_64/kernel/net/ipv4/netfilter/ip_tables.ko

 

и при 575к PPS как то стали только 4 ядра процессоров выделяться по загрузке

Изменено 17 июня, 2012 пользователем QWE

[purecopper]

Помогите пожалуйста с ситуацией:

Linux-маршрутизатор, на котором терминируются пользовательские vlan`ы (порядка 1000 штук), настроен шейпер исходящего от пользователя трафика.

Проблема в следующем - в топе постоянно [k] read_hpet и [k] acpi_idle_enter_simple, что, кмк, не совсем правильно.

 

uname -a:

 

 

Linux 2.6.34-gentoo-r6 #1 SMP Fri Oct 19 20:33:29 MSK 2012 x86_64 Intel(R) Xeon(R) CPU E5405 @ 2.00GHz GenuineIntel GNU/Linux

 

 

 

/proc/cpuinfo

 

 

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
stepping        : 10
cpu MHz         : 1994.834
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips        : 3989.66
clflush size    : 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
stepping        : 10
cpu MHz         : 1994.834
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 4
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips        : 3990.04
clflush size    : 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
stepping        : 10
cpu MHz         : 1994.834
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 4
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips        : 3990.05
clflush size    : 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
stepping        : 10
cpu MHz         : 1994.834
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 3
cpu cores       : 4
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips        : 3990.00
clflush size    : 64
cache_alignment : 64
address sizes   : 38 bits physical, 48 bits virtual
power management:

 

 

 

perf-top:

 

 

PerfTop:    3212 irqs/sec  kernel:99.5%  exact:  0.0% [1000Hz cycles],  (all, 4 CPUs)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

   26.34%  [kernel]          [k] read_hpet
   18.65%  [processor]       [k] acpi_idle_enter_simple
    4.98%  [kernel]          [k] _raw_spin_lock_irqsave
    2.29%  [igb]             [k] igb_poll
    2.29%  [ip_tables]       [k] ipt_do_table
    1.80%  [kernel]          [k] skb_copy_bits
    1.74%  [kernel]          [k] _raw_spin_lock
    1.11%  [kernel]          [k] tick_broadcast_oneshot_control
    1.04%  [kernel]          [k] pskb_expand_head
    0.96%  [cls_u32]         [k] u32_classify
    0.86%  [kernel]          [k] _raw_spin_unlock_irqrestore
    0.84%  [kernel]          [k] nf_iterate
    0.82%  [kernel]          [k] netif_receive_skb
    0.75%  [kernel]          [k] native_sched_clock
    0.70%  [kernel]          [k] kfree
    0.63%  [kernel]          [k] dev_queue_xmit
    0.63%  [kernel]          [k] skb_release_data
    0.63%  [kernel]          [k] dev_hard_start_xmit
    0.61%  [kernel]          [k] sk_run_filter
    0.61%  [processor]       [k] acpi_idle_enter_c1
    0.59%  [kernel]          [k] sched_clock_local
    0.55%  [kernel]          [k] csum_partial
    0.51%  [igb]             [k] igb_xmit_frame_ring
    0.50%  [kernel]          [k] menu_select
    0.49%  [kernel]          [k] __copy_skb_header
    0.49%  [kernel]          [k] skb_release_head_state
    0.49%  [kernel]          [k] ip_route_input
    0.46%  [kernel]          [k] __alloc_skb
    0.46%  [kernel]          [k] hpet_next_event
    0.45%  [kernel]          [k] ktime_get
    0.45%  [nf_conntrack]    [k] __nf_conntrack_find
    0.40%  [kernel]          [k] local_bh_enable
    0.39%  [kernel]          [k] _raw_spin_lock_bh
    0.39%  [sch_htb]         [k] htb_dequeue
    0.39%  [nf_conntrack]    [k] nf_conntrack_find_get
    0.38%  [kernel]          [k] ip_rcv
    0.38%  [kernel]          [k] irq_entries_start
    0.38%  [unknown]         [.] 0x00007f9e2db243b6
    0.37%  [kernel]          [k] kmem_cache_alloc
    0.37%  [nf_conntrack]    [k] 0x00000000000000a1

 

 

Изменено 23 октября, 2012 пользователем purecopper

[voron]

Укажите/смените clocksourse на tsc в параметрах загрузки ядра

kernel /boot/vmlinuz root=/dev/sda2 ro clocksource=tsc

Перезагрузитесь и убедитесь, что изменение имеет место быть

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
tsc

[Justas]

Коллеги, поставил машину самосбор под софтроутер на серверной маме Supermicro (чипсет Intel C202) + 4-ядерный процессор Intel i5 (без гипертрединга).

 

# cat /proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
stepping        : 9
microcode       : 0x12
cpu MHz         : 3399.965
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 6799.93
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

 

Операционная система Генту 64 разряда - 3.5.7-gentoo #9 SMP Wed Dec 12 01:11:12 MSK 2012 x86_64 Intel® Core i5-3570K CPU @ 3.40GHz GenuineIntel GNU/Linux

 

 

После пары часов работы в dmesg появляется

 

Clocksource tsc unstable (delta = 299966086829 ns)
Switching to clocksource hpet

 

и нагрузка на процессор возрастает в два раза. Что, понятно, не приемлемо.

 

С чем может быть связано такое поведение оперсистемы? Стоит ли отказаться от ACPI для решения вопроса? Может, какие-то опции ядра поправить? Что еще можно предпринять? TSC нужен как воздух.

 

Сервер делает NAT, немного шейпит + поднят BGP.

Изменено 12 декабря, 2012 пользователем Justas

[Abram]

Justas,

Вот такое нашёл:

The TSC is supposed to tick at the CPU rate (unless it's a constant_tsc, see /proc/cpuinfo flags, so on frequency change, this ought to happen. The kernel will automatically switch to something else.

Попробуйте Turbo Boost отключить.

Насчет нагрузки процессора после переключения clocksource:

Попробуйте после переключения clocksource сделать ntpdate, помогает?

Ну и ntpd, естественно, должен быть запущен.

 

А вообще, чем HPET плох?

[Alex/AT]

А вообще, чем HPET плох?

Для таймстампинга пакетов - тем, что время доступа к абсолютному показателю HPET по меркам машины достаточно приличное.

Именно поэтому read_hpet и вываливается в топ.

[Justas]

Попробуйте Turbo Boost отключить.

 

А вообще, чем HPET плох?

 

TurboBoost в биосе отключил - не помогает. hpet медленнее tsc, намного медленнее. Тут в аналогичной теме http://forum.nag.ru/forum/index.php?showtopic=38982&st=80&p=370335entry370335 товарищи писали.

 

ntpd запущен, часы исправно синхронизируются и еще клиентов даже обслуживают - уровень ntp-сервера стратум 2.

[Justas]

Вдогонку график загрузки процессора. До 01:00 - hpet. С 02:15 до 08:20 - tsc. Видно, что около 08:20 нагрузка возрастает в 2 раза. Это момент смены оперсистемой clocksource с tsc на hpet.