[vitalyb]

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

NiTr0 на 10й странице задавал вопрос...

 

Касательно аффинити... Без специальной поддержки железа и драйвера Linux не умеет один сетевой интерфейс обслуживать несколькими ядрами.

 

Т.е. если вы в /proc/interrupts видите

380:          0         0     0       0   PCI-MSI-edge      eth0

Это значит, что трафик с сетевой может обрабатываться только одим ядром в один момент времени. Это "одно ядро" выбирается из аффинити маск. Тот факт, что при, скажем, аффинити f видно что у всех ядер si по 25% объясняется усредненим - за указаный интервал ортаботали все 4 ядра по очереди. Хотя может показаться, что есть "запас в 4 раза", на самом деле - всё, приехали, надо срочно что-то делать. А таких случаях ksoftirqd/X начинает "кушать" CPU и "прилипает" к одному ядру, хотя всегда было 0.0%, подпрыгивает LA, в особо запущенных случаях (и при соотв. сборке ядра) ядро ругается на Soft-Lockup. Это, в частности, относится и к форвардингу трафика, и шейперам.

 

Сетевой интерфейс (Intel, драйвер igb, Linux 2.6.28), который умеет работать с несколькими ядрами одновременно выглядит так ("фотошоп", скопипастить сейчас не могу):

380:          0         0      0       0   PCI-MSI-edge      eth0
381:          0         0      0       0   PCI-MSI-edge      eth0-tx0
382:          0         0      0       0   PCI-MSI-edge      eth0-tx1
383:          0         0      0       0   PCI-MSI-edge      eth0-tx2
384:          0         0      0       0   PCI-MSI-edge      eth0-tx3
385:          0         0      0       0   PCI-MSI-edge      eth0-rx0
386:          0         0      0       0   PCI-MSI-edge      eth0-rx1
387:          0         0      0       0   PCI-MSI-edge      eth0-rx2
388:          0         0      0       0   PCI-MSI-edge      eth0-rx3

- по 4 очереди на прием и отправку.

 

Как это относится к сабжу пока не знаю - смотря где происходит обработка трафика, в ближайшем будущем планирую опробовать.

 

[[anp/hsw]]

кстати, еще один насущный вопрос: модуль pptp может работать одновременно с pppoe-клиентом?

 

у меня странно, но видимо не работает

(выдержка из lsmod)

pptp 9396 0 (unused)

pppox 1544 1 [pptp]

ppp_generic 28428 81 [ppp_mppe_mppc ppp_async pptp pppox]

 

да и в modules.conf alias net-pf-24 занят под pppoe, если его прописать под pptp - pppoe уже не поднимается.

а если вручную прописать в option.pptpd "plugin pptp.so", то плагин загружается, но ругается на опции, передаваемые pppd (в частности скорость "115200")

 

что я делаю нетак? (ядро, опять же, 2.4)

 

дополнение: если первым запустить pptp, то он работает, но pppoe - нет :)

 

mega pppd[12995]: PADS: Service-Name: ''

mega pppd[12995]: PPP session is 8680

mega pppd[12995]: Failed to create PPPoE socket: Protocol not supported

 

Изменено 7 августа, 2009 пользователем [anp/hsw]

[xeb]

кстати, еще один насущный вопрос: модуль pptp может работать одновременно с pppoe-клиентом?

не знаю как на 2.4, на 2.6 работает без проблем, на 2.4 тоже должно

 

(выдержка из lsmod)

pptp 9396 0 (unused)

pppox 1544 1 [pptp]

ppp_generic 28428 81 [ppp_mppe_mppc ppp_async pptp pppox]

mega pppd[12995]: PADS: Service-Name: ''

mega pppd[12995]: PPP session is 8680

mega pppd[12995]: Failed to create PPPoE socket: Protocol not supported

модуль pppoe не загружен, вот и не работает, поставь оба модуля где-нить в автозагрузку

 

[[anp/hsw]]

да, действительно, помогло.

просто оба модуля (pptp и pppoe) имеют один и тотже алиас: net-pf-24

поэтому грузился либо тот, либо другой

 

больше этот alias ни на что влиять не должен?

 

[xeb]

нет

[body]

Под CentOS 5.3 не собирается модуль ppp_generic_smp

 

