|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Slawa Olhovchenkov 2:5030/500 13 May 2004 21:34:46
To : Oleg Derevenetz
Subject : Journal FS mustdie!
--------------------------------------------------------------------------------
13 May 04, Oleg Derevenetz writes to Slawa Olhovchenkov:
SO>> Это тебе даст либо задержку следующих пакетов либо их дропание. Hо при
SO> SO>> этом пакет в интерфейс улетит все равно на интерфейсной скорости.
SO>> И на другой скорости он этого делать не умеет.
OD> Да, конечно. Hо мы их "с перерывами подкидывать" будем :-)
Hо это не панацея, если не вводить жесткую фрагментацию.
SO>> ты уже не переформируешь. В отличии от ATM, торчащего в роутер где
SO>> cell можно с перерывами подкидывать, соблюдая среднюю скорость и вовсе
SO>> не обязательно всю полуторакильную пачку засовывать сразу на скорости
SO>> 155мбит/с.
OD> А я и не собираюсь переформировывать _улетевший_ в тупую железку пакет. Где
OD> ты это прочел ?
Это я твержу о том, что если пакет большого размера в тупую железку улетел, то
все твое умение в одном L2 пакете перемешать несколько фрагментов от L3 пакетов
не спасет от злобного джитера.
OD> А насчет ATM - естественно. Я и не говорю, что ATM - это
OD> плохо. Просто бывает, что его нету.
Я ATM для примера привел. ДЛя илюстрации.
SO>> Так это ты не добавление payload предлагаешь, а устроить искуственную
SO>> жесткую фрагментацию с пересборкой. Большие накладные расходы и
SO>> отсутствие явной информации о congestion. Других подстав вроде нету.
OD> Жесткую фрагментацию с приоретизацией. А явной сигнализации о congestion ты
OD> и в MPPP не добьешься. Максимум - дропы пакетов, и соответственно
OD> отсутствие подтверждений об их доставке (в TCP).
Это почему же? Cisco умеет смотреть и на размер vc queue и на разиер
интерфейсной очереди и адекватно на них реагировать. А так же (в некоторых
случаях) доступна информация от транспортной сети о превышении бюджета.
OD>>> Hу в общем да, 24 байта оверхеда многовато. Hо на DSL как правило
OD>>> 256/512k
SO>> У нас продают 64download/16upload.
OD> Сурово.
Вот и крутись как умеешь. Ладно сейчас есть еще вариант 64/64, но всеравно 64 --
это не 256. Hа 256 есть шансы и без рагментации выжить.
SO>> Hа таком линке около 256 получается. 25% оверхеда.
OD> Угу. Бывает, что минимизация jitter'а важнее, чем выигрыш в скорости.
Hе каждый клиент на это пойдет
... А в попугаях я длиннее!
--- GoldED+/BSD 1.1.5
* Origin: (2:5030/500)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
