[nsa2006]

Мне бы Ваши проблемы с шейпером, тут сам по себе демон память жрёт, вот где проблема.

На каком ядре крутится система?

Жил на ядре 2.6.35.9 пробовал обновляться, проявлялись подобные проблемы.

На 2.6.36 и дальше не смотрел, ввиду нестабильности.

Изменено 16 февраля, 2012 пользователем nsa2006

[KotikBSd]

По поводу памяти, а вы htb шейперы используйте? burst у вас сколько в шейперах? :)

 

Я это к чему спрашиваю, очень большой burst может несчадно есть вашу память...

 

По поводу скорости, на больших тарифах скорость нормальная, главное сильно burst не наворачивать, при установке burst=speed*0.1, где speed это скорость тарифа, наблюдаются большие отклонения вверх по скорости, особенно на отдачу, у нас на IPoE burst по дефолту всегда 1550, независимо от скорости.

 

При тестах с ppp - установил 1590байт, мерилка скорсоти у яндекса сразу начала жестоко врать, если по тарифу скорост 37\10 мбит (вход\выход) то яндекс показывает 10\9, спидтест тоже занижает но не так сильно, в итоге я пришел к выводу что 30000-50000 достаточно оптимально, яндекс показал 32\10, спидтест 35\10.

 

Если мерить скорость просто перекачкой файла, то при очень большом burst исходящая скорость вначале очень большая, у меня была около 70 мбит, через 10 секунд вернулась к норме. В случаях с burst в 30000-50000 или даже 1590, скорость соответствует тарифной.

[lan-viper]

Мне бы Ваши проблемы с шейпером, тут сам по себе демон память жрёт, вот где проблема.

На каком ядре крутится система?

Жил на ядре 2.6.35.9 пробовал обновляться, проявлялись подобные проблемы.

На 2.6.36 и дальше не смотрел, ввиду нестабильности.

Linux nas 2.6.32-custom #1 SMP Wed Apr 20 08:56:37 MSD 2011 i686 GNU/Linux

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

 

По поводу памяти, а вы htb шейперы используйте? burst у вас сколько в шейперах? :)

 

Я это к чему спрашиваю, очень большой burst может несчадно есть вашу память...

 

По поводу скорости, на больших тарифах скорость нормальная, главное сильно burst не наворачивать, при установке burst=speed*0.1, где speed это скорость тарифа, наблюдаются большие отклонения вверх по скорости, особенно на отдачу, у нас на IPoE burst по дефолту всегда 1550, независимо от скорости.

 

При тестах с ppp - установил 1590байт, мерилка скорсоти у яндекса сразу начала жестоко врать, если по тарифу скорост 37\10 мбит (вход\выход) то яндекс показывает 10\9, спидтест тоже занижает но не так сильно, в итоге я пришел к выводу что 30000-50000 достаточно оптимально, яндекс показал 32\10, спидтест 35\10.

 

Если мерить скорость просто перекачкой файла, то при очень большом burst исходящая скорость вначале очень большая, у меня была около 70 мбит, через 10 секунд вернулась к норме. В случаях с burst в 30000-50000 или даже 1590, скорость соответствует тарифной.

Высказывал что-то подобное о burst несколькими страницами ранее.

Да, конечно использовал новый шейпер, ради этого и переустаналивал accel. Начиная с сегодняшнего дня сделал откат на релиз 1.5.0 с ручным внесением изменений из последующих некоторых коммитов (типа ошибки в синтаксисе и пр.). Буду наблюдать...

[NiTr0]

очень большой burst может несчадно есть вашу память...

burst по 500кб или более, по 3000 адресов на 3 ифейсах, потребление памяти всей системой от силы метров 500...

[Cramac]

Всем привет.

Подскажите, появилась такая проблема.

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

 

debug: : pptp: disconnect

info: : disconnected

и так много раз, до этого ничего подозрительного (на мой взгляд) нет.

Куда копать?

[Cramac]

еще зачастили записи типо:

[2012-02-19 20:26:59]: info: : recv [PPTP Start-Ctrl-Conn-Request <Version 1> <Framing 3> <Bearer 3> <Max-Chan 65535>]

