форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Предложение подискутировать о шейперах"
Сообщение от Admin (??) on 27-Ноя-04, 19:57  (MSK)
FREEBSD 5.2.1 ( ALTQ VS DUMMYNУT ) VS LINUX MANDRAKE ( HTB VS CBQ ) Что по мнению общественности точнее ограничивает, быстрее работает, требует меньше ресурсов. Важнейшим пунктом будем считать точность работы, точнее найменьшую погрешность. А то один мой коллега выступил против шейперов FREEBSD, якобы они не точно ограничивают, а исходящий траффик вообще не точно нарезают, т.к. FREEBSD архитектура не позволяет это осуществить. Что вы думаете по этому поводу и что Линукс и в самом деле Рулит в этом смысле? p.s. пересмотрел весь этот форум и инет, но итогов так никто и не подвел.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Предложение подискутировать о шейперах"
Сообщение от kir (??) on 27-Ноя-04, 20:02  (MSK)
>FREEBSD 5.2.1 ( ALTQ VS DUMMYNУT ) VS LINUX MANDRAKE ( HTB >VS CBQ ) >Что по мнению общественности точнее ограничивает, быстрее работает, требует меньше ресурсов. Важнейшим >пунктом будем считать точность работы, точнее найменьшую погрешность. А то один >мой коллега выступил против шейперов FREEBSD, якобы они не точно ограничивают, ipfw dummy net - да было есть и будет но с приходом altq в котором тот же cbq итд... подумайте сами >а исходящий траффик вообще не точно нарезают, т.к. FREEBSD архитектура не >позволяет это осуществить. Что вы думаете по этому поводу и что >Линукс и в самом деле Рулит в этом смысле? линукс не рулит..... линукс пытаеться быть выскочкой .. >p.s. пересмотрел весь этот форум и инет, но итогов так никто и >не подвел.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Предложение подискутировать о шейперах"
Сообщение от deep_admin (ok) on 28-Ноя-04, 15:01  (MSK)
хотите точности - используйте htb + pfifo, но при большом кол-ве запросов будет congestion. sfq решит эти проблемы но  тогда  увеличится и погрешность. а вообще-то это извечная проблема, и она решиться не сможет, ведь шейпера ориентируются на средний размер пакета (avgpkt).
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "Предложение подискутировать о шейперах"
	Сообщение от Admin (??) on 28-Ноя-04, 16:34  (MSK)
	>хотите точности - используйте htb + pfifo, но при большом кол-ве запросов >будет congestion. sfq решит эти проблемы но  тогда  увеличится >и погрешность. >а вообще-то это извечная проблема, и она решиться не сможет, ведь шейпера >ориентируются на средний размер пакета (avgpkt). Насколько я знаю HTB умеет работать с исходящим траффиком, как же быть с входящим? И интересно, как вообще удаленный хост узнает с какой скоростью оттадавать данные хосту, которому скажем с dummynet, я ограничил данные 16 кб/сек.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "Предложение подискутировать о шейперах"
	Сообщение от dukie (ok) on 29-Ноя-04, 10:17  (MSK)
	Отдает несколько пакетов с максимальной скоростью - потом долго ждет подтверждения их получения с зашепленной стороны. Разве не так?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "Предложение подискутировать о шейперах"
	Сообщение от deep_admin (ok) on 29-Ноя-04, 12:00  (MSK)
	выдержка из lartc: tc qdisc add dev imq0 root handle 1: htb default 20 tc class add dev imq0 parent 1: classid 1:1 htb rate 2mbit burst 15k tc class add dev imq0 parent 1:1 classid 1:10 htb rate 1mbit tc class add dev imq0 parent 1:1 classid 1:20 htb rate 1mbit tc qdisc add dev imq0 parent 1:10 handle 10: pfifo tc qdisc add dev imq0 parent 1:20 handle 20: sfq tc filter add dev imq0 parent 10:0 protocol ip prio 1 u32 match \ ip dst 10.0.0.230/32 flowid 1:10 iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0 ip link set imq0 up то есть все прекрасно шейпится через виртуальный интерфейс imq. Таким образом достигается симуляция ассинхронной линии. Правда кол-во таких интерфейсов ограничено
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "Предложение подискутировать о шейперах"
	Сообщение от Admin (??) on 29-Ноя-04, 19:38  (MSK)
	Так а у кого с какой погрешностью ограничивают шейперы.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "Предложение подискутировать о шейперах"
	Сообщение от Admin (??) on 01-Дек-04, 11:44  (MSK)
	Неужто никто траффик юзерам не шейпит???
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "Предложение подискутировать о шейперах"
	Сообщение от kir (??) on 01-Дек-04, 12:03  (MSK)
	>Неужто никто траффик юзерам не шейпит??? а ты попробуй его пошейпь на каждого юзера когда их >> 300 .... обычно шейпят по сервисам.... система ? FreeBSD ? < 5.2 = ipfw dummy net                       > 5.2 = altq
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "Предложение подискутировать о шейперах"
	Сообщение от alk (??) on 01-Дек-04, 12:36  (MSK)
	>>Неужто никто траффик юзерам не шейпит??? > > > а ты попробуй его пошейпь на каждого юзера когда их >> 300 .... > обычно шейпят по сервисам.... > > система ? FreeBSD ? < 5.2 = ipfw dummy net >                      > 5.2 = altq > > По поводу altq на 5.2 можно примеры ваши увидеть plz
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "Предложение подискутировать о шейперах"
	Сообщение от Z0termaNN (ok) on 01-Дек-04, 13:04  (MSK)
	входящий трафик шэйпить не имеет смысла (если понимать под шейпингом, попытки сглаживания трафика), т.к. буфера приема пакетов отсутствуют, а кроме того на момент принятия решения пакет все равно уже принят ядром, но его можно его резать. В линуксе есть по крайней мере 3 способа этого добиться: 1. iptables -m limit, 2. политикой фильтров - ip filter ... police ... decision 3. на промежуточном псевдоустройстве - imq. что касатеся точности, то она вполне приемлема, если конечно скорости не сильно низкие - проверка происходит 1 cек/HZ. В принципе есть возможность HZ крутить, но это отдельный патч в ядре.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "Предложение подискутировать о шейперах"
	Сообщение от Admin (??) on 01-Дек-04, 15:33  (MSK)
	Ну а каким макаром тогда шейпят входящий траффик все серьезные провайдеры, которые поставляют домашним сетям и корпоративным клиентам интернет? И кстати как HZ для dummynet считается оптимальным?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	12. "Предложение подискутировать о шейперах"
	Сообщение от Z0termaNN (ok) on 01-Дек-04, 18:51  (MSK)
	>Ну а каким макаром тогда шейпят входящий траффик все серьезные провайдеры, которые >поставляют домашним сетям и корпоративным клиентам интернет? И кстати как HZ >для dummynet считается оптимальным? у провайдеров дела обстоят намного лучше: 1. скорость tcp трафика обычно достаточно хорошо управляется путем отбрасывания пакетов, собственно  наиболее дешевые способ управления tcp трафиком на этом и основаны - всякие разновидности red, 2. они же паразиты умудряются брать деньги за трафик, поэтому их мало волнует загрузка клиентского канала, в любом случае за это платят клиенты, 3. структура сети у провайдеров обычно такова, что есть возможность как раз таки шейпить трафик на исходящих портах маршрутизаторов, т.к. у любого более менее крупного провайдера набор сетевого оборудования никак не ограничивается одним девайсом. что касается HZ в bsd, то здесь ничего не могу сказать членораздельного, т.к. с bsd знаком шапочно, но если идеология управления трафиком примерно соответсвует тому, что есть в линуксе, то естественно, чем HZ больше, тем лучше (хотя это сильно зависит от алгоритмов планирования, скорости трафика и пр.), так на HZ=1000 и среднем размере пакета на интерфейсе 512К вполне возможно получить гарантированную задержку 4 ms, соответственно при HZ=100, гарантировать можно только 40ms. Это критично даже не столько для интерактивного трафика, сколько для трафика с гарантированным временем отклика(например VoIP), но в других условиях (если основной трафик http) такая точность вообще просто не нужна, вполне сойдет и простенькая приоритизация.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.