Nallien

и одного и всех. иначе с точки зрения шейпера задача превращается в совершенно другую. нельзя ставить rate дочерних классов таковым, чтобы их сумма превышала rate а тем более ceil родительского. об этом четко и не двусмысленно сказано в мане, и даже описано что будет если сделать так. так вот у telephonist'а именно это и происходит. как уже писалось выше - если rate родительского класса 1 мибт, то если у вас даже теоретически может одновременно работать 100 человек - то вам необходимо выставить rate каждому 1 кбит. а ceil ставьте какой хотите. и будет у вас все хорошо.

вторая машина это сейчас и есть рабочий вариант, как раз сегодня приехала сетевая. но из академического интереса и более рационального использования ресурсов - хотелось бы реализовать исходный вариант. но, выходит, стандартными средствами и существующими патчами такую задачу в рамках одной машины решить невозможно хоть на сколь-нить приемлемом уровне. я так понимаю создав виртуальный интерфейс и прогнав трафик через него (и собственно на нем применив глобальный шейпер по направлениям) - задачу можно решить. вот только, боюсь, нагрузочка будет приличная... возможно есть еще варианты?

хм... пока еще полностью в ман не вник, но разве с ДРР не та же проблема? ведь не описав отдельно скорость по двум направлениям - шейпер же не будет правильно работать? он же не будет знать где потолок...