[2012-02-19 20:26:59]: info: : send [PPTP Start-Ctrl-Conn-Reply <Version 1> <Result 1> <Error 0> <Framing 3> <Bearer 3> <Max-Chan 1>]

[2012-02-19 20:26:59]: info: : recv [PPTP Start-Ctrl-Conn-Request <Version 1> <Framing 1> <Bearer 1> <Max-Chan 0>]

[2012-02-19 20:26:59]: info: : send [PPTP Start-Ctrl-Conn-Reply <Version 1> <Result 1> <Error 0> <Framing 3> <Bearer 3> <Max-Chan 1>]

[2012-02-19 20:26:59]: info: : recv [PPTP Start-Ctrl-Conn-Request <Version 1> <Framing 1> <Bearer 1> <Max-Chan 0>]

[2012-02-19 20:26:59]: info: : send [PPTP Start-Ctrl-Conn-Reply <Version 1> <Result 1> <Error 0> <Framing 3> <Bearer 3> <Max-Chan 1>]

[2012-02-19 20:26:59]: info: : recv [PPTP Start-Ctrl-Conn-Request <Version 1> <Framing 1> <Bearer 1> <Max-Chan 0>]

[2012-02-19 20:26:59]: info: : send [PPTP Start-Ctrl-Conn-Reply <Version 1> <Result 1> <Error 0> <Framing 3> <Bearer 3> <Max-Chan 1>]

[2012-02-19 20:26:59]: info: : recv [PPTP Start-Ctrl-Conn-Request <Version 1> <Framing 1> <Bearer 1> <Max-Chan 0>]

[2012-02-19 20:26:59]: info: : send [PPTP Start-Ctrl-Conn-Reply <Version 1> <Result 1> <Error 0> <Framing 3> <Bearer 3> <Max-Chan 1>]

[2012-02-19 20:26:59]: info: : recv [PPTP Start-Ctrl-Conn-Request <Version 1> <Framing 1> <Bearer 1> <Max-Chan 0>]

[2012-02-19 20:26:59]: info: : send [PPTP Start-Ctrl-Conn-Reply <Version 1> <Result 1> <Error 0> <Framing 3> <Bearer 3> <Max-Chan 1>]

[2012-02-19 20:26:59]: info: : recv [PPTP Start-Ctrl-Conn-Request <Version 1> <Framing 1> <Bearer 1> <Max-Chan 0>]

[2012-02-19 20:26:59]: info: : send [PPTP Start-Ctrl-Conn-Reply <Version 1> <Result 1> <Error 0> <Framing 3> <Bearer 3> <Max-Chan 1>]

[andretty]

Ошибка в man'е по accel-ppp.conf

     [pppd_compat]
             Configuration of pppd_compat module.

в pppd_compat.c же

       opt = conf_get_opt("pppd-compat", "radattr-prefix");               
       if (opt)
               conf_radattr_prefix = _strdup(opt);

получается, в конфиге надо писать через тире [pppd-compat] иначе не работает. Да и по дефолту в префиксе лишняя точка, файлики получаются вида radattr..ppp0

 

P.S. Это из релиза, accel-ppp-1.5.0

Изменено 20 февраля, 2012 пользователем andretty

[lan-viper]

И ведь не сохранил версию, на которой работали до 31 января. Надо выяснить, с какого коммита начинаются проблемы с утечками. Сегодня поставлю релиз 1.5.0, посмотрим.

...

Начиная с сегодняшнего дня сделал откат на релиз 1.5.0 с ручным внесением изменений из последующих некоторых коммитов (типа ошибки в синтаксисе и пр.). Буду наблюдать...

Думаю пора отписаться о результатах наблюдений за почти 5 суток

accel-ppp# show stat
uptime: 5.14:47:55
cpu: 0%
mem(rss/virt): 9736/95840 kB
core:
 mempool_allocated: 5359419
 mempool_available: 441515
 thread_count: 4
 thread_active: 1
 context_count: 254
 context_sleeping: 0
 context_pending: 0
 md_handler_count: 877
 md_handler_pending: 0
 timer_count: 825
 timer_pending: 0
ppp:
 starting: 0
 active: 208
 finishing: 0