[root@ultra work]# git clone git://accel-pptp.git.sourceforge.net/gitroot/accel-pptp
Initialized empty Git repository in /root/work/accel-pptp/.git/
remote: Counting objects: 227, done.
remote: Compressing objects: 100% (191/191), done.
Indexing 227 objects...
remote: Total 227 (delta 28), reused 211 (delta 21)
100% (227/227) done
Resolving 28 deltas...
100% (28/28) done
[root@ultra accel-pptp]# make server
echo Building kernel module
Building kernel module
(cd kernel/driver; make )
make[1]: Entering directory `/root/work/accel-pptp/kernel/driver'
using "/lib/modules/2.6.18-128.4.1.el5/build" kernel headers
make -C /lib/modules/2.6.18-128.4.1.el5/build SUBDIRS=/root/work/accel-pptp/kernel/driver modules
make[2]: Entering directory `/usr/src/kernels/2.6.18-128.4.1.el5-x86_64'
  CC [M]  /root/work/accel-pptp/kernel/driver/pptp.o
  CC [M]  /root/work/accel-pptp/kernel/driver/ppp_generic_smp.o
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c: In function ‘ppp_init’:
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:922: ошибка: implicit declaration of function ‘device_create_drvdata’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c: In function ‘ppp_start_xmit’:
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:970: ошибка: implicit declaration of function ‘skb_cow_head’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:990: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c: In function ‘ppp_send_frame’:
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:1136: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:1137: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:1212: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c: In function ‘ppp_mp_explode’:
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:1450: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c: In function ‘ppp_receive_frame’:
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:1583: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c: In function ‘ppp_receive_error’:
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:1592: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c: In function ‘ppp_receive_nonmp_frame’:
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:1672: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:1673: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c: In function ‘ppp_receive_mp_frame’:
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:1851: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c: In function ‘ppp_mp_reconstruct’:
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:1989: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:1998: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:2027: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c: In function ‘ppp_get_stats’:
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:2447: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:2448: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:2449: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:2450: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:2451: ошибка: ‘struct net_device’ has no member named ‘stats’
/root/work/accel-pptp/kernel/driver/ppp_generic_smp.c:2452: ошибка: ‘struct net_device’ has no member named ‘stats’
make[3]: *** [/root/work/accel-pptp/kernel/driver/ppp_generic_smp.o] Ошибка 1
make[2]: *** [_module_/root/work/accel-pptp/kernel/driver] Ошибка 2
make[2]: Leaving directory `/usr/src/kernels/2.6.18-128.4.1.el5-x86_64'
make[1]: *** [all] Ошибка 2
make[1]: Leaving directory `/root/work/accel-pptp/kernel/driver'
make: *** [module] Ошибка 2
[root@ultra accel-pptp]# rpm -qa | grep kernel
kernel-headers-2.6.18-128.4.1.el5
kernel-2.6.18-128.4.1.el5
kernel-devel-2.6.18-128.4.1.el5

 

Без этого модуля все нормально собирается и запускается.

На родных ядрах CentOS можно собрать этот модуль ?

Изменено 7 августа, 2009 пользователем body

[nick8080]

Здравствуйте,

у меня немного странный вопрос: как понять что модуль работает?

[root@server ~]# lsmod | grep pptp
pptp                   21136  0
pppox                   7625  1 pptp
ppp_generic            30037  9 ppp_deflate,pptp,pppox,ppp_mppe,ppp_async

 

[NiTr0]

Без модуля - pptpd в комплекте работать не будет ;)

[[anp/hsw]]

Здравствуйте,

у меня немного странный вопрос: как понять что модуль работает?

когда будет писать вторую цифру, отличную от нуля - значит работает.

 

еще помогает просмотр логов pppd на тему плагина "pptp":

Aug 15 02:55:04 mega pptp[5759]: Plugin pptp.so loaded.

Aug 15 02:55:04 mega pptp[5759]: PPTP plugin version 0.8.3 compiled for pppd-2.4.5, linux-2.4.37-anp18b4-thumper-smp4

Aug 15 02:55:04 mega pptp[5759]: pppd 2.4.5 started by root, uid 0

 

типа такого.

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

вот так примерно выглядит в ps правильный процесс accel-pppd:

 

root 5879 5865 0 02:55 ? 00:00:00 /usr/sbin/pppd 172.31.XX.XX: remotenumber 192.168.XX.XX - VIA 192.168.XX.XX local file /etc/ppp/options.pptpd 921600 ipparam 192.168.XX.XX plugin pptp.so pptp_client 192.168.XX.XX pptp_sock 6 nodetach

 

