Jump to content
Калькуляторы

Очень важный вопрос к знатокам по Linux ядро 2.6.35.7 (проблема с igb) - РЕШЕНО

Сразу скажу, что тему создал в продолжение вот этой http://forum.nag.ru/forum/index.php?showtopic=61586

 

Исходные данные: Slackware 13.1 (установка в режиме expert только с нужными мне пакетами, но ничего не модифицировано и никакие настройки не делались после инсталляции, кроме запуска сети и запуска pptpd)

 

Сервер: Intel Quad 9550| 4Gb RAM| Eth Intel E1G42ET Gigabit Adapter Dual Port PCI-E x4 (есть еще Intel E1G44ET Gigabit Adapter Quad Port PCI-E x4, поэтому тесты были проведены и с ней). На мат. плате стоит еще сетевка PCI-E c дравером e1000e.

 

Один порт сетевой смотрит в инет, другой в локалку. На данной конфигурации проведено более 60 тестов. Опционально тесты выполнялись на 4-х разных материнских платах с разными CPU от 2-х ядер до 6-ти с разными сетевыми картами.

 

Проверялись ядра 2.6.35.7 и 8. Проверялись драйвера igb 6-ти последних версий с опциями запуска modprobe и без. Проверялись драйвера igb, те, который в ядре с опциями запуска модуля и без. Проверялись комбинации ядер 2.6.35.7 и 8 с slackware 12.2., 13.0, 13.1 и даже current на дату 19 ноября 2010. Проводился тюнинг sysctl с параметрами взятыми с боевых серверов и проводилось тестирование с умолчальными sysctl.

 

Ни в одной комбинации из более чем 60, где сетевой картой, которая смотрит в интернет является igb не заработал ни один шейпер (tbf, htb, sfq и др.)!

 

Теперь самое интересное. Я на ходу переключаю внешний канал в сетевую e1000e, перекладываю адрес на другой интерфейс (опционально тестировал с skge, tg3, e1000, sky2 и даже realtek 8139) и все сразу же начинает работать как и работает на боевых серверах.

 

Я не идиот, у меня 12 серверов pptp в рабочем режиме и более 8000 вечерний онлайн и большой опыт в настройке, тюнинге и поддержке разных серверов. Собирать ядра под любые задачи тоже не вопрос, но с этой проблемой я не могу разобраться уже 3 недели. Испробовано почти все. Если что-то еще не проверял, так это другие ОС, кроме slackware.

 

В данное время все мои сервера работают на ядрах 2.6.27.х и 2.6.33.х с совершенно аналогичным алгоритмом шейпирования и в абсолютно идентичной конфигурации.

 

Ключевой вопрос. Почему на ядре 2.6.35.х как только снаружи оказывается сетевая с драйвером igb у алгоритма шейпирования слетают могзи, но без шейпера вообще сервер демонстрирует идеальные характеристики работы и многодневный uptime с этой сетевкой, а шейпер работает с любыми сетевыми, кроме igb.

 

Прошу откликнуться тех, у кого slackware с аналогичными сетевыми картами и желательно аналогичными ядрами 2.6.35.х.

 

Конфигурация моего тестового стенда такая http://forum.nag.ru/forum/index.php?s=&amp...st&p=559457

Edited by replicant

Share this post


Link to post
Share on other sites

может ASPM? попробуйте сравнить вывод lspci -vvv старого и нового ядер.

Share this post


Link to post
Share on other sites
может ASPM? попробуйте сравнить вывод lspci -vvv старого и нового ядер.

Сравнил, но что именно там искать в этом выводе? Вот вывод двух сетевок на одном и том же ядре 2.6.35.7 сразу после инсталляции slackware-current еще практически без настроек. Отличия только в том, что на e1010e все работает, а на igb - нет.

 