pptp:
 starting: 0
 active: 85
l2tp:
 starting: 0
 active: 123
radius(1, 127.0.0.1):
 request count: 0
 queue length: 0
 auth sent: 13634
 auth lost(total/5m/1m): 0/0/0
 auth avg query time(5m/1m): 0/0 ms
 acct sent: 13016
 acct lost(total/5m/1m): 0/0/0
 acct avg query time(5m/1m): 0/1 ms
 interim sent: 1237392
 interim lost(total/5m/1m): 0/0/0
 interim avg query time(5m/1m): 0/0 ms

 

Субъективно проблемы с реализацией где-то в недрах нового шейпера (библиотеки). На старой реализации с tbf/police утечки отсутствуют.

[a_andry]

accel-ppp version ccfc36744c585a4ea4fb5d5c4e183e9bbd293852 сегфолтится примерно через пол дня работы.

 

pppoe8 ~ # uname -r

3.2.1-gentoo-r2

 

Ставил с дебагом (USE="debug" emerge -av1 accel-ppp), работают pppoe+pptp

 

[2012-02-22 14:42:58]:  info: ppp9: send [LCP ConfReq id=1 <auth MSCHAP-v2> <magic 6ef9a131> <mru 1492>]
[2012-02-22 14:42:58]:  info: recv [PPPoE PADI fc:75:16:42:7f:bf => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 19030000>]
[2012-02-22 14:42:58]:  info: send [PPPoE PADO 00:15:17:67:47:76 => fc:75:16:42:7f:bf sid=0000 <AC-Name pppoe8> <Service-Name > <AC-Cookie e99112396478df4ee27b82cef635df2227f2de5b6786a572> <Host-Uniq 19030000>]
[2012-02-22 14:42:58]:  info: ppp225: send [RADIUS(1) Accounting-Request id=21 <User-Name "home25213"> <NAS-Identifier "193.XXX.ZZZ.249"> <NAS-IP-Address 193.XXX.ZZZ.249> <NAS-Port 225> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:16:17:dd:21:d7"> <Called-Station-Id "00:15:17:67:47:76"> <Acct-Status-Type Alive> <Acct-Authentic RADIUS> <Acct-Session-Id "0040de0f53556704"> <Acct-Session-Time 9600> <Acct-Input-Octets 61638871> <Acct-Output-Octets 118108473> <Acct-Input-Packets 736834> <Acct-Output-Packets 838809> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 172.16.21.246>]
[2012-02-22 14:42:58]:  info: ppp225: recv [RADIUS(1) Accounting-Response id=21]
[2012-02-22 14:42:58]:  info: recv [PPPoE PADI 00:24:01:02:8a:d8 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 0100000001000000>]
[2012-02-22 14:42:58]:  info: send [PPPoE PADO 00:15:17:67:47:76 => 00:24:01:02:8a:d8 sid=0000 <AC-Name pppoe8> <Service-Name > <AC-Cookie e22d8e284f7147561d035987177dd14812a12f43ce1b5560> <Host-Uniq 0100000001000000>]

 

[Thread 0x7ffff0ad6700 (LWP 4210) exited]
[Thread 0x7ffff7ff6700 (LWP 4289) exited]
[New Thread 0x7ffff7ff6700 (LWP 4294)]
[Thread 0x7ffff7ff6700 (LWP 4294) exited]
[New Thread 0x7ffff7ff6700 (LWP 4295)]
[Thread 0x7ffff7ff6700 (LWP 4295) exited]
[New Thread 0x7ffff7ff6700 (LWP 4315)]
[New Thread 0x7ffff0ad6700 (LWP 4317)]
[Thread 0x7ffff7e46700 (LWP 4287) exited]
[New Thread 0x7ffff7e46700 (LWP 4318)]
[Thread 0x7ffff0ad6700 (LWP 4317) exited]
[New Thread 0x7ffff1b5c700 (LWP 4321)]
[Thread 0x7ffff7e25700 (LWP 4291) exited]
RTNETLINK answers: No such file or directory
[New Thread 0x7ffff7e25700 (LWP 4348)]
[Thread 0x7ffff7e25700 (LWP 4348) exited]
[New Thread 0x7ffff7e25700 (LWP 4351)]
[Thread 0x7ffff1b5c700 (LWP 4321) exited]
[Thread 0x7ffff7ff6700 (LWP 4315) exited]
[New Thread 0x7ffff7ff6700 (LWP 4352)]
[Thread 0x7ffff7ff6700 (LWP 4352) exited]
[New Thread 0x7ffff7ff6700 (LWP 4354)]

Program received signal SIGSEGV, Segmentation fault.
[switching to Thread 0x7ffff0a73700 (LWP 4199)]
0x00007ffff6691afb in sha1_block_data_order () from /usr/lib64/libcrypto.so.1.0.0
(gdb) bt
#0  0x00007ffff6691afb in sha1_block_data_order () from /usr/lib64/libcrypto.so.1.0.0
#1  0x0000000000000000 in ?? ()

[vinnipux]

accel-ppp version ccfc36744c585a4ea4fb5d5c4e183e9bbd293852 сегфолтится примерно через пол дня работы.

 

pppoe8 ~ # uname -r

3.2.1-gentoo-r2

 

Ставил с дебагом (USE="debug" emerge -av1 accel-ppp), работают pppoe+pptp

Fedora 16, accel-pppd 1.5.0

Использую pptp+l2tp+pppoe, нагрузка на этот сервер до 400 сессий.

К сожалению наблюдаю такую же картину, частота ~ до 4-х раз в сутки, периодика - практически рандомная, но обычно не менее нескольких часов между падениями.

 

[root@nas2 tmp]# uname -r

3.2.7-1.fc16.i686

 

Компилил accel с Debug.

 

Feb 22 12:03:51 nas2 kernel: [32597.437726] accel-pppd[5486]: segfault at 658003 ip 0032cc09 sp b40fb180 error 4 in libcrypto.so.1.0.0f[2e8000+173000]

Feb 22 15:15:44 nas2 kernel: [44110.300208] accel-pppd[31640]: segfault at 621005 ip 00253c09 sp b19fd180 error 4 in libcrypto.so.1.0.0f[20f000+173000]

обновил openssl - это не помогло

Feb 23 11:21:23 nas2 kernel: [ 1452.497321] accel-pppd[12610]: segfault at 486008 ip 00320c09 sp b04fe180 error 4 in libcrypto.so.1.0.0g[2dc000+173000]

Feb 23 13:22:12 nas2 kernel: [ 8701.190502] accel-pppd[9354]: segfault at be5008 ip 00a9ac09 sp b48fc180 error 4 in libcrypto.so.1.0.0g[a56000+173000]

 

Корки лежат здесь: http://dl.dropbox.com/u/54248745/coredumps2.tgz

Ссылки по теме:

http://sourceforge.net/tracker/?func=detail&aid=3480127&group_id=390718&atid=1622576

http://sourceforge.net/tracker/?func=detail&aid=3486590&group_id=390718&atid=1622576

http://forum.nag.ru/forum/index.php?showtopic=45266&view=findpost&p=685881

Изменено 23 февраля, 2012 пользователем vinnipux

[a_andry]

vinnipux, спасибо, радует что я не один, и есть шанс что Xeb обратит внимание ;)

 

