Физические способы ограничения полосы

[misha mike]

Подскажите мне, уважаемые спецы, какие низкоуровневые способы ограничения ширины канала бывают?

 

Дело в том, что я имею канал в 64K, который реально дает эту скорость без проблем. Непонятки начинаются когда во время закачки пинг возрастает иногда до десяти секунд (в нормальном состоянии он имеет порядок ста миллисекунд). Я так понимаю что если канал загружен на 100% и кто-то еще его пытается использовать, то он разделяется между желающими поровну. Ведь именно так себя ведет например локальная сеть: даже при стопроцентной загрузке сетевого интерфейса пинг практически не увеличивается. А тут такой неприятный эффект...

 

У провайдера мне сказали что увеличение задержки -- это следствие урезания их широкого канала до оплаченных мной 64K, с чем в принципе трудно не согласиться. Но ведь ИМХО это далеко не самый лучший способ ограничения полосы! Аппаратные ограничения скорости портов ведь не вносят никаких задержек, почему тогда софтовое должно?

 

Короче у меня вопрос -- это нормальное явление, или все-таки у провайдера не все хорошо?

[GateKeeper]

Что такое пинг, и как оно соотносится с шириной канала? Опять меряем длину щепотью?

[misha mike]

Что такое пинг, и как оно соотносится с шириной канала? Опять меряем длину щепотью?

Я тоже об этом и спрашиваю.

 

Вот реальная картина происходящего:

===========================================

C:\>ping www.com -w 30000 -t

 

Обмен пакетами с www.com [64.131.66.218] по 32 байт:

 

Ответ от 64.131.66.218: число байт=32 время=133мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=133мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=138мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=134мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=133мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=133мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=136мс TTL=48

// тут запускаем закачку

Ответ от 64.131.66.218: число байт=32 время=521мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=2863мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=8575мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=7658мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=9490мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=8881мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=10057мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=9051мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=9185мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=10122мс TTL=48

// останавливаем закачку

Ответ от 64.131.66.218: число байт=32 время=515мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=133мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=129мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=131мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=133мс TTL=48

Ответ от 64.131.66.218: число байт=32 время=137мс TTL=48

===========================================

У провайдера говорят что таким образом собственно и ограничивается скорость обмена по поему каналу. ИМХО плохой способ, ведь можно и по-другому ограничить.

[deep_admin]

по-другому это как?

[misha mike]

по-другому это как?

Примерно так же, как до 100 Mbps ограничивает скорость обычная сетевая плата....

[vIv]

она не ограничивает ничего. она просто не передаёт то, что не может передать

[deep_admin]

по-другому это как?

Примерно так же, как до 100 Mbps ограничивает скорость обычная сетевая плата....

она не ограничивает, тут физика не позволяет....

если хотите такого же - используйте оборудование для подключения к провайдеру которое физически не сможет дать большую скорость, например e1 с одним таймслотом (как раз 64кбит/с)

[misha mike]

vIv, deep_admin.

Я согласен что карточка и прочие железки ничего не ограничивают, а просто передают сколько могут. Но пинги же при этом не возрастают катастрофическими темпами. Мне же интересно почему точно такую же картину нельзя воссоздать программно на более быстром железе?

[vIv]

не почему, а зачем

шейпер именно "размазывает" трафик в попытке одновременно не превысить скорость, и не потерять пакеты. В случае с физикой - лишнее просто отбрасывается.

 

Чисто теоретически провайдер на своей стороне и на твоей стороне может сделать приоритезацию трафика, но вряд ли будет это делать за незаметные деньги

[misha mike]

не почему, а зачем

шейпер именно "размазывает" трафик в попытке одновременно не превысить скорость, и не потерять пакеты.

Так, а если каким-либо образом уменьшить максимальный размер пакета и длину буфера передачи, то по идее должно сократиться и время между успешным проталкиванием блока данных в сокет и их реальным уходом в мир?

 

В случае с физикой - лишнее просто отбрасывается.

А почему тогда пинги продолжают доходить (и почти так же быстро как и без нагрузки)? Или мне кто-то не дает на все 100% загрузить сеть? Слышал краем уха когда-то про надстройку QoS и десятипроцентный резерв канала под нее...

[deep_admin]

не почему, а зачем

шейпер именно "размазывает" трафик в попытке одновременно не превысить скорость, и не потерять пакеты.

Так, а если каким-либо образом уменьшить максимальный размер пакета и длину буфера передачи, то по идее должно сократиться и время между успешным проталкиванием блока данных в сокет и их реальным уходом в мир?

 

В случае с физикой - лишнее просто отбрасывается.

А почему тогда пинги продолжают доходить (и почти так же быстро как и без нагрузки)? Или мне кто-то не дает на все 100% загрузить сеть? Слышал краем уха когда-то про надстройку QoS и десятипроцентный резерв канала под нее...

 