00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
        Subsystem: Intel Corporation Device 34d0
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 45
        Region 0: Memory at 83200000 (32-bit, non-prefetchable) [size=128K]
        Region 1: Memory at 83220000 (32-bit, non-prefetchable) [size=4K]
        Region 2: I/O ports at 4040 [size=32]
        Capabilities: [c8] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000fee0300c  Data: 4182
        Capabilities: [e0] PCI Advanced Features
                AFCap: TP+ FLR+
                AFCtrl: FLR-
                AFStatus: TP-
        Kernel driver in use: e1000e
        Kernel modules: e1000e

 

04:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
        Subsystem: Intel Corporation Gigabit ET Quad Port Server Adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin B routed to IRQ 17
        Region 0: Memory at 82400000 (32-bit, non-prefetchable) [size=128K]
        Region 1: Memory at 81c00000 (32-bit, non-prefetchable) [size=4M]
        Region 2: I/O ports at 2000 [size=32]
        Region 3: Memory at 82440000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
                Address: 0000000000000000  Data: 0000
                Masking: 00000000  Pending: 00000000
        Capabilities: [70] MSI-X: Enable+ Count=10 Masked-
                Vector table: BAR=3 offset=00000000
                PBA: BAR=3 offset=00002000
        Capabilities: [a0] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
                DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
                LnkCap: Port #4, Speed 2.5GT/s, Width x4, ASPM L0s L1, Latency L0 <4us, L1 <64us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
                DevCtl2: Completion Timeout: 4s to 13s, TimeoutDis-
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB
        Capabilities: [100] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
                UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
        Capabilities: [140] Device Serial Number 00-1b-21-ff-ff-7a-68-c6
        Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
                ARICap: MFVC- ACS-, Next Function: 0
                ARICtl: MFVC- ACS-, Function Group: 0
        Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
                IOVCap: Migration-, Interrupt Message Number: 000
                IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy-
                IOVSta: Migration-
                Initial VFs: 8, Total VFs: 8, Number of VFs: 0, Function Dependency Link: 01
                VF offset: 384, stride: 2, Device ID: 10ca
                Supported Page Size: 00000553, System Page Size: 00000001
                Region 0: Memory at 0000000000000000 (64-bit, non-prefetchable)
                Region 3: Memory at 0000000000000000 (64-bit, non-prefetchable)
                VF Migration: offset: 00000000, BIR: 0
        Kernel driver in use: igb
        Kernel modules: igb

 

А вот все девайсы разом.

 

00:00.0 Host bridge: Intel Corporation 3200/3210 Chipset DRAM Controller
        Subsystem: Intel Corporation Device 34d0
00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
        Subsystem: Intel Corporation Device 34d0
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode])
        Capabilities: [90] Subsystem: Intel Corporation Optiplex 755
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02) (prog-if 00 [Normal decode])
        Capabilities: [90] Subsystem: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) (prog-if 01 [Subtractive decode])
        Capabilities: [50] Subsystem: Intel Corporation Device 34d0
00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02)
        Subsystem: Intel Corporation Device 34d0
00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])
        Subsystem: Intel Corporation Device 34d0
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
        Subsystem: Intel Corporation Device 34d0
03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
        Subsystem: Intel Corporation Gigabit ET Quad Port Server Adapter
03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
        Subsystem: Intel Corporation Gigabit ET Quad Port Server Adapter
04:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
        Subsystem: Intel Corporation Gigabit ET Quad Port Server Adapter
04:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
        Subsystem: Intel Corporation Gigabit ET Quad Port Server Adapter
        Subsystem: Intel Corporation Device 0101
06:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)
        Subsystem: Intel Corporation Device 34d0

Edited by replicant

Share this post


Link to post
Share on other sites

replicant

я имел ввиду сравнить вывод на старом и новом ядре, а не разные сетевые карты, но по "LnkCtl: ASPM Disabled" можно заподозрить что оно отключено, хотя для уверенности надо проверить то же на PCI-E коммутаторе - это должно быть отдельное устр-во в том же списке.

 

BIOS пробовали обновить/откатить?

Share this post