Есть еще интересная особенность по libcrypto.so, у меня 5 "обновленных" сервера до 3.2.1-gentoo-r2, я ОС на них не ставил, вернее, ставил только на 1 тестовом, а потом через dd копировал его на рабочие сервера, изменения минимальные - ip адрес, имя сервера и т.п.. В итоге на 4-ех все работает отлично, без падений уже с пол месяца. А на одном постоянные падения на всех версиях accel-ppp.

 

Сервера почти одинаковые - Core Duo c E7400 и выше, тот что падает - самый слабый E7400. Железо - БП, память - меняли, не помогло. Раньше на этом сервере стояла freebsd+mpd - работало стабильно, т.е. с железками вроде как должно быть все в порядке.

 

Нагрузка - 50% idle, по 1200 тунелей, больше не пускаем, трафика 800-900Мбит/с. Но падает рандомно, вне зависимости от нагрузки.

[andretty]

libcrypto.so

С 1.0.0 он совсем плохо работает - я тоже пробовал (правда еще на релизе 1.3.5). Как решение проблемы я просто поставил dev-libs/openssl-0.9.8s-r1 в новый слот.

 

тут сам по себе демон память жрёт, вот где проблема.

 

по утечке памяти пока ничего нового?... Может помочь чем?

 

Еще одна проблемка есть: при закрытии сессии accel-ppp отправляет вместо ip вызывающего абонента какое то некорректное значение, поэтому в базе radius ip записывается как 0.0.0.0 (преобразование не срабатывает).Сегодня включил verbose, постараюсь точно отследить, что он отправляет.

 

