|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 18 Oct 2005 20:15:00
To : Eugene B. Berdnikov
Subject : Re: Дык на чём остановиться?
--------------------------------------------------------------------------------
Oct 18 16:08 05, Eugene B. Berdnikov wrote to Zahar Kiselev:
ZK>> Причем основная задница в том, что у провайдера (для примера тот же
ZK>> вебплюс)
ZK>> стоит крутое коммуникационное оборудование, в котором буферы
ZK>> килобайтов на дцать. От этого плохо(медленно) работает все, что
ZK>> требует частого взаимодействия "вопрос/ответ". Это если качаешь один
ZK>> огромный файл по http -
EBB> Hе этого. То есть вовсе не от размера буфера.
Я описал реальную ситуацию - ответ моего фидошного узла через арендованный в
режиме разделения времени провайдерский модемный пул. Гидра там работает весьма
посредственно - именно из-за того, что посланные в сторону клиента пакеты
"болтаются где-то в канале". То есть она работает, но намного медленее чем через
два обычных модема на такой же скорости.
EBB> Вы описываете ситуацию, в которой скорость перекачки ограничена
EBB> модемом.
Естественно - как наиболее актуальную дял меня.
EBB> Какие в таком случае претензии к параметрам провайдерского роутера?
Hе роутера, а Access Server`а
EBB> Всё правильно, QoS сам по себе не возникнет. Если он нужен - надо
EBB> просить
EBB> провайдера расставить приоритеты для трафика на downlink'e.
В данном случае вид трафика только один - фидошный. Между клиентом и Access
Server`ом он может идти как просто по модемному соединению, так и поверх ppp,
работающего по тому же модемному соединению. С точки зрения тормозов - разницы
нет, проверялось и так и так.
EBB> Hо можно немного улучшить ситуацию, если не допустить скопления
EBB> пакетов в провайдерском роутере, а подобрать параметры канала так, чтобы
EBB> очередь возникла у получателя. Это довольно сложная задача, и требует
Hе уверен что решаемая в моем случае.
ZK>> "чистый" tcp даже на таком странном канале живет довольно прилично, у
ZK>> него все
ZK>> же интеллекта достаточно чтобы и к такому подстроиться,
ZK>> однако если поверх собственно tcp оказывается что-то примитивное типа
ZK>> nntp или
ZK>> даже той же Гидры с небольшим размером пакета, что требует частой
ZK>> посылки подтверждений или команд на ту сторону - то тормоза
ZK>> гарантированы.
EBB> Верно. Правда, мало кого интересует скорость nntp - ведь очень мало
EBB> людей, выбирающих, какие постинги они хотели бы скачать, а потом
EBB> ждуших закачки.
Hе далее как несколько дней назад именно эта возможность выдавалсь здесь за
основную, позволяющую достигать большей экономии трафика чем фидошная упаковка.
Мне еще тогда пытались доказать, что я качаю кучу лишнего, что не читаю.
EBB> Подавляющее большинство качает интересные эхи подряд -
EBB> им так проще (читай дешевле).
Во-первых проще тут обычно означает _дороже_. Проще не настраивать пакующий
туннель, а качать nntp как есть - но это ощутимо дороже.
Во-вторых если качать интересные эхи все же подряд - то nntp опять становится
очень невыгодным по трафику по сравнению с гидрой. Hа модеме хоть v42b немного
помогает, хотя Кирилл уже привел тут неутешительные цифры, а в случае gprs
получается что туннель с упаковкой просто необходим.
Zahar
--- Msged/LNX 6.1.1
* Origin: mobile point - Compaq Armada 1750 + Siemens ME45 (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
