replicant Опубликовано 19 ноября, 2010 (изменено) · Жалоба Сразу скажу, что тему создал в продолжение вот этой 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=&...st&p=559457 Изменено 22 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 19 ноября, 2010 · Жалоба может ASPM? попробуйте сравнить вывод lspci -vvv старого и нового ядер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 19 ноября, 2010 (изменено) · Жалоба может 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 Изменено 19 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 19 ноября, 2010 · Жалоба replicant я имел ввиду сравнить вывод на старом и новом ядре, а не разные сетевые карты, но по "LnkCtl: ASPM Disabled" можно заподозрить что оно отключено, хотя для уверенности надо проверить то же на PCI-E коммутаторе - это должно быть отдельное устр-во в том же списке. BIOS пробовали обновить/откатить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 19 ноября, 2010 (изменено) · Жалоба 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. Изменено 19 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 19 ноября, 2010 · Жалоба Где-то видел информацию что во всем виноват segmentation offload для igb, попробуйте ethtool -K ethХ tso off tx off sg off Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 19 ноября, 2010 · Жалоба Где-то видел информацию что во всем виноват segmentation offload для igb, попробуйтеethtool -K ethХ tso off tx off sg off Тоже гуглил про это. Потом пробовал разные комбинации, но дело не в этом. Мне не помогло. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vinnipux Опубликовано 19 ноября, 2010 (изменено) · Жалоба 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 нет, ни других ... До детального разбора полетов все вернул назад ... Обидно однако ... :( Изменено 19 ноября, 2010 пользователем vinnipux Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 19 ноября, 2010 (изменено) · Жалоба Подтверждаю наличие проблемы. Проблема есть у меня и на ядре 2.6.34.7, хотя на других сетевых картах и драйвере e1000e подобных проблем нет.Сегодня наконец приехали несколько сетевых карт - поставил на тестовый сервак, ввел в работу и огреб по полной :( Потестить подольше пока не получилось, но первое впечатление - не работает tbf, причем в этом случае vpn-соединение работет не на максимально-возможной скорости (как если-бы он не был-бы установлен на ppp-интерфейс) а на минимальной - 128 кБит или около того ... Подумываю начать составлять багтрепорт (но не силен в английском), потому что такие сетевые используются для очень ответственных задач и многопроцессорных систем, но из-за наличия багов в последних версиях ядра применять их нет никакой возможности. Может быть кто-то еще подтвердит наличие проблемы. Подождем еще результатов. Изменено 19 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 19 ноября, 2010 · Жалоба Подтверждаю наличие проблемы. Проблема есть у меня и на ядре 2.6.34.7, хотя на других сетевых картах и драйвере e1000e подобных проблем нет.Сегодня наконец приехали несколько сетевых карт - поставил на тестовый сервак, ввел в работу и огреб по полной :( Потестить подольше пока не получилось, но первое впечатление - не работает tbf, причем в этом случае vpn-соединение работет не на максимально-возможной скорости (как если-бы он не был-бы установлен на ppp-интерфейс) а на минимальной - 128 кБит или около того ... Подумываю начать составлять багтрепорт (но не силен в английском), потому что такие сетевые используются для очень ответственных задач и многопроцессорных систем, но из-за наличия багов в последних версиях ядра применять их нет никакой возможности. Может быть кто-то еще подтвердит наличие проблемы. Подождем еще результатов. ChangeLog не пробовали смотреть???? Попробуйте чистое 2.6.35, без патчей (2.6.35.х) может оно заработает))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 20 ноября, 2010 (изменено) · Жалоба ChangeLog не пробовали смотреть???? Попробуйте чистое 2.6.35, без патчей (2.6.35.х) может оно заработает))) Смотрел по всей ветви 2.6.35.х, но, если честно, то я не очень понимаю что именно там надо искать и что именно могло повлиять на работу. Это могло быть все что угодно. Конечно, скорее всего это сетевые подсистемы ядра. Надо проверять все ядра начиная с 2.6.33.7 (максимальное по версии, на котором заработало из тех, что я проверял) и вверх до 2.6.35.7 и посмотреть на каком откажет шейпер. Вот между этими ядрами и смотреть лог изменений. 2 vinnipux, встроенный драйвер куцый, но не работает с любой версией igb дров начиная с 2.0.6 (ниже не смотрел и на мой взгляд вообще дело не в них). Изменено 20 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 20 ноября, 2010 (изменено) · Жалоба Могу сказать, что в своё время тестировал ядро 2.6.32.7 + igb 2.1.9. Заметил следующие странности: 1. htb работало очень странно, непредсказуемо. 2. tbf работало, но как-то не совсем так, как на других сетевухах. 3. не работал полисер на output интерфейса, на input работал. С такими же параметрами полисер на выход работал на других картах. Деталей уже не помню, в продакшен так и не стали ставить, т.к. трудно прогнозируемое и плохо проверяемое решение получилось. P.S. Все qdisc и policers я пробовал делать на вланах (на сабинтерфейсах). Изменено 20 ноября, 2010 пользователем wtyd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 20 ноября, 2010 · Жалоба Из вcего топика не понял в чем проблема. В чем конкретно выражается некорректность работы шейпера? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 22 ноября, 2010 · Жалоба Из вcего топика не понял в чем проблема. В чем конкретно выражается некорректность работы шейпера? Вместо нужного ограничения по скорости он либо срезает скорость почти до нуля, либо ограничивает ее рандомно, но не более 20 кбайт/с. Т.е. может не работать входящий или исходящий, могут не проходить большие пакеты и т.п. Работает совершенно не прогнозируемо и режет скорость так, что у абонента в браузере ничего не открывается или открывается как на модеме 33.6 или около того. Игры с burst ни к чему не привели. Причем не работает не только tbf, но htb. Все проверенные алгоритмы шейпирования сбоят. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stelsik Опубликовано 22 ноября, 2010 · Жалоба tc class show dev xxx что кажет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 22 ноября, 2010 (изменено) · Жалоба 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 идут по порядку с момента первого соединения и навешивания на него правила шейпера и это не вызывает никаких нареканий. Разницу между работающим ядром и не работающим здесь не засечь. Вывод совершенно одинаковый. Изменено 22 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 22 ноября, 2010 (изменено) · Жалоба Как это объяснить? 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 вообще ничего Изменено 22 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 22 ноября, 2010 (изменено) · Жалоба Я так понимаю что решения, кроме отката на ядра 2.6.27.х или замены сетевых карт на другую модель с драйвером "не igb" нет? Изменено 22 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 22 ноября, 2010 · Жалоба Вероятно бага проявляется именно с этим ядром :( У меня были случаи что неправильно резало, но виноват был оффлоад и его отключение на всех интерфейсах снимало вопрос. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 22 ноября, 2010 (изменено) · Жалоба Я тут вообще стенд вот такой собрал. Клиент цепляется к серверу pptp и на его ppp интерфейс навешивается правило шейпера, дальше клиент видит два сервера, стоящие за тестовым. На обоих серверах поднят ftp-http на upload/download. С сервером 1 полная ерунда (ни скорости ни стабильности в работе шейпера), а с сервером 2 все отлично в обе стороны все шейпится и полисится по тарифу и все замечательно. Единственное что осталось это перебрать разные версии accel-pptp. Пока ясно что на 0.8.3 - 0.8.5 не работает. Изменено 22 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 22 ноября, 2010 · Жалоба видимо прийдется вам искать багу с помощью git bisect: http://kerneltrap.org/node/11753 http://www.linux-kongress.org/2009/slides/...tian_couder.pdf Если повезет, за 10-20 пересборок ядра можно найти проблему Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 22 ноября, 2010 (изменено) · Жалоба видимо прийдется вам искать багу с помощью 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.х). Изменено 22 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 22 ноября, 2010 (изменено) · Жалоба Кажется нашел что влияло. На одной из сборок не подтвердился глюк шейпера. Сейчас найду отличия, но, если мне не изменяет память то это GRO (LRO) в ядре. Сетевые e1000e и tg3 этого просто не понимают по-умолчанию, а igb понимает, но реализация этого влияет на шейпер транзитного трафика. Сейчас тесты провожу. Изменено 22 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 22 ноября, 2010 (изменено) · Жалоба Единственная работоспособная комбинация для 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 не отделаться). Изменено 22 ноября, 2010 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vinnipux Опубликовано 22 ноября, 2010 · Жалоба Единственная работоспособная комбинация для 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 и использования двухголовой карты ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