UPD: А, нет, прошу прощения. Зря грешил на accel, судя по логам он все нормально отправляет...

Изменено 24 февраля, 2012 пользователем andretty

[xeb]

по утечке памяти пока ничего нового?

мысль есть

 

насчёт crypto, нужно попробовать увеличить размер стека...

[=-Sky-=]

Fedora 16, accel-pppd 1.5.0

Использую pptp+l2tp+pppoe, нагрузка на этот сервер до 400 сессий.

К сожалению наблюдаю такую же картину, частота ~ до 4-х раз в сутки, периодика - практически рандомная, но обычно не менее нескольких часов между падениями.

+1

У меня на Федоре то же самое, из-за этого я до сих пор на версии 0.8.5. Осенью пробовал ставить 1.3.5 (на тот момент она была последняя), но на сервере бывает до 1000 коннектов, поэтому core dump не ловил, чтобы не мучать абонентов.

Ещё, кстати после обновления до ядра 3.2 загрузка процессора сильно выросла, раза в полтора, не знаю из-за чего, и дрова на сетевуху переставил, и эксель пересобрал...

 

Tasks: 1738 total,  11 running, 1726 sleeping,   0 stopped,   1 zombie
Cpu0  :  0.9%us, 14.7%sy,  1.2%ni,  0.3%id,  0.0%wa,  1.5%hi, 81.4%si,  0.0%st
Cpu1  :  0.3%us, 12.0%sy,  4.5%ni,  1.2%id,  0.0%wa,  0.9%hi, 81.1%si,  0.0%st
Cpu2  :  0.3%us, 18.0%sy,  3.0%ni,  1.2%id,  0.0%wa,  0.6%hi, 76.8%si,  0.0%st
Cpu3  :  0.3%us, 14.8%sy,  0.6%ni,  1.2%id,  0.0%wa,  1.5%hi, 81.6%si,  0.0%st
Cpu4  :  1.2%us, 15.7%sy,  9.3%ni,  0.3%id,  0.0%wa,  0.6%hi, 72.9%si,  0.0%st
Cpu5  :  0.3%us, 22.0%sy,  0.6%ni,  0.9%id,  0.0%wa,  2.2%hi, 73.9%si,  0.0%st
Mem:   3917332k total,  3606824k used,   310508k free,   138344k buffers
Swap:  6160380k total,    30652k used,  6129728k free,  1438908k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  27 root      20   0     0    0    0 R 12.5  0.0 136:15.24 ksoftirqd/5
15409 root      30  10  373m  39m 7536 R 10.6  1.0   0:28.41 php
16794 root      30  10  374m  40m 7536 R 10.6  1.0   0:19.03 php
15881 root      30  10  373m  39m 7536 S  9.7  1.0   0:24.98 php
13353 root      20   0     0    0    0 R  8.7  0.0   0:11.46 kworker/5:1
20084 root      30  10  373m  39m 7536 R  8.1  1.0   0:03.71 php
   3 root      20   0     0    0    0 S  6.9  0.0 106:58.88 ksoftirqd/0
  19 root      20   0     0    0    0 S  5.9  0.0 143:41.47 ksoftirqd/3
6787 root      20   0     0    0    0 S  4.7  0.0   0:03.26 kworker/0:2
21125 root      35  15  349m  15m 7396 S  4.7  0.4   0:00.18 php
27510 root      20   0     0    0    0 S  3.4  0.0   5:18.41 kworker/3:2
2970 named     20   0  593m 175m 2492 S  2.8  4.6 136:13.21 named
  15 root      20   0     0    0    0 S  2.5  0.0  60:30.80 ksoftirqd/2
