[Nallien]

http://www.linuximq.net/ - плохо копали, товарищ.

[v-m-k]

eth = это на прова... Ну фактически исходящий мой в инет мона считать...

to Nallien: Плохо читаете товарищ, про IMQ я упомянул сразу же, выше...

Вот только он не совсем подходит по причинам производительности... Хотя хз, может я чо делал не так, уже и не помню... + помню что проблема была не тока у мя, но и у кучи народу. Решение нашлось в качестве установки отдельного сервака доступа с freebsd... Копал, нормально и долго...

[Nallien]

да я только увидел что IMQ вы не смогли настроить, потому решил подсказать где почитать :), собствено очень интересно что это за проблема с производительностью ? пока ничего толкового вы не сказали, а только - "ТАМ - хорошо, а ТУТ - плохо", ни ОС, ни конкретного софтажелеза, а сравнение ПРОИЗВОДИТЕЛЬНОСТИ линуха и фри - вообще смехотворно, поскольку вы не утруднили себя сообщить массам при каких именно операциях и каким образом эта самая производительность измерялась, не говоря уже о названии дистрибутивов линуха и релизах фри :)

 

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

 

к слову - я как не старался так и не понял что вы вообще, безусловно молодой человек, имели в виду рассказами о том что вы как-то уж архи странно накладываете ограничения на ppp, если 128 - то почему-то 256, а если 64 - то почемуто не 128 %))))) объяснитесь (выражайте мысли четче) или молчите вообще.

[Ascent77]

Nallien, пионер - это тот, кто обливает человека помоями, неразобравшись.

IMHO.

[Jugernault]

Я конечно извеняюсь, но если я правильно понял, то Благородный Дон хочет странного...

А iptables может ограничить скорость на синхронном порту.

У меня создается впечателение, что Благородный Дон не видит разницы между синхорнным и ассиметричным каналом.

Жы и так делал, но всё равно получается так:

Предположим у человека 128Kb/s канал, мы можем сделать ограничение на ppp в 128, но тогда на eth тоже будет 128, т.е. суммарная 256, а если человеку делить по 64 туда сюда, то им это не нравится, надо динамически и сразу, вот тогда на помощь pipes и приходит...

Ну тоесть получается, что Благородный Дон предлагает влупить клиенту под видом дуплексного симментрочного канала в 128К нечто отдаленно его напоминающее? То, что будет изображать из себя деские качели и показывать то 64 на 64, то 100 на 28, то 8 на 120 - но при этом суммарная полоса будет 128К?

Мне бы на месте Ваших пользователей то же бы неприятно было.

Какнал болтается как сопля из стороны в сторону - он ни симметричный ни несемметричный, а какой то странный получается.

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

 

Но это было лирическое отступление, а если по теме, то если лепить на интерфейсе направленном в сторону клиента HTB и ограничивать траффик идущий к киенту. И на том же интерфейсе применять ingress, то можно ограничивать траффик идущий и от клиента.

[jab]

Вот ведь до чего пингвинщики человека довели... :-)

[balamutang]

Ну тоесть получается, что Благородный Дон предлагает влупить клиенту под видом дуплексного симментрочного канала в 128К нечто отдаленно его напоминающее? То, что будет изображать из себя деские качели и показывать то 64 на 64, то 100 на 28, то 8 на 120 - но при этом суммарная полоса будет 128К?

хинт: канал надо делать 4вх/1исх , т.е. 128/32 или 256/64.

[Nallien]

ОФФТОП, ака личное:

 

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

 

спасибо за внимание.

 

ОФФТОП ака личное.

[v-m-k]

to Jugernault

