|
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) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.unix.bsd/736885788e43.html, оценка из 5, голосов 10
|