9148 root      20   0     0    0    0 R  2.5  0.0   0:02.12 kworker/2:1
27421 root      20   0     0    0    0 S  1.9  0.0   0:04.65 kworker/1:2
  10 root      20   0     0    0    0 S  1.6  0.0 124:25.31 ksoftirqd/1
21197 root      35  15  6428  652  556 R  1.6  0.0   0:00.05 nbtscan
18788 root      20   0 16548 2624  968 R  1.2  0.1   0:00.94 top
21093 root      20   0 53300 2772 2016 S  0.6  0.1   0:00.02 pppd
  23 root      20   0     0    0    0 S  0.3  0.0  61:34.60 ksoftirqd/4
2949 dhcpd     20   0 89268 9584 2564 S  0.3  0.2  12:58.65 dhcpd
2966 root      20   0  180m 3160 1680 S  0.3  0.1  13:19.31 nmbd
20956 root      35  15  350m  16m 7420 S  0.3  0.4   0:00.19 php
21185 root      35  15  174m 2588 1892 S  0.3  0.1   0:00.01 sudo
21208 root      20   0  244m 9188 6040 R  0.3  0.2   0:00.01 php
   1 root      20   0 40740 7832 1732 S  0.0  0.2   0:11.99 systemd

Изменено 26 февраля, 2012 пользователем =-Sky-=

[rainbo]

Добрый день.

имеется новенький Centos 6.2:

 

[root@vpn2 build]# uname -a
Linux vpn2 2.6.32-220.4.2.el6.x86_64 #1 SMP Tue Feb 14 04:00:16 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux
[root@vpn2 build]# 

 

Вытащенный с Git и свежескомпиленный accel-ppp version ccfc36744c585a4ea4fb5d5c4e183e9bbd293852

 

при запуске в логе выдает:

warn: shaper: requested 'htb' upstream limiter, but no 'ifb' specified, falling back to police...

 

Хотя в конфигах

[shaper]
attr=PPPD-Speed-Limit
#down-burst-factor=0.1
#up-burst-factor=1.0
#latency=50
#mpu=0
#r2q=10
#quantum=1500
#ifb=ifb0
up-limiter=htb
down-limiter=htb
verbose=1

 

 

соседняя тачка такая же один в один. тоже центос 6.2 и тд. Там такой строчки не выдается.

Я так понимаю, можно не бояться?

[taf_321]

 

при запуске в логе выдает:

warn: shaper: requested 'htb' upstream limiter, but no 'ifb' specified, falling back to police...

 

Хотя в конфигах

[shaper]
attr=PPPD-Speed-Limit
#down-burst-factor=0.1
#up-burst-factor=1.0
#latency=50
#mpu=0
#r2q=10
#quantum=1500
#ifb=ifb0
up-limiter=htb
down-limiter=htb
verbose=1

 

 

соседняя тачка такая же один в один. тоже центос 6.2 и тд. Там такой строчки не выдается.

Я так понимаю, можно не бояться?

 

Так если вы для UP используете htb, то надо определить ifb, а он у вас в конфиге закомментирован.

[xeb]

commit 0144238b8e364dac353797368fe45cda5426d88d
Author: Kozlov Dmitry <xeb@mail.ru>
Date:   Mon Feb 27 16:51:04 2012 +0400

shaper: move thread local variables to stack

commit 8a8680bfb817a25fdc04b6ce5e55605b1ac63d3d
Author: Kozlov Dmitry <xeb@mail.ru>
Date:   Mon Feb 27 16:50:21 2012 +0400

core: increase stack size

пробуйте

[desperado]

Доброе время суток всем!

 

Извините если вопросы уже обсуждались, но поиском не нашел, а листать 128 страниц уж очень долго. Кстати, поздравляю тему с юбилеем ;-)

 

Поставил на федору-15 (16 не стал из-за новой ветки ядра). Сразу вылезла старая версия libnl. Скачал libnl3, поставил не удаляя libnl-1 т.к. на него повязано много софта, собрал с опцией -DLIBNL_PREFIX.

 