вы врядли грузите 100мбит езернета под 100%, вы попробуйте взять железки ну например теже дслки или вай-фай и нагрузить их, и посмотрите на пинги

icmp это такой же трафик как и любой другой

[misha mike]

вы врядли грузите 100мбит езернета под 100%

Гружу настолько, насколько это возможно, не поленился для этого пару программок накидать. Но какая-то сволочь действительно оставляет около 10% канала свободной вне зависимости от его ширины!

 

Вот два работающих на полную катушку синтетических клиента (один почему-то не справлялся):

 

Вот монитор загрузки сети на 100 Mbps:

Первая ступенька -- один клиент, вторая -- второй. Добавление третего и больше клиентов картины уже не меняет.

 

Вот монитор загрузки сети на 10 Mbps:

Тут уже справляется и один клиент, но имеются какие-то странности с равномерностью загрузки. Тем не менее 10-12% ширины канала проставивает и это прекрасно видно.

 

вы попробуйте взять железки ну например теже дслки или вай-фай и нагрузить их, и посмотрите на пинги

icmp это такой же трафик как и любой другой

Пробовал когда-то с модемом, были те же проблемы, но там связь была очень плохая, ничего кроме стандартной локалки пока под рукой нет.

[Barsick]

Дело в том, что я имею канал в 64K, который реально дает эту скорость без проблем. Непонятки начинаются когда во время закачки пинг возрастает иногда до десяти секунд

Поставить еще один шейпер между провом и тобой, и обрезать полосу, ну, например до 62-63К. Имхо.

[nuclearcat]

Все зависит от типа "очереди" у провайдера.

Если там Fair-Queue или SFQ/ESFQ - то будет пытаться распределять пакеты равномерно. Если FIFO - обычная очередь.

Пинг будет расти однозначно, т.к. почти всегда на шейпере есть определенный буфер.

[edo]

всё очень просто - мир устроен так, что вы напрямую можете управлять только отсылаемымми пакетами. приходщие же к вам пакеты генерируются на других компьютерах и напрямую вы на этот процесс воздействовать не можете.

так вот сервер, откуда вы скачиваете не знает, что у вас канал 64кбит, начинает через свой жирный гигабитный канал слать вам пакеты.

вашему провайдеру пакетов для вас приходит больше, чем пролезает в ваш канал.

он может на выбор:

- отложить эти пакеты (задержка ping растет);

- откинуть лишние пакеты (ping не проходит).

 

то есть если бы у вас задержка не росла - пакеты просто терялись бы (что там винда пишет? кажется "Превышен интервал ожидания для пакета").

 

ps: пришла в голову автомобильная аналогия:

трасса, три полосы. все едут 100-120. въезд в город - пост дпс, все едут по одной полосе, скорость 40-60. перед постом образуется пробка, в ней машины теряют время.

вот ваш узкий канал - это пост дпс, если пакетов больше, чем он может пропустить - возникает та же самая пробка, задержки увеличиваются.

когда пробка становится слишком большой - часть машин разворачивается и едет назад или ищет обходную дорогу (для нас они пропали - через пост дпс они уже не проедут).

вот пакеты начали теряться.

[misha mike]

ps: пришла в голову автомобильная аналогия:

трасса, три полосы. все едут 100-120. въезд в город - пост дпс, все едут по одной полосе, скорость 40-60. перед постом образуется пробка, в ней машины теряют время.

вот ваш узкий канал - это пост дпс, если пакетов больше, чем он может пропустить - возникает та же самая пробка, задержки увеличиваются.

когда пробка становится слишком большой - часть машин разворачивается и едет назад или ищет обходную дорогу (для нас они пропали - через пост дпс они уже не проедут).

вот пакеты начали теряться.

Мне такая же аналогия придумалась :) Но у меня тогда вопрос: если я начал качать большой блок данных по протоколу без контроля потока, то удаленный сервер по своему широкому каналу будет передавать его непрерывно и не угомонится пока данные не закончатся. Этому процессу должен быть некоторый предел (ведь TCP/IP имеет собственные средства контроля потока), после которого серверу пойдут отлупы и он будет думать прежде чем передать следующий кусок данных? Если так, то значит уменьшение размера пакета и длины очереди таки поможет улучшить время реакции, или я чего-нибудь недопонимаю?

[deep_admin]

ps: пришла в голову автомобильная аналогия:

трасса, три полосы. все едут 100-120. въезд в город - пост дпс, все едут по одной полосе, скорость 40-60. перед постом образуется пробка, в ней машины теряют время.

вот ваш узкий канал - это пост дпс, если пакетов больше, чем он может пропустить - возникает та же самая пробка, задержки увеличиваются.

когда пробка становится слишком большой - часть машин разворачивается и едет назад или ищет обходную дорогу (для нас они пропали - через пост дпс они уже не проедут).

вот пакеты начали теряться.