Link to post
Share on other sites
BIOS пробовали обновить/откатить?

Я даже разные мат. платы вообще пробовал на разных чипсетах и везде одно и то же. Не думаю что дело в БИОС. Сделаю вывод чуть погодя и выложу, но ведь без шейпера работает, а логически в железяке и в выводе lspci от наличия / отсутствия шейпера вообще ничего не меняется. Какие-то подсистемы ядра 2.6.35.8 работают не так как на старых ядрах и это проявляется именно в комбинации tc + igb.

 

У меня есть еще мнение, что accel-pptp 0.8.5 не стыкуется с ядром 2.6.35.8, потому что шейпер нарезает на ppp интерфейсах. Но 0.8.5 версия работает на этом ядре в комбинации с другой сетевой картой и это вновь меня ставит в тупик. Просто переключаю внешний интерфейс на другую сетевую находу и работает как доктор прописал.

 

Поэтому я обращаюсь к всем, кто может подтвердить или опровергнуть наличие проблем в такой комбинации tc + igb + kernel 2.6.35.7 или 8, где igb внешний и внутренний интерфейсы, а сервер работает под accel-pptp.

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

 

Кто может помочь в моделировании у себя подобной связки ПО + железо? Нужно смоделировать чистую систему slackware 13.1 (обновиться до current по желанию) + ядро 2.6.35.7 + pptpd + минимальный шейпер на tbf или htb (можно даже взять код шейпера из темы по ссылке в первом посте).

 

Просто поднять snat или dnat, ip_forward и интерфейс ppp0 и прогнать несколько тестов на разных rate.

Edited by replicant

Share this post


Link to post
Share on other sites

Где-то видел информацию что во всем виноват segmentation offload для igb, попробуйте

ethtool -K ethХ tso off tx off sg off

Share this post


Link to post
Share on other sites
Где-то видел информацию что во всем виноват segmentation offload для igb, попробуйте

ethtool -K ethХ tso off tx off sg off

Тоже гуглил про это. Потом пробовал разные комбинации, но дело не в этом. Мне не помогло.

Share this post


Link to post
Share on other sites
BIOS пробовали обновить/откатить?

Я даже разные мат. платы вообще пробовал на разных чипсетах и везде одно и то же. Не думаю что дело в БИОС. Сделаю вывод чуть погодя и выложу, но ведь без шейпера работает, а логически в железяке и в выводе lspci от наличия / отсутствия шейпера вообще ничего не меняется. Какие-то подсистемы ядра 2.6.35.8 работают не так как на старых ядрах и это проявляется именно в комбинации tc + igb.

 

У меня есть еще мнение, что accel-pptp 0.8.5 не стыкуется с ядром 2.6.35.8, потому что шейпер нарезает на ppp интерфейсах. Но 0.8.5 версия работает на этом ядре в комбинации с другой сетевой картой и это вновь меня ставит в тупик. Просто переключаю внешний интерфейс на другую сетевую находу и работает как доктор прописал.

 

Поэтому я обращаюсь к всем, кто может подтвердить или опровергнуть наличие проблем в такой комбинации tc + igb + kernel 2.6.35.7 или 8, где igb внешний и внутренний интерфейсы, а сервер работает под accel-pptp.

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

 

Кто может помочь в моделировании у себя подобной связки ПО + железо? Нужно смоделировать чистую систему slackware 13.1 (обновиться до current по желанию) + ядро 2.6.35.7 + pptpd + минимальный шейпер на tbf или htb (можно даже взять код шейпера из темы по ссылке в первом посте).

 

Просто поднять snat или dnat, ip_forward и интерфейс ppp0 и прогнать несколько тестов на разных rate.

Подтверждаю наличие проблемы. Проблема есть у меня и на ядре 2.6.34.7, хотя на других сетевых картах и драйвере e1000e подобных проблем нет.