ключевые слова - все, что после "plugin"

если такого нету - то неправильно собран poptop (pptpd) - его тоже надо брать с сайта accel-pptp (или лучше из git)

Изменено 14 августа, 2009 пользователем [anp/hsw]

[xeb]

Без этого модуля все нормально собирается и запускается.<br />На родных ядрах CentOS можно собрать этот модуль ?<br />

этот модуль экспериментальный и собирается только на 2.6.28 и 2.6.29, в дальнейшим думаю исключить его...

[nick8080]

 

когда будет писать вторую цифру, отличную от нуля - значит работает.

 

еще помогает просмотр логов pppd на тему плагина "pptp":

Aug 15 02:55:04 mega pptp[5759]: Plugin pptp.so loaded.

Aug 15 02:55:04 mega pptp[5759]: PPTP plugin version 0.8.3 compiled for pppd-2.4.5, linux-2.4.37-anp18b4-thumper-smp4

Aug 15 02:55:04 mega pptp[5759]: pppd 2.4.5 started by root, uid 0

 

типа такого.

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

вот так примерно выглядит в ps правильный процесс accel-pppd:

 

root 5879 5865 0 02:55 ? 00:00:00 /usr/sbin/pppd 172.31.XX.XX: remotenumber 192.168.XX.XX - VIA 192.168.XX.XX local file /etc/ppp/options.pptpd 921600 ipparam 192.168.XX.XX plugin pptp.so pptp_client 192.168.XX.XX pptp_sock 6 nodetach

 

ключевые слова - все, что после "plugin"

если такого нету - то неправильно собран poptop (pptpd) - его тоже надо брать с сайта accel-pptp (или лучше из git)

 

 

Спасибо

 

Здраствуйте,

лог:

Aug 18 07:28:48 server217-174 pptpd[14108]: CTRL: Client x.x.62.254 control connection started
Aug 18 07:28:48 server217-174 pptpd[14108]: CTRL: Starting call (launching pppd, opening GRE)
Aug 18 07:28:48 server217-174 pptp[14109]: Plugin pptp.so loaded.
Aug 18 07:28:48 server217-174 pptp[14109]: PPTP plugin version 0.8.3 compiled for pppd-2.4.4, linux-2.6.18-128.4.1.el5.centos.plus
Aug 18 07:28:48 server217-174- pptp[14109]: unrecognized option '115200'
Aug 18 07:28:48 server217-174 pptpd[14108]: GRE: read(fd=6,buffer=8059680,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Aug 18 07:28:48 server217-174 pptpd[14108]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
Aug 18 07:28:48 server217-174 pptpd[14108]: CTRL: Client x.x.62.254 control connection finished

 

При соединении вылетает,

"unrecognized option '115200'" - появляется как с параметром speed так и без него.

процесса понятно нету......

необходимо пересобирать?

Изменено 18 августа, 2009 пользователем nick8080

[nick8080]

понятно, что ему это передают в таком виде......

где бы это подкрутить....

 

 

 

[xeb]

unrecognized option '115200'

оно находится в /etc/ppp/options или /etc/ppp/options.pptpd или еще в каких-то файлах в этом каталоге

 

Aug 18 07:28:48 server217-174 pptpd[14108]: GRE: read(fd=6,buffer=8059680,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs

Aug 18 07:28:48 server217-174 pptpd[14108]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)

хм, зачем ты poptop то используешь, используй pptpd из пакета accel-pptp, поэтому и не работает у тебя оно ...

 

[nick8080]

хм, зачем ты poptop то используешь, используй pptpd из пакета accel-pptp, поэтому и не работает у тебя оно ...

да помогло, спасибо.

[[anp/hsw]]

собственно, возникло две странные проблемы с accel-pptpd (git 04.08.2009):

1. некоторые клиенты (не удалось установить закономерность) после подключения сразу же отключаются (30-150 секунд), причина разрыва - "LCP terminated by peer", хотя я проверял - VPN-соединение под win пропадает само (т.е. даже не потеря связи, а винда сама по каким-то причинам желает отключиться) - с большой вероятностью повторимо на accel-ptpd

2. некоторые клиенты "залипают" - т.е. в логах мы видим коннект клиента, через минут 30 видим тот же коннект (но первый при этом еще не завершился). у меня стоит скрипт, который убивает создающийся vpn, при условии что такой адрес уже есть у одного ppp-интерфейса в системе (через if-up).

у юзера выглядит так: подключается интернет, через 30-60-90итд минут вылетает изза потери пакета (например у него wifi по квартире), потом пытается подключиться заново, но его в течении получаса уже не пускает на vpn "как будто кто-то сидит под моим логином". естественно, lcp-echo-interval и lcp-echo-failure в ppp включены

 

 

 

[NiTr0]

Странные вещи творятся... Работал сервер без проблем, порядка 50 дней, после чего - понадобилось его ребутнуть. И после ребута - начались проблемы с пингом... В вечернее время - пинг на сервер скачет в районе 20-30-50-300 мс, pps - порядка 20-30к пакетов в каждую из сторон. Сетевуха интел PRO/1000MT десктопная, ядро было 2.6.30-r1 (gentoo), дрова были из ядра. Accel-pptp - 0.8.3

Обновил ядро до 2.6.30-r4 (с обновлением мира попутно), пересобрал соответственно accel-pptp, собрал драйвер 8.0.13 с сайта интела, с включенным NAPI, в опциях драйвера указывал меньшую величину InterruptThrottlingRate (стояло 50000, снизил до 20000) - безрезультатно. Нагрузка при этом по htop - 0е ядро - порядка 10% (снмп и прочее), 1е - от 40 до 70-80% скачет.

Куда копать?

[xeb]

попробуй откатить ядро

[NiTr0]

Так ведь проблема появилась еще до апдейта ядра...

Попробую побаловаться еще с настройками модуля (занизил InterruptThrottleRate, увеличил кол-во буфферов и максимальную задержку на прием/передачу), если не поможет - ради эксперимента таки поставлю pci-e марвелл, посмотреть что изменится...

[NiTr0]

При занижении InterruptThrottleRate - ничего хорошего не случилось, скорее наоборот...

Смотрел iptraf - сейчас 17кппс на прием, 15-16кппс на отдачу, запускаю с другой машины ping -f - суммарный поток интерфейса падает со 160 до 110 мбит/с, ппс фактически не меняется (???), нагрузка правда сейчас меньше (перевел народ на другой сервер через днс) и пинг стабильно низкий.

Осталась идея вообще убрать форсирование InterruptThrottleRate, посмотреть что изменится...

[theMIROn]

Кстати, это принципиальная позиция не работоспособности persist с accel pptp или просто руки не дошли? А то удалось наконец прикрутить данное чудо к wive-ng и засада с persist всё портит. Если не сложно добавьтие в плагин обработку сего дела, в своём коде ИМХО проще разобраться чем мне.

Пока привернул вот такой костылик, но как-то оно не кузяво:

...

Зато гарантированно переподнимется, но ИМХО нужно сделать более элегантно.

persist не работает по причине 1-в-1 заимствования из юзерлевелного pptp, который запускается отдельным процессом из pppd. Плагин pppd.so работает в том же процессе, что и pppd.

1. Если в процессе создания подключения (pptp.c) произошла ошибка, то будет fatal сообщение с exit(1) и процесс pptp завершится.

В условиях плагина этот же код завершит сам весь pppd.

2. Если в процессе работы соединения (pptp_callmgr.c) прозошкла ошибка, то будет отослан сигнал SIGTERM в процесс pptp и (пр необходимости) в запущенный pppd, если не используется --nolaunchpppd.

В условиях плагина get_call_id выполняется с получением pid самого pppd, соответственно в pppd будет отправлен сигнал SIGTERM, из-за чего persist не сработает.

С этим патчем persist отлично работает

http://code.google.com/p/wl500g/source/bro...0-persist.patch

[[anp/hsw]]

С чем может быть связана ошибка "CTRL: failed to connect PPTP socket (Operation already in progress)" ?

изредка возникает при использовании accel-pptpd, раньше не наблюдалась

 

 

[sfstudio]

С этим патчем persist отлично работает

http://code.google.com/p/wl500g/source/bro...0-persist.patch

Ну дык значит нужно пнуть xeb для влючения в основную ветку ;)

[theMIROn]

С этим патчем persist отлично работает

http://code.google.com/p/wl500g/source/bro...0-persist.patch

Ну дык значит нужно пнуть xeb для влючения в основную ветку ;)

Дык уже.

Проявилась проблема, при реконнекте остаются незакрытые сокеты. Буду глядеть дальше