На самом деле наоборот всё правильно, человеку даётся канал в 128Kb/s, как он его будет использовать? Отправлять другу DVD в кишинёв или качать из кишинёва этот DVD, это его дело... Т.е. канал может выглядить как 120/8 так и наоборот 8/120, надеюсь понятное. Но в отличие, хм от многих, такую полосу я хоть гарантировать могу, т.е. у мя реально чесные 128 (ну единственное если только мне что, то очень срочно надо скачать и я полосу прогружаю). На самом деле, на канале в 1Mb/s висит около 65 человек, и пока никто не жаловался (65 имеется введу людей может заходить), реально показатель больше 40 анлимщиков не поднимается, по использованию соответственно (если начнутся подсчёты что на 40 человек 1Mb/s не выходят чесные, то во первых это когда эти 40 прогружают одновременно канал все, за 2,5 года я такого не видел).

P.S. А про ingress поподробнее пожалуйста, хотя б сцылу, ну или сам почитаю...

 

to Nallien

Если возникают вопросы причём тут eth если разговоры о ppp советую почитать про iproute2 и его классовые структуры HTB и CBQ, и как их применять...

А к мнениям я прислушиваюсь, просто вижу что проблема была понята не совсем правильно, пытаюсь направить вопрос в нужное русло, вот и всё :)

 

P.P.S. Мне нужно динамическо выделяемая полоса, о5 таки HTB не позволяет это делать, а для клиента намного приятнее, что он сам может решать в какой пропорции он может использовать канал - ОН ЕГО, ОН ЗА НЕГО ЗАПЛАТИЛ!

 

Вот а синхронный порт (не совсем я правильную формулировку использовал, это када исхд=вхд, асинхронный когда они не равны, всё просто)

 

Жы, на самом деле (т.к. 2,5 года считаю не очень маленьким сроком), то опыта уже хватает, и на достигнутым не останавливаюсь, самое главное что клиентам всё нравится качество и стоимость, никто не гундосит что надо дешевле или качественее, на мозги никто не капает, правда и клиентов около 150, но из сетки в 200 человек, 150 активных интернетчиков, помойму это не мало...

 

Если по железу, то весьма всё скромно: Билинг - шлюз в нет = 700MHz - 128MB RAM, 40GB при это сумарный трафик постоянно проходящий около 10Mb/s (не много), но он его NATит. Ос Linux Slackware 10.2. Правил iptables около 100 + разные маршруты в инет на разные тарифы.

Сервер доступа (mpd работает как сервер VPN (pptp) без шифрования mppe) 800MHz - 128MB, 5GB обслуживает не напрягаясь около 80 юзверей, ОС Freebsd.

[Nallien]

кхм, тогда боюь вас опять никто не понял. о двух с половиной годах - промолчу.

 

то что вы тут описали - обычно называют асинхронный канал... вот только если у вас на ап 128 а даун - 20 (к примеру) то это уже 148 %) и наоборот соответственно. то что у пользователя должно быть 128 - в потолке и в случае если он отправляет и в случае если сливает - я правильно понял ? ну дык это же и есть асинхронный канал !?

 

и что за бредни насчет "почитать про iproute2" ??? ЕКЛМ, сил нету. чуствую в печь я этот топик пошлю :( вы хоть читали что было непонятно в ваших суждениях о интерфейсах ?

 

"""""""

Linux - 60 пользователей online проц под 40%

Freebsd - 80 пользователей online проц 2%

Неплохие показатели. Единственное, отошёл от темы, мы тут не про производительность...

"""""""

 

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

 

"""""""

Предположим у человека 128Kb/s канал, мы можем сделать ограничение на ppp в 128, но тогда на eth тоже будет 128, т.е. суммарная 256, а если человеку делить по 64 туда сюда, то им это не нравится, надо динамически и сразу, вот тогда на помощь pipes и приходит...

"""""""

 

вьехать в вышесказанное - очень не просто... и называется оно асинхронным каналом, кои можно строить и в линухе и во фре.

 

все. я завязываю флудить с товарищами у которых амфотерный линух работает в 20 (!) раз медленней амфотерной фри :)

[Jugernault]

to Jugernault

На самом деле наоборот всё правильно, человеку даётся канал в 128Kb/s, как он его будет использовать? Отправлять другу DVD в кишинёв или качать из кишинёва этот DVD, это его дело... Т.е. канал может выглядить как 120/8 так и наоборот 8/120, надеюсь понятное.

Оносительно правильности я бы очень очень усомнился...