Сегодня наконец приехали несколько сетевых карт - поставил на тестовый сервак, ввел в работу и огреб по полной :(

 

Потестить подольше пока не получилось, но первое впечатление - не работает tbf, причем в этом случае vpn-соединение работет не на максимально-возможной скорости (как если-бы он не был-бы установлен на ppp-интерфейс) а на минимальной - 128 кБит или около того ...

 

Попробовал ваши рецепты, но никакого эффекта.

 

Железо:

серверная мама от Intel - S3420GP

проц: Intel® Xeon® CPU X3440 @ 2.53GHz

On-board сетевки, с которыми нет проблем, драйвер e1000e (ITR=100000):

1-я Intel 82578DM Gigabit Network Connection

2-я Intel 82574L Gigabit Network Connection

 

Софт:

Fedora 14, использую дефолтное ядро 2.6.35.6, accel-pptp-0.8.4, шейпер tbf на каждый ppp-интерфейс, нарезка скорости различная, от 1-2Мбит-а до 10-50Мбит

 

Сетевые, что пытался поставить:

Intel E1G42ET (Чип, Intel Corporation 82576 Gigabit Network Connection)

driver=igb driverversion=2.1.0-k2

куцый какой-то на опции, ни ITR нет, ни других ...

 

 

До детального разбора полетов все вернул назад ...

Обидно однако ... :(

Edited by vinnipux

Share this post


Link to post
Share on other sites
Подтверждаю наличие проблемы. Проблема есть у меня и на ядре 2.6.34.7, хотя на других сетевых картах и драйвере e1000e подобных проблем нет.

Сегодня наконец приехали несколько сетевых карт - поставил на тестовый сервак, ввел в работу и огреб по полной :(

 

Потестить подольше пока не получилось, но первое впечатление - не работает tbf, причем в этом случае vpn-соединение работет не на максимально-возможной скорости (как если-бы он не был-бы установлен на ppp-интерфейс) а на минимальной - 128 кБит или около того ...

Подумываю начать составлять багтрепорт (но не силен в английском), потому что такие сетевые используются для очень ответственных задач и многопроцессорных систем, но из-за наличия багов в последних версиях ядра применять их нет никакой возможности.

 

Может быть кто-то еще подтвердит наличие проблемы. Подождем еще результатов.

Edited by replicant

Share this post


Link to post
Share on other sites
Подтверждаю наличие проблемы. Проблема есть у меня и на ядре 2.6.34.7, хотя на других сетевых картах и драйвере e1000e подобных проблем нет.

Сегодня наконец приехали несколько сетевых карт - поставил на тестовый сервак, ввел в работу и огреб по полной :(

 

Потестить подольше пока не получилось, но первое впечатление - не работает tbf, причем в этом случае vpn-соединение работет не на максимально-возможной скорости (как если-бы он не был-бы установлен на ppp-интерфейс) а на минимальной - 128 кБит или около того ...

Подумываю начать составлять багтрепорт (но не силен в английском), потому что такие сетевые используются для очень ответственных задач и многопроцессорных систем, но из-за наличия багов в последних версиях ядра применять их нет никакой возможности.

 

Может быть кто-то еще подтвердит наличие проблемы. Подождем еще результатов.

ChangeLog не пробовали смотреть????

 

Попробуйте чистое 2.6.35, без патчей (2.6.35.х) может оно заработает)))

 

 

Share this post


Link to post
Share on other sites
ChangeLog не пробовали смотреть????

 

Попробуйте чистое 2.6.35, без патчей (2.6.35.х) может оно заработает)))

Смотрел по всей ветви 2.6.35.х, но, если честно, то я не очень понимаю что именно там надо искать и что именно могло повлиять на работу. Это могло быть все что угодно. Конечно, скорее всего это сетевые подсистемы ядра.

 

Надо проверять все ядра начиная с 2.6.33.7 (максимальное по версии, на котором заработало из тех, что я проверял) и вверх до 2.6.35.7 и посмотреть на каком откажет шейпер. Вот между этими ядрами и смотреть лог изменений.

 