Пришлось поправить ./build/accel-pppd/extra/CMakeFiles/shaper_tbf.dir/link.txt "-lnl" на "-lnl-3"

 

Где это можно сделать в сырцах чтобы не приходилось править после каждой переконфигурации?

Еще есть насущная задача при установке соединения дернуть скрипт, чтобы одним из параметров был callingstationid. Крайне нежелательно чтобы это был триггер на бд радиуса. Лучше что-то типа ip-up.

Вопрос снимается, вроде бы в ip-up передается нужный параметр ($6), раньше я его что-то проглядел.

 

Существует ли возможность обновлять шейпер без разрыва соединения? Например, пнуть его по snmp?

Изменено 27 февраля, 2012 пользователем desperado

[Dimka88]

root@pppd:~# telnet 127.0.0.1 2000
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
accel-ppp version 0144238b8e364dac353797368fe45cda5426d88d

 

accel-ppp# show sessions match username user 
ifname |   username    | calling-sid  |       ip        | rate-limit  | type | state  |  uptime  
--------+---------------+--------------+-----------------+-------------+------+--------+----------
ppp7   | user        | 192.168.1.50 | 172.16.41.38     | 11000/11000 | pptp | active | 00:07:03 

 

root@pppd:~# tc -s class show dev ppp7
class htb 1:1 root prio 0 rate 11000Kbit ceil 11000Kbit burst 137500b cburst 137500b 
Sent 25824956 bytes 26288 pkt (dropped 677, overlimits 0 requeues 0) 
rate 24bit 0pps backlog 0b 0p requeues 0 
lended: 19809 borrowed: 0 giants: 0
tokens: 1561969 ctokens: 1561969

 

root@pppd:~# tc -s class show dev ifb1
...
...
...
class htb 1:2f root prio 0 rate 11000Kbit ceil 11000Kbit burst 1375000b cburst 1375000b 
Sent 210466 bytes 546 pkt (dropped 0, overlimits 0 requeues 0) 
rate 40bit 0pps backlog 0b 0p requeues 0 
lended: 546 borrowed: 0 giants: 0
tokens: 15623735 ctokens: 15623735
...
...

 

[modules]
...
shaper


[shaper]
attr=PPPD-Upstream-Speed-Limit
down-burst-factor=0.1
up-burst-factor=1.0
latency=50
mpu=0
r2q=10
quantum=1500
ifb=ifb1
down-limiter=htb
up-limiter=htb
verbose=1

 

При параметре скорости 11000 Кбит/c, download такой как нужен,upload в среднем на 5 мегабит выше. Ставлю 40мегабит download 40 = upload 25 тут вообще непонятно.

Убираю шейпер download 85 = upload 85

[xeb]

Существует ли возможность обновлять шейпер без разрыва соединения? Например, пнуть его по snmp?

snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::cli.0 = "shaper change ppp0 1024"

[NiTr0]

Dimka88

tc -s class show dev ifb1 - при прокачке траффика сделайте. И cburst поставьте в дефолт (1534 байт что ли).

[Dimka88]

Только подключился, не изменяя cburst показывает так

class htb 1:4b root prio 0 rate 11000Kbit ceil 11000Kbit burst 1375000b cburst 1375000b 
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
rate 0bit 0pps backlog 0b 0p requeues 0 
lended: 0 borrowed: 0 giants: 0
tokens: 15625000 ctokens: 15625000

Ниже три показателя при при нагрузке канала

 

class htb 1:4b root prio 0 rate 11000Kbit ceil 11000Kbit burst 1375000b cburst 1375000b 
Sent 438589 bytes 5444 pkt (dropped 0, overlimits 0 requeues 0) 
rate 106352bit 162pps backlog 0b 0p requeues 0 
lended: 5444 borrowed: 0 giants: 0
tokens: 15622425 ctokens: 15622425

 

 

class htb 1:4b root prio 0 rate 11000Kbit ceil 11000Kbit burst 1375000b cburst 1375000b 
Sent 1454917 bytes 11584 pkt (dropped 0, overlimits 0 requeues 0) 
rate 574928bit 489pps backlog 0b 0p requeues 0 
lended: 11584 borrowed: 0 giants: 0
tokens: 14214186 ctokens: 14214186

 