Но сомнения мои были бы не технической стороной вопроса, а маркетинговой.

Насколько я понял из Ваших писем, Вы предлагаете продавать клиенту канал шириной 128К/с суммарно, т.е. сумма полосы входа + полосу изхода = 128К/с. При этом что бы реально пропускная способность канала могла перекоситься и в ту и в другую сторону полностью автоматически, но при этом сумма все равно оставалась бы 128К/с.

Т.е. назвать это можно ассиметричным дуплексным каналом с динамическим шейпингом по направлениям и суммарной пропускной способностью в 128К. - вот это бы было честно. А то что вы называете каналом в 128К у нас зовется симметричным каналом в 64К. При этом Вы кривите душой называя то, что продаете, каналом в 128К - пользователь из него никогда не получит 16кб/с при закачке по фтп.

 

Я не берусь обсуждать текущую ситуацию на Вашем рынке и конкурентоспособность этой услуги. Но для нашего региона такая услуга не пошла бы - не привык народ к таким махинациям. Пару лет назад у нас вовсю практиковались ассиметричные каналы, типа 128К на 32К и т.д. Сейчас это кануло в лету. А почему? - Да потому что если магистральщик продавал ассиметрично, то и вторичные и третичные провайдеры тоже следовали этому принципу.

Сейчас у нас магистральщики даже по траффику не очень то продают. Только симметричные полосы. Ну и остальные так же себя ведут - никакой ассиметрии.

Но в отличие, хм от многих, такую полосу я хоть гарантировать могу, т.е. у мя реально чесные 128 (ну единственное если только мне что, то очень срочно надо скачать и я полосу прогружаю).

Это конечно похвально...

Но что ни говори - Вы хотите странного... Продать 64К симметрии под видом 128К. Возможно именно по этому не смогли найти нормального решения под Линукс.

На самом деле, на канале в 1Mb/s висит около 65 человек, и пока никто не жаловался (65 имеется введу людей может заходить), реально показатель больше 40 анлимщиков не поднимается, по использованию соответственно (если начнутся подсчёты что на 40 человек 1Mb/s не выходят чесные, то во первых это когда эти 40 прогружают одновременно канал все, за 2,5 года я такого не видел).

Впредь я бы попросил Вас излагать свою мысль менее сумбурно - не торопитесь ответить, времени у нас много...

В сказаном Вами я увидил, что Вы самостоятельно дошли до истины, что мегабит + мегабит не равно два... :) А всего лиш полтора, а то и меньше... :) В этом я Вас разубеждать пожалуй не буду. Все зависит от конкретной ситуации. У меня есть ряд клиентов которые "выедают" свою полосу с коэффициентом среднемесячной загрузки на 85-90%.

Но ведь такие не все и по этому 1+1 не равно 2.

P.S. А про ingress поподробнее пожалуйста, хотя б сцылу, ну или сам почитаю...

Ну конечно же Linux Advanced Routing & Traffic Control HOWTO.

Ну и пример в решебнике про противодействие синфлуду.

В нем как раз видно как ограничить трафик на входящем интерфейсе со стороные клиента.

P.P.S. Мне нужно динамическо выделяемая полоса, о5 таки HTB не позволяет это делать, а для клиента намного приятнее, что он сам может решать в какой пропорции он может использовать канал - ОН ЕГО, ОН ЗА НЕГО ЗАПЛАТИЛ!

HTB позволяет подходить к распределению траффика динамически.

Но при помощи HTB Вы не сможете связать 2 разных класса (не одноподчиненных) что бы один работал на вход, а другой на изход.

Да клиент то заплатил, но вот только, что Вы ему предлагаете за это...

Вот а синхронный порт (не совсем я правильную формулировку использовал, это када исхд=вхд, асинхронный когда они не равны, всё просто)

вьехать в вышесказанное - очень не просто... и называется оно асинхронным каналом, кои можно строить и в линухе и во фре.  

Уважаемые господа v-m-k и Nallien ну перестаньте же наконец путать грешное с праведным. Или завязываейте применть поняти синхронный и асинхронный. Забудьте про них...

