уже неактуально

[jonny rotten]

уже неактуально

..

 

[Гість 7548]

⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.

 

[alex444]

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

 

[jonny rotten]

спасибо за помошь. но я ниче непонял
ребята, а попроще как то можно?

 

[dr_mousefly]

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

 

[Гість 7548]

особенно для входящего трафика поможет...
не queue а pipe

я не виноват, если вам не помогает. всем помогает, а вам нет.
пайп это во фреебсд. вам следует так сказать расширить кругозор
https://ru.wikipedia.org/wiki/Файл:Unix_history-simple.en.svg

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

ну Саша ты даешь. а как же TCP окно?
при потере пакета tcp благополучно снижает скорость, там есть все механизмы.
с udp фокус не пройдет, но для простейшего варианта достаточно прирезать весь трафик по маске \x7F\xFF\xFF\xFF\xAB. после этого pcq отлично делит канал всем поровну, если указать ему скорость аплинка.

 

[0xygen]

я не виноват, если вам не помогает. всем помогает, а вам нет.

ВХОДЯЩИЙ трафик, приходящий на ppp0 (в этом случае) ты НИКОГДА не порежешь. потому что пакет УЖЕ ПРИШЕЛ на интерфейс, забив при этом канал.

 

[alex444]

ВХОДЯЩИЙ трафик, приходящий на ppp0 (в этом случае) ты НИКОГДА не порежешь. потому что пакет УЖЕ ПРИШЕЛ на интерфейс, забив при этом канал.

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

ps механизм регуляции описан в RFC 792

A gateway MAY discard internet datagrams if it does not have the buffer space needed to queue the datagrams for output to the next network on the route to the destination network.
If a gateway discards a datagram, it may send a source quench message to the internet source host of the datagram. A destination host may also send a source quench message if datagrams arrive too fast to be processed. The source quench message is a request to the host to cut back the rate at which it is sending traffic to the internet destination. The gateway may send a source quench message for every message that it discards. On receipt of a source quench message, the source host should cut back the rate at which it is sending traffic to the specified destination until it no longer receives source quench messages from the gateway. The source host can then gradually increase the rate at which it sends traffic to the destination until it again receives source quench messages.

The gateway or host MAY send the source quench message when it approaches its capacity limit rather than waiting until the capacity is exceeded. This means that the data datagram which triggered the source quench message may be delivered.

При таком дискарде источнику от имени этого gateway отправляется icmp message type 4 (The ICMP Source quench message is a request to decrease the traffic rate of data messages sent to an internet destination) - и (если источник настраивался не дебилоадмином, режущим icmp всех типов) - источник снижает скорость. Других протокольных механизмов, позволяющих избежать оверлоада канала от аплинка к данному гейтвею (транзитному роутеру в общем случае) - не существует.


зы а вот этим

A destination host may also send a source quench message if datagrams arrive too fast to be processed.

механизмом пользуются всякие приложения, в которых есть настройка "ограничить скорость закачки" - например, даунлоадеры, торрентокачалки и т.п.
Что я и рекомендую сделать ТС-у

ззы как все понимают, "может!=обязан"

 

[0xygen]

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

ну можно, конечно попросить того сервера отдавать со скоростью не более такой то. но это далеко не применимо к ситуации ТСа

 

[Orshansky]

При таком дискарде источнику от имени этого gateway отправляется icmp message type 4 (The ICMP Source quench message is a request to decrease the traffic rate of data messages sent to an internet destination) - и (если источник настраивался не дебилоадмином, режущим icmp всех типов) - источник снижает скорость. Других протокольных механизмов, позволяющих избежать оверлоада канала от аплинка к данному гейтвею - не существует.

RSVP (Resource ReserVation Protocol)
RFC2205.

alex444, прочтите хотя бы один раз, хотя бы Олифера.

 

[alex444]

RSVP (Resource ReserVation Protocol)
RFC2205.

alex444, прочтите хотя бы один раз, хотя бы Олифера.

и что? Опять "абы ляпнуть" ?
мы говорим о сохо девайсах ТС-а, в мессаге #1 они указаны. Укажите модель девайса и его стоимость для ТС-а , плз, работающего с маркерами приоритетов (и, самое главное - кто/что эти маркеры на траффик повесит).

 

[Orshansky]