[vitalyb]

При занижении InterruptThrottleRate - ничего хорошего не случилось, скорее наоборот...

Смотрел iptraf - сейчас 17кппс на прием, 15-16кппс на отдачу, запускаю с другой машины ping -f - суммарный поток интерфейса падает со 160 до 110 мбит/с, ппс фактически не меняется (???), нагрузка правда сейчас меньше (перевел народ на другой сервер через днс) и пинг стабильно низкий.

Осталась идея вообще убрать форсирование InterruptThrottleRate, посмотреть что изменится...

AFAICT InterruptThrottleRate при включеном NAPI особого смысла не имеет. При определенном пороге срабатываний прерываний NAPI, образно говоря, на одно прерывание начинает вытягивать несколько пакетов.

 

Например,

10:13:34         INTR    intr/s
10:13:39          sum  36516.00

10:13:34        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
10:13:39           lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
10:13:39         eth0  46277.20  40815.00  40514.74  19843.81      0.00      0.00      0.00
10:13:39         eth1  40851.60  45487.60  19941.89  40403.39      0.00      0.00      0.00

 

У Вас точно CPU не перегужены?

 

[NiTr0]

Оно-то не имеет, но в драйвере, если верить описанию, включено и дефолтно стоит на 3000 что ли...

Поставил марвелл DGE-560T PCIe - с первой карточкой поимел гимора (карточка ревизии 11), в лог написала 1 раз о кривой чексумме пакета, спустя пару часов - порадовала тем, что подвисла и должна реинициализировать интерфейс, сессии посыпались, вочдог на радостях ребутнул машину (подумал, что серв повис - load average скакнул). После ребута -опять сообщение о битом пакете примерно через такое же время, но добиться подвисания интерфейса (насиловал с помощью iperf) не вышло. Заменил на другую, ревизии 13 - пока (с 5 утра) работает стабильно. На другой машине (роутер под 2.4 ядром с драйвером от вендора) стоит карточка ревизии 17 - тоже проблем с ней не наблюдалось. Возможно, дело в кривой еепромке (с 13 версии сдампил, попробую влить в 11ю). Хотя нельзя исключать и проблемы с кабелем (его тоже во время ревизии сменили, хотя особых подозрений не вызывал, на порту свича ошибок тоже вроде как не сыпалось массово).

 

Процессор - точно не перегружен был, смотрел htop. При ~50% загрузке ядра, обрабатывающего прерывания - начинались жуткие задержки пинга.

 

UPD:

Итак, с марвеллом повторяется та же ситуевина, что и с интелом.

top - 15:31:34 up 10:15, 470 users,  load average: 0.30, 0.32, 0.39
Tasks: 1015 total,   2 running, 1013 sleeping,   0 stopped,   0 zombie
Cpu0  :  1.0%us,  1.3%sy,  0.0%ni, 55.0%id,  0.0%wa,  0.7%hi, 42.0%si,  0.0%st
Cpu1  :  0.6%us,  2.2%sy,  0.0%ni, 96.9%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st

При этом пинги в 30-70 мс.

 

UPD2:

На более слабой машине (нфорс4 с атлоном 3200+, с дуал ддр400), ядро 2.6.23, проблем не возникает... Траффик под 200 мбит, загрузка проца под 100%, 30 кппс в каждую из сторон - проблема только с исходящим траффиком (там пользуется шейпер на ingress qdisc), пинг - не скачет. Будем менять материнку (на той мамке и раньше странные приколы были, но нерегулярные и не настолько явновыраженные).

 

UPD3:

Таки InterruptThrottleRate для NAPI имеет смысл - если система занимается еще и юзер-левел задачами. Суть NAPI хорошо описана тута.

 

UPD4:

Похоже, это как-то связано с htb - у меня eth0 пользовался для шейпинга исходящего траффика. После удаления с eth0 root qdisc - пинги на сервер упали, но при прохождении траффика через туннель - наблюдаются до 200-300мс задержки случайного характера. Странно, с нового года htb на eth0 вел себя нормально, на разных ядрах.

Смущает то, что в логах оседает много мессаг "htb: too many events!" (где-то 1 мессага в секунду при солидной нагрузке), и смущает мессага в dmesg где-то после 11000 сек "hrtimer: interrupt too slow, forcing clock min delta to 11733 ns".

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

Изменено 1 сентября, 2009 пользователем NiTr0