Jump to content

Очень важный вопрос к знатокам по Linux

replicant
 Share

Recommended Posts

replicant

replicant

Posted
Posted (edited)

Сразу скажу, что тему создал в продолжение вот этой 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
replicant

replicant

Posted
  • Author
Posted (edited)
может 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
vitalyb

vitalyb

Posted
Posted

replicant

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

 

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

replicant

replicant

Posted
  • Author
Posted (edited)
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
replicant

replicant

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

ethtool -K ethХ tso off tx off sg off

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

vinnipux

vinnipux

Posted
Posted (edited)
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
replicant

replicant

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

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

 

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

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

 

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

Edited by replicant
telecom

telecom

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

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

 

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

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

 

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

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

 

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

 

 

replicant

replicant

Posted
  • Author
Posted (edited)
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
wtyd

wtyd

Posted
Posted (edited)

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

 

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

 

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

 

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

 

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

 

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

Edited by wtyd
replicant

replicant

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

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

 

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

replicant

replicant

Posted
  • Author
Posted (edited)
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
replicant

replicant

Posted
  • Author
Posted (edited)

Как это объяснить? 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
replicant

replicant

Posted
  • Author
Posted (edited)

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

Edited by replicant
SokolovS

SokolovS

Posted
Posted

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

replicant

replicant

Posted
  • Author
Posted (edited)

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

 

post-76605-1290429274_thumb.png

 

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

 

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

Edited by replicant
replicant

replicant

Posted
  • Author
Posted (edited)
видимо прийдется вам искать багу с помощью 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
replicant

replicant

Posted
  • Author
Posted (edited)

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

 

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

Edited by replicant
replicant

replicant

Posted
  • Author
Posted (edited)

Единственная работоспособная комбинация для 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
vinnipux

vinnipux

Posted
Posted
Единственная работоспособная комбинация для 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 и использования двухголовой карты ?

 

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.