class htb 1:4b root prio 0 rate 11000Kbit ceil 11000Kbit burst 1375000b cburst 1375000b 
Sent 26636400 bytes 44704 pkt (dropped 43, overlimits 0 requeues 0) 
rate 2150Kbit 650pps backlog 0b 9p requeues 0 
lended: 44695 borrowed: 0 giants: 0
tokens: -15701 ctokens: -15701

 

Все параметры заданы

 

 

[shaper]
attr=PPPD-Upstream-Speed-Limit
down-burst-factor=0.1
up-burst-factor=1.0
latency=50
mpu=0
r2q=10
quantum=1500
ifb=ifb1
down-limiter=htb
up-limiter=htb
verbose=1

 

Скорость по прежнему download = 10 upload 15,то есть я не задаю никаких параметров кроме attr=PPPD-Upstream-Speed-Limit в конфиге accel-pppd

 

Сделал

tc class change dev ifb1 parent 1:200 classid 1:4b htb rate 11000Kbit cburst 1534

И скорость на заданных 10 мегабитах показала download = 10 upload 10. Всё верно. Спасибо NiTr0

 

Ставлю скорость 25 мегабит. Делаю

tc class change dev ifb1 parent 1:200 classid 1:44 htb rate 25600Kbit burst 3250000b cburst 1534b

download = 25 upload = 20

Изминяю cburst на 152900b и скорость становится download 25 upload 25.

 

Еще раз спасибо NiTr0 за подсказку, вот как бы это теперь без костылей в accel вкрутить. Об этом еще не говорилось? Может можно передавать cburst как то правильно

 

Спасибо Xeb за огромные труды.

 

И еще вопрос.

 

[427166.773373] HTB: quantum of class 10044 is big. Consider r2q change.
[427266.542913] HTB: quantum of class 10001 is big. Consider r2q change.
[427266.542961] HTB: quantum of class 10053 is big. Consider r2q change.
[427563.073653] HTB: quantum of class 10001 is big. Consider r2q change.
[427563.073702] HTB: quantum of class 10005 is big. Consider r2q change.
[427660.675109] HTB: quantum of class 10001 is big. Consider r2q change.
[427660.675157] HTB: quantum of class 1002A is big. Consider r2q change.
[427802.213046] HTB: quantum of class 10001 is big. Consider r2q change.
[427802.213095] HTB: quantum of class 1004F is big. Consider r2q change.

 

это в dmessege пишется, кто то менял r2q и quantum для скоростей от 10 до 45 мегабит?

ps/ Уж очень сильно хотелось бы использовать интегрированый в accel-pppd шейпер

Изменено 28 февраля, 2012 пользователем Dimka88

[taf_321]

up-burst-factor=1.0

 

А не пробовали вот этому параметру присвоить те же значения, что и для down-burst-factor?

Изменено 28 февраля, 2012 пользователем taf_321

[xeb]

commit cf40442a413d04379711bd73a52372d3a3264ea4
Author: Kozlov Dmitry <xeb@mail.ru>
Date:   Tue Feb 28 13:25:37 2012 +0400

shaper: add cburst configuration option

[Dimka88]

taf_321 пробовал, для разных скоростей по разному считает.

xeb, огромное спасибо.

 

Пишу результаты

accel-ppp version cf40442a413d04379711bd73a52372d3a3264ea4

 

 

[shaper]
attr=PPPD-Upstream-Speed-Limit
down-burst-factor=0.1
up-burst-factor=1.0
latency=50
mpu=0
r2q=10
quantum=1500
ifb=ifb1
cburst=1534
down-limiter=htb
up-limiter=htb
verbose=1

 

Пострадал download. Ему cburst дефолтный подходил. Upload заработал как надо. Сейчас попробую down-burst-factor=1.0 или использовать down-limiter=tbf

 

upd/

down-burst-factor=1.0 не сработало, но установив cburst=153400 вроде всё хорошо только iperf что то смешные результаты начал показывать, spreedtest говорит всё нормально...

Изменено 28 февраля, 2012 пользователем Dimka88