В данном вопросе важна дуплексность и симплексность, а так же симметричность и ассимметричность. Я уже дал примерное название тому что мы обсуждаем, см. выше...

[Jugernault]

Ну тоесть получается, что Благородный Дон предлагает влупить клиенту под видом дуплексного симментрочного канала в 128К нечто отдаленно его напоминающее? То, что будет изображать из себя деские качели и показывать то 64 на 64, то 100 на 28, то 8 на 120 - но при этом суммарная полоса будет 128К?

хинт: канал надо делать 4вх/1исх , т.е. 128/32 или 256/64.

А почему не 1 к 1-му? ;)

[v-m-k]

to Nallien

Если почитаешь выше, то увидишь что я говорил о pppd линуксовом и mpd во фре (сравнивал их), а насчёт как настроить динамический асинхронный канал так и не сказал... Слова просто не дают никакой информации. Думаю лучше действительно закончить, а то просто захломляем форум не нужными мессагами.

 

А сообщениями о производительности я пытался показать, что от выбранной задачи надо правильно выбирать ОС, тогда можно выжать из железа максимально...

[Jugernault]

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

Действительно...

Потому что хоть кол на голове теши, а у тебя канал как был асинхроннмм, так и остался в словосточетаниях... АССИМЕТРИЧНЫЙ ОН, А НЕ АСИНХРОННЫЙ!!! ;)

Т.е. понимания не прибавилось...

[v-m-k]

Жы, прошу прощения, только что увидел что описался, конечно ассиметричный хотел написать...

[sirmax]

Ну тоесть получается, что Благородный Дон предлагает влупить клиенту под видом дуплексного симментрочного канала в 128К нечто отдаленно его напоминающее? То, что будет изображать из себя деские качели и показывать то 64 на 64, то 100 на 28, то 8 на 120 - но при этом суммарная полоса будет 128К?

 

Вопрос к знатокам HTB - в какую сторону смотреть что б такое реализовать?

(интерес чисто теоретический, практического смысла я не вижу)

[Nallien]

?????? как это смысла не видите ?!

[sirmax]

Nallien,

переформулирую

"практического смысла для себя, т.к. у нас не предусмотрено соответствующих тарифных планов"

[v-m-k]

В HTB ты не сделаешь динамического шейпера, на эту тему смотри в сторону IMQ (как понял из описания, как раз что-то типа pipe)

 

Жы а HTB не только для зажимания можно использовать... Но и очередь красивую строить раскидывая траф по приоритетам, соответственно пуская интерактивный быстрее...

[Nallien]

sirmax, собственно - v-m-k верно говорит, в первую очередь HTB и CBQ - это реализация некоего QoS, и только потом - шейпер (хотя грань между тем и тем ооочень тонкая)

[fadey]

Специально под "как бороться с ослом" написал програмку (trafitizer.sourceforge.net). У кого есть интерес - помогите потестить. Програмка - для linux-роутера. Следит за трафиком юзверей и, в зависимости от потребляемого трафика, повышает или понижает приоритет. Начал писать после безуспешных (народ начал шифровать p2p) попыток зашейпить p2p при помощи ipp2p и l7 патчей к iptables, которые тут уже упомянались.

[BECHA]

а почему freebsd у вас ассоциируется именно с IPFW ? Во фрю давно портирован PF из OpenBSD.

[desperado]

народ начал шифровать p2p

Это как?

[fadey]

народ начал шифровать p2p

Это как?

Например,

в ktorrent (bittorrent): галочка напротив "use protocol encryption"

в amule (edonkey2000): Preferences->Security->Protocol Obfuscation->Use obfuscation for outgoing connections

 

Это для linux. В программах под винду эти опции тоже есть. Народ, как просек, что мы шейпим p2p, стал их (опции) активно юзать.

 

[Ascent77]

Сейчас для этого модно использовать Cisco SCE, полный контроль над трафиком, в том числе и над шифрованным + много других вкусностей.

P.S. Про цену не надо знаю :)