ага, понял, увы - задача как раз более похожа на вашу старую, те кому нужны гарантированные каналы (их почти по пальцам можно пересчитать) вообще другим сервером обслуживаются. а вот тут совсем другой колинкор. необходимо чтобы честно делилось между, скажем, 500 пользователями 500 мбит. и при чем динамически, с контролем качества, минимизированными задержками и т.д. .... вот незадача... по прежнему ожидаю интересных мыслей. должно оно как-то просто решаться... а то пока только по дурацки выходит - вешать 2 мбита зарубежки + 8 националки, чтобы типа 10 получить, но и при таком раскладе - невозможно получить правильную балансировку, так как невозможно описать общий класс националки, а если быть точнее - невозможно дочерние классы пользователя заставить при этом быть дочерними классами глобального класса националки :( ведь по идее все, у кого есть хоть какой-то национальный трафик, который отдельно не нарезается пользователю должны сталкиваться с такой проблемой...

что подход неправильный сейчас - это конечно,потому тут и ищу ответ. пока он устраивал - он был правильным. вы создаете один класс 10 мбит на юзверя, в него три дочерних по направлениям, а фильтры на эти дочерние класы по каким признакам вешаете? предположим что по реалмам (я так понимаю что-то типа tc filter add dev eth parent $uid:0 route to <realm>), но при этом все равно как решается вопрос распределения общей полосы между абонентами? предположим есть тариф с менее гарантированным приоритетом и с более гарантированным, как заставить шейпер отбирать часть канала у тарифов с более мелким приоритетом к более высокому? ведь не описав четко параметры каналов (а загвоздка в том что их два, но в одном интерфейсе, одним куском) - шейпер не будет работать, просто не зная своего потолка. если же этот потолок указан у вас отдельными классами (на украину там, локалку и прочее), то как в таком случае ведет себя шейпер? ведь фактически, дочерние классы на клиентском классе остаются, а их фильтры направляют трафик в отдельный класс (например та же украина), разве, в таком случае, не будет отдельно стоящий, общий класс украины навязывать свои значения скорости? или все же будет работать как фактически класс имеющий два родительских класса, но тогда чьи значения родителей ceil и rate например будет принимать этот конкретно взятый дочерний класс? если не сложно - сбросьте простой пример, я какой-то ключевой фишки просто не вижу :(

500 - это суммарная полоса, тоесть 200 + 300, 800 - ну пусть 1000 - чтоб легче - это скорость локального шейпера\интерфеса. есть национальны и зарубежный трафик в одном канале от вышестоящего оператора, мне нужно дать клиентам 10 мбит, например, по обоим направлениям. тбишь в случае если пользователь качает с зарубежки - это будет до 10 мбит зарубежки, если с нац ресурсов - это будет до 10 мбит национального канала, если будет качать с обоих направлений - то скорость между ними должна делиться, и не превышать 10 мбит. и все было бы просто, если бы не было этих двух разных каналов в одном. тоесть мне нужно каким-то образом определять что есть национальный трафик, а что нет, и на основе этого выдавать 10 мбит клиенту. зачем? клиентов физиков много, скорость на этом тарифе не гарантирована никак, задача разделить имеющиеся 200+300 мбит максимально поровну, ну и конечно же динамически. до этого были тарифы с фиксированной зарубежкой (4 и 8 мбита) и на них было до 100 мбит национального трафика. решалось просто - создавалось два класса - один на зарубежку со скоростью 200 мбит, второй на националку - 300 мбит. вот для более легкого представления: по умолчанию все пользователи были чайлдами того шейпа что на зарубежку, отдельно iptables проверялось вхождение в префиксы национальных сетей, и на них вешалась метка, которая автоматически обрабатывалась 300 мбитным шейпом националки. сейчас же нужно дать до 10 мбит и зарубежки и националки одновременно... в случае если неправильно описать рутовый класс - будет бардак. но вот тут и проблема о которой и писалось выше.

а задача немного другая - что бы конкретный абонент с rate 10 имел пусть и два подкласа, но что бы унего в обоих этих подкласах был ceil 10, хотя возможно я еще не совсем врубился что вы имеете в виду... но в любом же случае сверху нужно ограничивать, ибо если этого не делать - то скорость не будет правильно делиться между абонентами и будет забивать внешний канал. может я чего не понимаю - распишу как вижу. если все абоненты будут иметь в парентах 1:0, как описать этот 1:0? логичным представляется как указываем локальной скорости - тобишь 800 мбит. но в таком случае если все кинуться качать с зарубежки, оч быстро забьют 200 мбит, так как шейпер буде считать что таем всего 800 мбит, тобишь еще 600 свободно. если 1:0 описать как 500 мбит (суммарная скорость) - будет точно так же. если описать как 200 мбит - не будет использоваться реальная пропускная способность канала. а без правильного описания 1:0 - шейпер вообще не сможет нормально работать.... поправьте если не прав.

вкратце обрисую проблему. предположим имеем 200 мбит зарубежки, и 300 мбит национального канала. суммарно 500 мбит шейпинг осуществляется на линукс-коробке, с помощью tc и маркировки пакетов. к примеру существует глобальный класс на весь интерфейс - описывающий его локальною скорость в 800 мбит 1:0 у этого класса 1:0 есть два (упрощенно) дочерних класса - 1:200 и 1:300, первый - для зарубежного трафика, второй для национального. в данный момент классы пользователей по умолчанию создаются как дочерние класса 1:200, затем проверяется попадание трафика в национальные префиксы сетей, если какой-то из адресов совпадает - на пакеты ставится метка, и они обрабатываются классом 1:300, если же не попадают - обрабатываются родительским 1:200 на примере - у пользователя скорость 2 мбита зарубежки и 10 мбит национального трафика. при коннекте ему создается свой собственный class, qdisc и filter, описывающий скорость в 2 мбита, и дополнительно проверяется - не является ли трафик национальным, если является - пакетам ставится метка, которую обрабатывает класс 1:300. задача довольно банальна, но что-то я не могу найти приемлемого решения :( необходимо дать пользователю суммарно 10 мбит трафика, а уже на стороне сервера определять - национальный трафик это или нет. проблема усложняется тем что наливают нам эти 500 мбит одним каналом, и нам самим приходится разгребать что есть национальный трафик, а что зарубежка. если свалить все в один класс 1:500 с ограничением в 500 мбит - не феншуй, может забиваться как зарубежка так и националка, приводя к потерям, задержкам и жалобам. в идеале как мне видится, так это клиентские классы создавать с двумя родителями - 1:200 и 1:300, но насколько мне известно такого функионала нет. а еще у меня чувство что я все очень усложняю и есть боле простой способ решения задачи. буду признателен за любую подсказку в верном направлении.

как вам уже говорили - у вас абсолютно всюду rate=ceil шейпер работает именно так, как вы ему сказали.

создайте отдельный класс с высоким приоритетом и скоростью на все локальные нужды (ARP, DHCP, DNS, ICMP, TCP, SSH... и т.д.). дефолт должен играть роль буфера для классифицированного трафика, то есть того о котором вам ничего не известно и/или на качество которого наплевать.

wtyd как я вижу - у вас все работает именно так как написано. уберите описание ceil - и будет то что вы хотите. так как в вашем случае burst рассчитывается от ceil - свободной полосы родителя.

кто-то еще тестирует? интересны результаты. сами недавно переехали на 2.6.35 - честно говоря улучшений не видно... даже наоборот. но подозреваю исключительно от того что основные ресурсы жрут на машине не сетевые процессы, а юзер и кернел левел приложения.

к слову присоединюсь к вопросу и апну тему. я как-то уверился что не поддерживают, в даташите что-то не припомню. но все же - кто пользует такие? может все таки есть? мне вообще кажется что по идее от самой сетевой не так уж и зависит. или я не прав?

есть еще пару ретрекеров (софт тобишь)... можно и самому спилять с трекера обычного. а что за побочные эффекты? ничего хоть сколь значимого на ум не приходит

немного сдвинулось, просьба дальше поучаствовать в голосовании http://torrents.ru/forum/viewtopic.php?t=2078919

на переговоры идут многие - и пиратбей и региональные, но все заканчивается прописыванием у них диапазонов наших адресов, и они сами вставляют в торрент-файл за писть о втором трекере по поводу - как муторрент определяет кто есть локлаьный пир - хороший вопрос. судя по всему по айпишке (ну не совсем так конечно, это грубо говоря))) . так как для общения с внешними пирами используется внешний айп, то скорее всего на него и навешиваются скоростные ограничения, а на локальные ( в случае если таковые имеются) - нет, ибо обычно они из совсем другого диапазона\сети. вот он и качает с локальных 100\1000 мбит. а с интернета - по тарифной скорости. что, вобщем-то, нам как раз на руку.

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

ничего не понял что вы хотели этим сказать. муторрент с локальных пиров качает на всю катушку в независимости от ограничения в нем самом (как мне показалось :))) а все остальные манипулйии с очередями и приоритетами -он и так хорошо решает. в противном случае - пакетный фильтр вам в руки. просто пакетами там не обойтись. да и так - это гемор и лишняя нагрузка на железо. оно вам надо? "глобальный" фейковый адрес ретрекера вообще закрывает 99% вопросов с ретрекером в целом.

