|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 31 May 2002 08:39:12
To : Lev Serebryakov
Subject : Re: QOS
--------------------------------------------------------------------------------
>>> Lev Serebryakov wrote:
VN> diffserv-like - да. intserv-like - ой, сомневаюсь.
VN> Смотри на ALTQ. Или dummynet научилась выделять по принципу "если
VN> есть более приоритетный - не шире этой полосы, иначе - выделять
VN> сколько получится"?
> Hу, пишут, что есть WF2Q+, который поддерживает приоритеты...
Посмотрел ман - да, похоже.
>> диалап, причем диалапит и NAT'ит машина с FreeBSD. Провайдер
>> хороший, 5Kb/s по FTP или HTTP -- норма жизни. Hо при этом
>> практически невозможно работать по SSH, IRC и очень плохо с ICQ.
VN> А вот провайдера ты не вылечишь.
> А зачем его лечить? Его-то как раз я понимаю -- скольким процентам клиентов
> коммерческого диалап-провайдера нужен ssh? Думаю, что 1% -- это завышенная
> оценка...
Дело не в этом. Дело в очередях на входе _к тебе от провайдера_.
Если у тебя будет 20 качальщиков порнухи, то на исходящих ты увидишь
только ACK'и. Что, ACK'и зажимать до нужной ширины?
Если шейпинг на выходе - операция понятная, то на входе - идеологически
проблемная: пакет-то уже пришел, и не пускать его к потребителю -
выглядит для многих скорее как садистское наказание, чем мера ограничения...
И TCP flow control в этом случае начинает работать странно - я добивался
дома даже на NewReno TCP регулярных пульсаций потока.
VN> Hесколько поможет очередь на __входе__ с bw где-то в половину ширины
VN> канала или меньше. Hо будет неустойчиво.
> По идее, если от меня будут задерживатся ACK'и для HTTP-соединения, то
> передающая сторона переполнит окно и притормозит. Я не прав?
Зависит от размеров окна. Hичто не мешает клиенту задрать его до небес
(например, поставить равным мегу). У реализаций TCP есть свои ограничения
пределов разгона в зависимости от RTT, но они косвенные и слабые.
А ACK"и - ты будешь пересчитывать 40-байтные ACK'и на 1500-байтные пакеты
данных и в соответствии с этим задавать полосу шейперу?
Боюсь, тут же нарвешься на сильные проблемы для всех других протоколов.
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
| Тема: |
Автор: |
Дата: |
|
QOS |
Lev Serebryakov |
29 May 2002 01:04:23 |
 Re: QOS |
Eugene Grosbein |
29 May 2002 09:54:16 |
 Re: QOS |
oleg dashevskii |
29 May 2002 10:49:18 |
  Re: QOS |
Eugene Grosbein |
29 May 2002 21:43:13 |
 Re: QOS |
oleg dashevskii |
31 May 2002 10:31:52 |
|
Re: QOS |
Eugene Grosbein |
31 May 2002 15:46:21 |
|
QOS |
Lev Serebryakov |
29 May 2002 12:37:34 |
|
Re: QOS |
Eugene Grosbein |
29 May 2002 17:27:16 |
|
Re: QOS |
Yaroslav Halchinsky |
29 May 2002 13:32:15 |
|
QOS |
Ilia Kuliev |
29 May 2002 08:00:52 |
|
Re: QOS |
Gregory Ansari |
29 May 2002 16:10:38 |
|
Re: QOS |
Valentin Nechayev |
29 May 2002 23:45:57 |
|
QOS |
Ilia Kuliev |
30 May 2002 00:19:10 |
|
Re: QOS |
Valentin Nechayev |
30 May 2002 20:39:23 |
|
QOS |
Lev Serebryakov |
30 May 2002 12:20:27 |
|
Re: QOS |
Valentin Nechayev |
31 May 2002 08:39:12 |
|
QOS |
Lev Serebryakov |
31 May 2002 20:08:25 |
|
QOS |
Slawa Olhovchenkov |
03 Jun 2002 20:06:44 |
|
QOS |
Lev Serebryakov |
04 Jun 2002 00:59:00 |
|
QOS |
Slawa Olhovchenkov |
04 Jun 2002 10:11:22 |
|
Re: QOS |
Valentin Davydov |
04 Jun 2002 12:57:24 |
|
QOS |
Ivan Voytas |
04 Jun 2002 12:29:27 |
|
Re: QOS |
Valentin Nechayev |
06 Jun 2002 22:55:44 |
|
QOS |
Sergey Novak |
12 Jun 2002 22:51:49 |
|
QOS |
Lev Serebryakov |
14 Jun 2002 11:25:51 |
|
|
