|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Oleg Derevenetz 2:5025/3.4 13 May 2004 21:04:01
To : Slawa Olhovchenkov
Subject : Journal FS mustdie!
--------------------------------------------------------------------------------
At 13 May 04 20:15:06, Slawa Olhovchenkov wrote to Oleg Derevenetz:
OD>>>> Провайдерская сторона должна добавлять payload еще до того, как
OD>>>> пакет уйдет в Zyxel. Минимальный размер фрейма в Ethernet, если мне
OD>>>> не изменяет память, 46 байт, так что оверхеда за счет "добивания" не
OD>>>> должно быть.
SO>>> У нас есть полтора кило от мыла. Мы их и отправили. И они улетели --
SO>>> мы глазом моргнуть не успели. Медленно мы отправлять не можем --
SO>>> улетает всегда со скоростью езернета. В буфере сетевухи пакет так же
SO>>> не принято
OD>> Почему не можем ?
SO> Потому что по езернету пакеты передаются со скорость или 10 или 100 или
SO> 1000 или 10000 мбит/с.
Физически в интерфейсе - да.
[...]
OD>> Это оффтопик, пожалуй, но на cisco это делается с помощью
OD>> иерархических policy-map - внешний с police, внутренний с LLQ,
OD>> навешиваемого на Virtual-Access (применительно к PPPoE).
SO> Это тебе даст либо задержку следующих пакетов либо их дропание. Hо при
SO> этом пакет в интерфейс улетит все равно на интерфейсной скорости. И на
SO> другой скорости он этого делать не умеет.
Да, конечно. Hо мы их "с перерывами подкидывать" будем :-)
OD>> То есть LLQ работает правильно (police настроен соответственно
OD>> скорости на DSL-линке), печалит только отсутствие фрагментации.
SO> Я повторюсь -- пакет, улетевший по езернету в DSL-модем/концентратор ты
SO> уже не переформируешь. В отличии от ATM, торчащего в роутер где cell
SO> можно с перерывами подкидывать, соблюдая среднюю скорость и вовсе не
SO> обязательно всю полуторакильную пачку засовывать сразу на скорости
SO> 155мбит/с.
А я и не собираюсь переформировывать _улетевший_ в тупую железку пакет. Где ты
это прочел ? А насчет ATM - естественно. Я и не говорю, что ATM - это плохо.
Просто бывает, что его нету.
SO>>> на ходу исправлять. Как ты предлагаешь туда payload добавлять? Его
SO>>> _еще_ нету, он только через 20мс придет. если не потеряется.
OD>> Запросто предлагаю. До LLQ пакеты бьются на фрагменты, полисер дает
OD>> LLQ работать в соответствии с реальной пропускной способностью DSL-линка
OD>> дальше.
SO> Так это ты не добавление payload предлагаешь, а устроить искуственную
SO> жесткую фрагментацию с пересборкой. Большие накладные расходы и
SO> отсутствие явной информации о congestion. Других подстав вроде нету.
Жесткую фрагментацию с приоретизацией. А явной сигнализации о congestion ты и в
MPPP не добьешься. Максимум - дропы пакетов, и соответственно отсутствие
подтверждений об их доставке (в TCP). Hу и бог с ним, тормознется у тебя FTP,
зато RTP будет нормально ходить. Ты же этого хотел ? Для RTP, естественно,
strict priority и разумная полоса.
SO>>> Все резать на минимальные езернетовские фреймы -- 18 байт езернетного
SO>>> оверхеда + 6 байт твоих накладных тебе канал в ноль усадят.
OD>> Hу в общем да, 24 байта оверхеда многовато. Hо на DSL как правило
OD>> 256/512k
SO> У нас продают 64download/16upload.
Сурово.
OD>> минимум продают, поэтому фрагменты можно и поболее сделать размером,
OD>> чем 64 байта.
SO> Hа таком линке около 256 получается. 25% оверхеда.
Угу. Бывает, что минимизация jitter'а важнее, чем выигрыш в скорости.
--- QDed beta v1.3 under FreeBSD 4.0-RELEASE
* Origin: Взялся за гуж - полезай в кузов... (2:5025/3.4)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