у кого как :) от населения сети и % юриков зависит, имо.

очень вяло в этом направлении движется :( давайте товарищи пролетариаты! объединимся :) напишите по ссылке выше свое "за или против" - привлечем внимание админов торрентс.ру. реально очень полезная штука. я не нарадуюсь смотря на 2-3 тысячи пиров на локальном ретрекере. это все сэкономленный внешний канал на самом тяжелом типе трафика, абсолютно прозрачный способ для пользователя, к тому же повышающий в большинстве случаев скорость скачки клиенту. все мы от этого только выиграем! еще раз прошу общественность просить популярные трекеры работать с сабжем.

приветствую всех, идея созревала давно, дядя Наг ее даже описывал в одном из номеров. посмотрев, что больших движений в эту сторону нет - создал тему на торенте. http://torrents.ru/forum/viewtopic.php?t=1730797 там же и описание о чем разговор, думаю, большинство и так "в курсе дела" ;) просьба отписаться там и поддержать идею - в результате выиграют фактически все.

исходя из задачи находить затухания и обрывы - берите все что подешевле умеет такое делать. особой рзницы не будет.

вам есть смысл посмотреть в сторону SNMP трапов. правильнее оно и излизано вдоль и в поперек.

эммм... тогда вопрос такой - мемтест на дэфолтных настройках? какого рода ошибки были обнаружены? для меня загадка как одна программа при выполнении тех же операций видит ошибку а другая нет. попахивает влиянием сторонних фактором или недостаточного тестирования (время, сложность) А что это за несовместимость модулей памяти ? и в чем она выражается в работа - какого рода ошибки ? условность того что ваша тестовая утилита работает под ОС виндовс - огромное ограничение. давайте как условия тестов и что за ошибки. мне кажется вы чегой-то путаете. проверка памяти (именно памяти) процесс простой и рутинный.

в какти есть плагинчик CAMM ( ранее snmptt ) вот он прекрасно и сислог и трапы показывает. из бесплатных решений - действительно какти с обвесом + нагиос с обвесом - и никаких проблем )