и что? Опять "абы ляпнуть" ?
мы говорим о сохо девайсах ТС-а, в мессаге #1 они указаны. Укажите модель девайса и его стоимость для ТС-а , плз.

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

А то, что не существует и не реализован в данной модели - это принципиально разные вещи.

Модем dlink dsl-2540u работает под управлением Linux и если задаться такой целью, то добавить этот функционал наверняка можно:

⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.

Со стороны оператора я согласен - там беда. Но ведь - это же не означает, что таких методов не существует!

 

[Гість 7548]

мужики вы бредите. если роутер режет tcp клиенту на 64к, то на входе у него будет забита вся полоса от аплинка? все 100 мегабит? не мелите ерундой.
с mTP несколько иная ситуация, там прет бесконтрольный UDP. и поскольку он прет без подтверждения действительно забивает входной канал.
вообще ТС спрашивал за "поделить всем поровну". именно такой алгоритм реализует очередь типа pcq. для этого ей всего лишь нужно знать суммарную полосу ВХОДНОГО канала.

 

[Orshansky]

мужики вы бредите. если роутер режет tcp клиенту на 64к, то на входе у него будет забита вся полоса от аплинка? все 100 мегабит? не мелите ерундой.
с mTP несколько иная ситуация, там прет бесконтрольный UDP. и поскольку он прет без подтверждения действительно забивает входной канал.
вообще ТС спрашивал за "поделить всем поровну". именно такой алгоритм реализует очередь типа pcq. для этого ей всего лишь нужно знать суммарную полосу ВХОДНОГО канала.

На самом деле вариантов масса, но на оборудовании другого класса, нежели у ТС.

 

[alex444]

мужики вы бредите. если роутер режет tcp клиенту на 64к, то на входе у него будет забита вся полоса от аплинка? все 100 мегабит?

если РОУТЕР режет НА входе от аплинка транзитные пакеты, адресованные клиенту - то да, весь входной канал от аплинка будет забит этим траффиком, который роутер дропнет. Если роутер "режет tcp клиенту" (т.е. на отдаче в интерфейс к клиенту) - ничего не забьётся.

2Orshansky : мы рассматриваем случай "чистого" транспорта, без модификации заголовков пакетов - обычные soho-девайсы.

 

[Гість 7548]

и что? Опять "абы ляпнуть" ?
мы говорим о сохо девайсах ТС-а, в мессаге #1 они указаны. Укажите модель девайса и его стоимость для ТС-а , плз, работающего с маркерами приоритетов (и, самое главное - кто/что эти маркеры на траффик повесит).

MikroTik RB750 400 грн
самое настоящее сохо.
умеет маркеры, приритеты, очереди red, fifo, pcq и т.д.

 

[Orshansky]

MikroTik RB750 400 грн
самое настоящее сохо.
умеет маркеры, приритеты, очереди red, fifo, pcq и т.д.

+ hierarchical queue structure.

 

[Гість 7548]

если РОУТЕР режет НА входе от аплинка транзитные пакеты, адресованные клиенту - то да, весь входной канал от аплинка будет забит этим траффиком, который роутер дропнет. Если роутер "режет tcp клиенту" (т.е. на отдаче в интерфейс к клиенту) - ничего не забьётся.

я прошу прощения, а какая нафиг разница, режет он на входящем интерфейсе или на исходящем или например в user space? результат для клиента однако одинаков.

 

[alex444]

denzz: я выше уже показывал цитату.
A gateway MAY discard internet datagrams if it does not have the buffer space needed to queue the datagrams for output to the next network on the route to the destination network.
разница в том, что при таком "зажимании" (отдачи клиенту) - пойдёт штатный ицмп источнику "уменьшить скорость отдачи", при "зажимании" на интерфейсе от аплинка - никаких механизмов не предусмотрено (в стеке, я не говорю о системах с доп.маркерами в заголовках пакетов).

 

[Orshansky]

2Orshansky : мы рассматриваем случай "чистого" транспорта, без модификации заголовков пакетов - обычные soho-девайсы.

А я рассматриваю, "обычные soho-девайсы", как компьютерные системы на базе RISC процессоров с установленной ОС общего назначения - Linux/FreeBSD или в лучшем случае RT ОС vxWorks/QNX. Поэтому словосочетание "не существует" употребляю редко по отношению к таким устройствам. Да, они имеют жесткие ограничения по производительности, но функционал там может быть достаточно хорошим - Mikrotik/Vyatta...