Падение скорости при аплоаде после обновления ядра

А где информация по сетевухам и модулям?

Ну а зачем вы переходили на новое ядро? Есть какая-то конкретная причина? Или вам просто поиграться со сборкой нового ядра?

Нет, если действительно есть, то повышайте уровень логирования ядра и смотрите, что оно будет вам «говорить». Плюс почитайте change логи ядра на предмет изменений в используемых вами драйверах. Заодно проверьте с какой версии ядра появилась указанная вами проблема, т.е. собирайте ядро более младших версий, отходя по одной ревизии, т.е., к примеру 3.12.13, затем 3.12.12 и так далее, если конечно вносились изменения в код драйверов, на этой ревизии.

Как найдёте ядро, на котором проблем нет то помещайте баг репорт, с указанием на какой версии ядра проблем нет, а с какой уже появились. Не забудьте включить вывод отладочных собщений и вообще более высокий уровень вывода сообщений ядром.

А в этом есть необходимость учитывая то, что на других версиях ядра все работает отлично? Просто на текущий момент я откатился на 3.6.8, напишите, листинги каких команд приложить и с какой детализацией, перегружусь, приложу (lspci? modinfo?).

Если коротко - сетевая карта смотрящая в локалку:

02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5723 Gigabit Ethernet PCIe (rev 10)

На самом деле есть мысли, что проблема собственно не в модулях, а скорее где-то в NF части ядра. Хотя что там может сломаться - обычный маскарадинг...

Да, была необходимость. У меня простаивает usb wifi адаптер на базе ралинк 3573. В какой-то момент в модуль rt2800usb добавили его экспериментальную поддержку. Хотелось заменить свой текущий wifi адаптер в сервере.

Декрементировать ревизию это жестоко :) Ядро собирается около двух часов :)

Ядро 2 часа ? Ты на 386dx25 собираешь ? 40 минут на 386dx40/4M собирались ядра 1.3.Х и 10 минут на 386dx40/8M. C тех пор пингвинчик конечно располнел, но не до такой же степени.

Если так интересно: AMD Turion(tm) II Neo N40L Dual-Core Processor Может быть не два, а полтора, но совершенно точно не меньше часа. Но это как бы не по теме, да.

На тему wifi - я бы пошел на openwrt и посмотрел бы там наборы патчей. https://dev.openwrt.org/browser/trunk/package/kernel/mac80211/patches?rev=378... видно, что для rt2x00 есть несколько патчей. Возможно, что кто-то из них лечит проблему со скоростью. Только они на 3.8 ядрах :(

На 3.14 пока рано, 3.12 - пока стабильная ветка, в 3.13 и выше очень активно переделывают netfilter :(

Я на 3.12 с intel 82574L проблем со скоростью не получил.

Что мешает протестировать скорость старым добрым iperf ? На время тестирования можно отключить netfilter...

Я бы еще ethtool-ом посмотрел на всяки tso

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

Но этот вариант тоже стоит учитывать. В модулях тоже бывают регрессии.

Вы не поняли или не очень внимательно прочили первоначальный пост. К wifi в моем случае претензий нет. Перейти на адаптер с ралинк 3573 захотелось по причине того, что он банально более продвинутей моего текущего риалтека. Для 3573 были драйвера и ранее, но они не поддерживали nl80211 и заставить с ними работать hostapd не получалось. Но проблема не в этом, это просто причина сборки нового ядра.
Я не вижу смысла тестировать аплоад разными способами - проблема есть в любом случае, я ее что называется вижу воочию. Но при этом она есть на ядре 3.14 и только для проводных lan клиентов. У беспроводных wifi клиентов все замечательно со скоростью аплоада. Отключить iptables я не смогу банально потому, что тогда не будет маскарадинга.

А можно подробнее, что вы имели ввиду относительно ethtool и tso?

я про «ethtool -k ethX»

Я бы обязательно выключил tcp-segmentation-offload, large-receive-offload, проверил включено ли tx-checksumming

Медленная передача - значит должны быть и ошибки. Нужно смотреть счетчики ошибок начиная с /proc/net/snmp.

Посмотреть на число ошибок в «ethtool -S ethX»

Скорость отдачи зависит от ОS на клиентской машине?

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

В конце концов раз скорость маленькая, то можно tcpdump-ом захватить немного трафика, а там будет видна причина низкой скорости.

Может быть не два, а полтора, но совершенно точно не меньше часа.

genkernel-ем с полным конфигом собираешь небось? А если повыкидывать из ядра ненужный тебе хлам?

Вы что-то брешете. Не уж-то у вас какой-то Pentium III?

Вы хоть знаете, что ядро можно собирать в несколько потоков, для этого есть параметр '-j', кроме всего прочего если обтимизировать конфигурацию ядра под конфигурацию целевой системы, то время сборки ядра в 4 потока можно сократить до 4-5 минут.

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

make -jN bzImage
make -jN modules
make install
make modules_install

Где N - число потоков сборки ядра.

Нормальный процессор. Так и скажи, что не умеешь оптимизировать конфигурацию ядра и производить сборку в несколько потоков, смотри мой предыдущий комментарий. В итоге всё теже минут 5, может 6 с оптимизацией конфигурации ядра и сборкой в несколько потоков, ну или минут 15 без оптимизации, но сборкой всё так же в несколько потоков.

Ох. Товарищ, вы мудак или просто так умело притворяетесь? Вы заметили, как называется тема? Если нечего сказать по существу вопроса просто воздержитесь от постов. Если я скажу, что «я не умею _оптимизировать_», надеюсь я больше вас в этой теме не увижу, правда?

Даже если бы я использовал распараллеливание при текущем конфиге я бы не добился значительного ускорения сборки. Но у меня нет никакого желания и времени для того, чтобы задротствовать с настройками конфига. Изначально за основу был взят конфиг дистрибутива cent os, который собственно и стоял у меня на сервере. Я не собираю ядро для embedded системы.

Печально, что на каждом форуме обязательно найдется имбецил желающий попиарить свою пубертатный и сомнительные достижения в «оптимизации» на публику вместо того, чтобы действительно помочь с решением проблемы.

Как тут уже советовали, попробуйте iperf между компом в локалке и шлюзом, например. В принципе могу врубить iperf на прослушивание на внешнем адресе, чтобы проверить, в чем проблема. Сам сижу на 3.14+ ядре из арча, падения скорости не обнаружено, хотя подозрения были.

Недавно обновил ядро до 3.14

Для CentOS есть уже собранное ядро в elrepo (в архиве есть и 3.12 и 3.13, ничего собирать не надо)

Мда, на форуме 3 дня, а уже начинает в позу вставать. По сути, если не хочешь разбираться почему так оно работает, т.е. изменять конфиг, собирать другие версии ядра, то иди на фиг отсюда и не ной. За тебя ни кто в том, что тебе нужно самому разбираться не будет. Тебе указали на пути решения, не хочешь им следовать - иди гуляй стороной.

Ну и не забудь почитать правила форуме, прежде чем писать что-либо сюда www.linux.org.ru/rules.jsp.

На досуге проверю. Но проблемы между клиентом и назовем его шлюзом по проводу скорее всего нет. Я бы это заметил потому как довольно часто заливаю на него файлы через scp.

На счет зависимости от OS точно ничего не могу сказать - под рукой только Windows 7. Остальные клиенты андроиды по «воздуху». Когда появится время, займусь-отпишусь.