2 vinnipux, встроенный драйвер куцый, но не работает с любой версией igb дров начиная с 2.0.6 (ниже не смотрел и на мой взгляд вообще дело не в них).

Edited by replicant

Share this post


Link to post
Share on other sites

Могу сказать, что в своё время тестировал ядро 2.6.32.7 + igb 2.1.9. Заметил следующие странности:

 

1. htb работало очень странно, непредсказуемо.

 

2. tbf работало, но как-то не совсем так, как на других сетевухах.

 

3. не работал полисер на output интерфейса, на input работал. С такими же параметрами полисер на выход работал на других картах.

 

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

 

P.S. Все qdisc и policers я пробовал делать на вланах (на сабинтерфейсах).

Edited by wtyd

Share this post


Link to post
Share on other sites

Из вcего топика не понял в чем проблема. В чем конкретно выражается некорректность работы шейпера?

Share this post


Link to post
Share on other sites
Из вcего топика не понял в чем проблема. В чем конкретно выражается некорректность работы шейпера?

Вместо нужного ограничения по скорости он либо срезает скорость почти до нуля, либо ограничивает ее рандомно, но не более 20 кбайт/с. Т.е. может не работать входящий или исходящий, могут не проходить большие пакеты и т.п.

 

Работает совершенно не прогнозируемо и режет скорость так, что у абонента в браузере ничего не открывается или открывается как на модеме 33.6 или около того. Игры с burst ни к чему не привели. Причем не работает не только tbf, но htb. Все проверенные алгоритмы шейпирования сбоят.

Share this post


Link to post
Share on other sites
tc class show dev xxx

что кажет?

 

Шейпер установлен на 8000 кбит/с Ядро 2.6.35.7 снаружи igb (шейпер глючит и непредсказуем)

 

tc class show dev ppp82

class tbf 8001:1 parent 8001:

 

Это же самое ядро. Этот же самый сервер, но снаружи tg3 (шейпер работает как часы)

 

tc class show dev ppp18

class tbf a85a:1 parent a85a:

=================

class tbf и parent идут по порядку с момента первого соединения и навешивания на него правила шейпера и это не вызывает никаких нареканий. Разницу между работающим ядром и не работающим здесь не засечь. Вывод совершенно одинаковый.

Edited by replicant

Share this post


Link to post
Share on other sites

Как это объяснить? eth1 - igb, eth3 - tg3, eth4 - e1000e. Картинка снята на одном и том же ядре и одном и том же сервере. Связка e1000e-tg3 работает в любых направлениях. Связка с внешней картой igb не работает. Это кол-во очередей в сетевой карте что-ли? В двухпортовой Intel E1G42ET их 16 по 8 на каждый интерфейс. Вроде бы все сходится. Стоит ли на это обращать внимание?

--------------------------------------------------

tc class show dev eth1

class mq :1 root

class mq :2 root

class mq :3 root

class mq :4 root

class mq :5 root

class mq :6 root

class mq :7 root

class mq :8 root

class mq :9 root

class mq :a root

class mq :b root

class mq :c root

class mq :d root

class mq :e root

class mq :f root

class mq :10 root

 

tc class show dev eth3

class mq :1 root

class mq :2 root

class mq :3 root

class mq :4 root

class mq :5 root

 

tc class show dev eth4

вообще ничего

Edited by replicant

Share this post


Link to post
Share on other sites

Я так понимаю что решения, кроме отката на ядра 2.6.27.х или замены сетевых карт на другую модель с драйвером "не igb" нет?

Edited by replicant

Share this post


Link to post
Share on other sites

