Jump to content
Калькуляторы

Аплоад медленнее даунлоада

Есть проблема - пользователи коннектятся к 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

 

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

 

Share this post


Link to post
Share on other sites

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

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

DL: 29629

UL: 14414

 

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

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

Share this post


Link to post
Share on other sites

Может 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 от полисинга?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

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

Share this post


Link to post
Share on other sites

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

DL: 29629

UL: 14414

 

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Поюзайте такой алгоритм расчеты 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 передается из биллинга в кбит/с

Edited by replicant

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Такой алгоритм вряд ли применим для больших скоростей. При 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

Edited by replicant

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.