Мне такая же аналогия придумалась :) Но у меня тогда вопрос: если я начал качать большой блок данных по протоколу без контроля потока, то удаленный сервер по своему широкому каналу будет передавать его непрерывно и не угомонится пока данные не закончатся. Этому процессу должен быть некоторый предел (ведь TCP/IP имеет собственные средства контроля потока), после которого серверу пойдут отлупы и он будет думать прежде чем передать следующий кусок данных? Если так, то значит уменьшение размера пакета и длины очереди таки поможет улучшить время реакции, или я чего-нибудь недопонимаю?

 

из известных протоколов такой контроль имеет только TCP и тому подобные реализации, опять же размер пакета не уменьшится, станет размер сегмента, но все равно не менее размера MTU - служебная инфа. С UDP такого даже не произойдет - не влезающие в канал пакеты будут тупо отбрасываться

[edo]

да, tcp подстраивается под доступную скорость. выглядит это так - сервер постоянно пробует поднять скорость передачи данных, когда возникают затыки - скорость немного снижается. в результате ваш канал забит под завязку (плюс ещё чуть-чуть).

повторюсь - сервер же не знает, что у вас канал 64кбит, а не, например, спутниковый канал в пару десятков мегабит, но с огромными задержками и потерями - поэтому он всё время будет пытаться засунуть в ваш канал чуть больше, чем туда помещается.

Edited July 22, 2007 by edo

[misha mike]

Жаль что TCP не поддерживает ограничение скорости на уровне сессии :(

 

Ладно, буду терпеть, спасибо всем.

 

P.S. Ох и смачная гроза этой ночью над Киевом прошла. Каждые три секунды молния. Менее секунды между вспышкой и громом. Решил воспользоваться случаем и проверить на прочность защиты портов, но после десятка сообщений "сетевой кабель не подключен" не вынес издевательств и повыдергивал шнурки (защиты оставлял)...

[Ascent77]

Смотрю и удивляюсь на форуме одни провайдеры и люди связанные с интернетом, а как конкретный вопрос

так один флейм, зато как обсудить 10гбит/с и влан до клиента тут мы да...могём...

Итак, виноват в проблеме исключительно провайдер не желающий учить матчасть, что изменить:

1. Приоритет маленьким пакетам. Особенно от этого выиграет tcp, так как наконец сможет нормально устанавливать соэдинения: поясняю syn syn/ack и ask пакеты не будут томится в в буфере шейпера.

2. Настроить размер буфера шейпера в зависимости от полосы пропускания.

И все проблемы волшебным образом пропадут.

[vIv]

Вообще-то в связи приноято правило "70%"

Если канал регулярно нагружается до 70% - его надо расширять.

Так-что провайдер тут ни в чём не виноват. Не хватает полосы - заказывайте больше.

Постоянно работать в режиме "выживем в аварии несмотря ни на что", - мазохизм и глупость.

[SergeiK]

Смотрю и удивляюсь на форуме одни провайдеры и люди связанные с интернетом, а как конкретный вопрос

так один флейм, зато как обсудить 10гбит/с и влан до клиента тут мы да...могём...

Это все просто. Сакральными знаниями делиться никто не хочет :).

А поболтать за жизть - запросто.

 

А потом - скажешь - приоритет мелким пакетам - а как?

Очередь-то на стороне провайдера, клиент со своей стороны ничего сделать не сможет.

[Ascent77]

Очередь-то на стороне провайдера, клиент со своей стороны ничего сделать не сможет.

Вот поэтому я и сказал, что вся вина на провайдере.

 

 

Вообще-то в связи приноято правило "70%"

Если канал регулярно нагружается до 70% - его надо расширять.

Не в тему, так как, в данном случае нет регулярной нагрузки, любая закачка(даже в один поток) полностью убивает канал, может пользователю вообще в интернет не ходить:)? Не надо оправдывать провайдера когда ситуация проста как 3 рубля, а то будет как у врачей круговая порука.

[SergeiK]

Да не вина это провайдера...

 

У провайдера 2 варианта - делать очередь длинее, чтоб потери были меньше или же очередь короче - пинги короче.

Ставить на каждого отдельную очередь - не тот класс клиентов, чтоб так извращаться.

 

Хотя 10 сек - на мой взгляд - многовато. 3 мне кажутся достаточными.

 

Клиент должен сам понимать - у него всего 64К, либо он качает, либо играет :).

Для всех других сервисов такие задержки не критичны.

[misha mike]

Клиент должен сам понимать - у него всего 64К, либо он качает, либо играет :).

Угу, вот только даже браузер не всегда может загрузить ресурсы страницы, сессии просто отваливаются по таймауту (это FF недоделанный так себя ведет, Opera, в принципе, работает нормально, но тормоза все равно напрягают малость).

 

Для всех других сервисов такие задержки не критичны.

Из-за этих задержек иногда TCP-соединение создаться не может. Так что критично это всем сервисам, кто не через UDP работает. Edited August 8, 2007 by misha mike