seagull Опубликовано 25 октября, 2010 Есть проблема - пользователи коннектятся к 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 Ладно даунлоад, еще более-менее близко, но аплоад что-то совсем хреновый. Как бы это настроить, чтобы показометр показывал скорость, ближе к тарифной? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 25 октября, 2010 Может burst увеличить? 128к явно маловато для полисинга 30мбит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 26 октября, 2010 Может burst увеличить? 128к явно маловато для полисинга 30мбит. Попробовал сделать 256к и на UL и на DL. Результаты: DL: 29629 UL: 14414 То есть upload увеличился, но совсем незначительно. Можно берст конечно еще увеличивать, но не приведет ли это к каким негативным последствиям? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
keshalg Опубликовано 26 октября, 2010 Может 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 от полисинга? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 26 октября, 2010 Больше пробуйте, 10m например :) Клиентам чем больше, тем лучше будет работать, единственное НО - лишь бы память не кончилась. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 26 октября, 2010 Есть проблема - пользователи коннектятся к PPTP серерам на линухе, обычный PoPToP. Ладно даунлоад, еще более-менее близко, но аплоад что-то совсем хреновый. Как бы это настроить, чтобы показометр показывал скорость, ближе к тарифной? на виндоус ХР?попробуйте на семёрке, ничего не меняя на брасе. ну и про пинги тут уважаемый disppointed писал уже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 26 октября, 2010 (изменено) Попробовал сделать 256к и на UL и на DL. Результаты:DL: 29629 UL: 14414 То есть upload увеличился, но совсем незначительно. Можно берст конечно еще увеличивать, но не приведет ли это к каким негативным последствиям? Согласно моим экспериментам, для полисинга скоростей около 30 Мбит/с надо ставить burst примерно 1200Kb. А вообще, асимметричный канал -- это полезно, т.к. трафик экономится. Большинство юзеров все равно интересует только download. Изменено 26 октября, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 26 октября, 2010 А вообще, асимметричный канал -- это полезно, т.к. трафик экономится.трафик какой экономится? мне вот пофиг на восходящий, он всё равно в конечном итоге (на аплинке), хотябы у нас, ниже чем низходящий Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
keshalg Опубликовано 27 октября, 2010 Согласно моим экспериментам, для полисинга скоростей около 30 Мбит/с надо ставить burst примерно 1200Kb....а можно узнать Ваши экспериментальные данные по всему диапазону широтыт.е. интересует градиент burst-а в зависимости от rate Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 8 ноября, 2010 (изменено) Поюзайте такой алгоритм расчеты 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 8 ноября, 2010 Такой алгоритм вряд ли применим для больших скоростей. При 50мбит размер буфера по формуле $speed*40 получится 50m/8*40=250мбайт, не сильно ли круто?) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 8 ноября, 2010 (изменено) Такой алгоритм вряд ли применим для больших скоростей. При 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...