[seagull]

Есть проблема - пользователи коннектятся к PPTP серерам на линухе, обычный PoPToP.

Им шейпится аплоад и даунлоад следующими командами:

 

# DL

/sbin/tc qdisc add dev $DEV root tbf rate ${DOWN}Kbit latency 50ms burst 128Kb

#

# UL

/sbin/tc qdisc add dev $DEV handle ffff: ingress

/sbin/tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate ${UP}Kbit burst 128Kb drop flowid :1

 

При этом, при ограничении скорости например 30Мбит, при измерении на internet.yandex.ru вижу:

DL: 28070

UL: 12269

 

Ладно даунлоад, еще более-менее близко, но аплоад что-то совсем хреновый. Как бы это настроить, чтобы показометр показывал скорость, ближе к тарифной?

 

[kayot]

Может burst увеличить? 128к явно маловато для полисинга 30мбит.

[seagull]

Может burst увеличить? 128к явно маловато для полисинга 30мбит.

Попробовал сделать 256к и на UL и на DL. Результаты:

DL: 29629

UL: 14414

 

То есть upload увеличился, но совсем незначительно.

Можно берст конечно еще увеличивать, но не приведет ли это к каким негативным последствиям?

[keshalg]

Может burst увеличить? 128к явно маловато для полисинга 30мбит.

А какую посоветуете? На странице НТВ вообще пишет уще в 2001м году:

In TC you don't have to specify "burst" and "cburst" anymore. The tc tool will compute it for you (you can still override it).

И для шейпинга отличаются порядки burst от полисинга?

[kayot]

Больше пробуйте, 10m например :) Клиентам чем больше, тем лучше будет работать, единственное НО - лишь бы память не кончилась.

[Giga-Byte]

Есть проблема - пользователи коннектятся к PPTP серерам на линухе, обычный PoPToP.

 

Ладно даунлоад, еще более-менее близко, но аплоад что-то совсем хреновый. Как бы это настроить, чтобы показометр показывал скорость, ближе к тарифной?

на виндоус ХР?

попробуйте на семёрке, ничего не меняя на брасе.

ну и про пинги тут уважаемый disppointed писал уже.

[photon]

Попробовал сделать 256к и на UL и на DL. Результаты:

DL: 29629

UL: 14414

 

То есть upload увеличился, но совсем незначительно.

Можно берст конечно еще увеличивать, но не приведет ли это к каким негативным последствиям?

Согласно моим экспериментам, для полисинга скоростей около 30 Мбит/с надо ставить burst примерно 1200Kb. А вообще, асимметричный канал -- это полезно, т.к. трафик экономится. Большинство юзеров все равно интересует только download.

Изменено 26 октября, 2010 пользователем photon

[Giga-Byte]

А вообще, асимметричный канал -- это полезно, т.к. трафик экономится.

трафик какой экономится?

мне вот пофиг на восходящий, он всё равно в конечном итоге (на аплинке), хотябы у нас, ниже чем низходящий

[keshalg]

Согласно моим экспериментам, для полисинга скоростей около 30 Мбит/с надо ставить burst примерно 1200Kb....

а можно узнать Ваши экспериментальные данные по всему диапазону широты

т.е. интересует градиент burst-а в зависимости от rate

[replicant]

Поюзайте такой алгоритм расчеты burst от rate

 

/usr/sbin/tc qdisc del dev $interface root
/usr/sbin/tc qdisc add dev $interface root tbf rate ${speed}kbit burst $[1500+$speed*10] latency 50

/usr/sbin/tc qdisc del dev $interface ingress handle ffff:
/usr/sbin/tc qdisc add dev $interface ingress handle ffff:
/usr/sbin/tc filter add dev $interface parent ffff: protocol ip prio 10 u32 match ip src 0.0.0.0/0 police rate ${speed}kbit buffer $[7000+$speed*40] drop flowid :1

 

Значение speed передается из биллинга в кбит/с

Изменено 8 ноября, 2010 пользователем replicant

[kayot]

Такой алгоритм вряд ли применим для больших скоростей. При 50мбит размер буфера по формуле $speed*40 получится 50m/8*40=250мбайт, не сильно ли круто?)

[replicant]

Такой алгоритм вряд ли применим для больших скоростей. При 50мбит размер буфера по формуле $speed*40 получится 50m/8*40=250мбайт, не сильно ли круто?)

Ошиблись в расчетах на 3 порядка. :)

 

Он работает именно на больших скоростях даже лучше.

 

Вот данные с рабочего сервера в данный момент:

 

Mem: 2074464k total, 472060k used, 1602404k free, 86388k buffers

pstree: -pptpd---194*[pptpctrl---pppd]

uptime: up 312 days, 6:23, 1 user, load average: 0.03, 0.04, 0.00

Изменено 19 ноября, 2010 пользователем replicant