Вероятно бага проявляется именно с этим ядром :( У меня были случаи что неправильно резало, но виноват был оффлоад и его отключение на всех интерфейсах снимало вопрос.

Share this post


Link to post
Share on other sites

Я тут вообще стенд вот такой собрал. Клиент цепляется к серверу pptp и на его ppp интерфейс навешивается правило шейпера, дальше клиент видит два сервера, стоящие за тестовым. На обоих серверах поднят ftp-http на upload/download.

 

post-76605-1290429274_thumb.png

 

С сервером 1 полная ерунда (ни скорости ни стабильности в работе шейпера), а с сервером 2 все отлично в обе стороны все шейпится и полисится по тарифу и все замечательно.

 

Единственное что осталось это перебрать разные версии accel-pptp. Пока ясно что на 0.8.3 - 0.8.5 не работает.

Edited by replicant

Share this post


Link to post
Share on other sites

видимо прийдется вам искать багу с помощью git bisect: http://kerneltrap.org/node/11753 http://www.linux-kongress.org/2009/slides/...tian_couder.pdf Если повезет, за 10-20 пересборок ядра можно найти проблему

Share this post


Link to post
Share on other sites
видимо прийдется вам искать багу с помощью git bisect: http://kerneltrap.org/node/11753 http://www.linux-kongress.org/2009/slides/...tian_couder.pdf Если повезет, за 10-20 пересборок ядра можно найти проблему

Не думаю что этот метод поиска ограничится 10-20 сборками, если вообще приведет к решению.

 

1. Не понятно что искать вообще.

2. Не работает как минимум со всеми ядрами 2.6.35.х, а возможно и с 2.6.34.х и 2.6.33.х, поэтому проблема древняя и появилась в какой-то ветке ядра целиком и дальше тянется во всех новых ветках, а не в одном ядре из ветки.

3. Проблему подтверждают на разных ОС с аналогичной сетевой картой и последними ядрами (выше 2.6.27.х).

Edited by replicant

Share this post


Link to post
Share on other sites

Кажется нашел что влияло. На одной из сборок не подтвердился глюк шейпера. Сейчас найду отличия, но, если мне не изменяет память то это GRO (LRO) в ядре.

 

Сетевые e1000e и tg3 этого просто не понимают по-умолчанию, а igb понимает, но реализация этого влияет на шейпер транзитного трафика. Сейчас тесты провожу.

Edited by replicant

Share this post


Link to post
Share on other sites

Единственная работоспособная комбинация для igb на новых ядрах. sg, tso, gso и тем более tx выключать не стоит. В новых ядрах после 2.6.27.х появился механизм GRO (LRO), который надо выключить.

 

rx-checksumming: on

tx-checksumming: on

scatter-gather: on

tcp-segmentation-offload: on | off

udp-fragmentation-offload: off

generic-segmentation-offload: on

generic-receive-offload: off

large-receive-offload: off

-----------------------------

 

На некоторых системах в выводе ethtool -k нет generic-receive-offload (поэтому я сразу и не нашел глюк) и тут уже не знаю что придумывать. На таких системах придется как-то выкручиваться и делать так, чтобы опция отключения gro появилась (простым включение в ядре LRO не отделаться).

Edited by replicant

Share this post


Link to post
Share on other sites
Единственная работоспособная комбинация для igb на новых ядрах. sg, tso, gso и тем более tx выключать не стоит. В новых ядрах после 2.6.27.х появился механизм GRO (LRO), который надо выключить.

 

rx-checksumming: on

tx-checksumming: on

scatter-gather: on

tcp-segmentation-offload: on | off

udp-fragmentation-offload: off

generic-segmentation-offload: on

generic-receive-offload: off

large-receive-offload: off

-----------------------------

 

На некоторых системах в выводе ethtool -k нет generic-receive-offload (поэтому я сразу и не нашел глюк) и тут уже не знаю что придумывать. На таких системах придется как-то выкручиваться и делать так, чтобы опция отключения gro появилась.

На моих системах эти опции есть, как для ядра 2.6.34.7 (ethtool version 2.6.33-pre1) так и для 2.6.35.6 (ethtool version 2.6.34)

Завтра проведу тесты, посмотрим что получится.

Это решение справедливо для случая igb + igb и использования двухголовой карты ?

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this