Потери на канале в несколько мегабит, пров объясняет это работой шейпера

Есть канал для юрлица в несколько мегабит. Как тока канал нагружаем по полной идут потери и пинг больше 100мс, а тои по полторы секунды. Пров объясняет это действием шейпера, и типа так и должно быть... У меня на канале VoIP, потери весьма критичны... С другими провами такого никогда не наблюдал.
Чем бить провайдера?

Докупкой у него ещё нескольких мегабит канала до неполной его загруженности.

Или аналогичный вариант - не полностью нагружать канал. Не вариант. С таким раскладом у домашних пользователей на 128к в таком случае потерь должно быть больше половины пакетов, а оставшиеся будут с пигом по 8 секунд

А как может быть на перегруженном канале низкий пинг без потери пакетов? Только попроще, а то я неграмотный.

Это сообщение отредактировал дядя Саша - 1.09.2010 - 14:57

Да хрен с ним, пусть пинг подрастёт, но потерь вот совсем не надо.

да это вполне реальное объяснение..

ZAC
Потери зависят от не от абсолютной скорости, а от того сколько ты пытаешься пропихнуть в маленький канал. Протоколы интернета устроены так, чтобы снижать скорость при увеличении задержки или потерях пакетов.
Домашние потребители не снижают скорость при потерях, и потери прекращаются, всё просто ))

ПОэтому большие потери говорят о СИЛЬНОЙ, неспадающей перегрузке. Скорее всего вирусы или пообные вещи перегужают канал. Или о попытках "обмануть" ограничитель провайдера, игнорируя требования протоколов интернета о снижении скорости при возникновения потерь.

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

При 90% Загрузке канала потери есть?

PS: И, кстати говоря, для передачи голоса лучше небольшие потери чем большие задержки. Такие дела )

Не совсем, скорость падает за счёт необходимости повторной пересылки потерянного пакета.
При нормальной работе потери меньше одного процента, но при закачке, любой закачке ограничиваемой шириной моего канала, растут пинги и появляются потери до 15%. Потери растут пропорционально загрузке.

смотря что считать большими задержками и небольшими потерями.

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

Что "не совсем"? Кого ты лечишь? Сама по себе повторная пересылка не снижает нагрузки на канал, и не предупреждает дальнейшие потери. Основа протокола TCP это СНИЖЕНИЕ СКОРОСТИ ПЕРЕДАЧИ, если другая сторона сообщает о потерях при приёме.

Ты выше писал что лишь бы потерь не было а на зедержки тебе плевать !

Вот я и говорб тебе что уж лучше для передачи голоса 2% потерь и задержки не более 100 миллисекунд, чем 0,5% потерь с 200 миллисекундной задержкой.
А там ещё джиттер, в общем без настройки не будут работать передача голоса с торрентами ))

Что за оператор? Какой тип услуги? Трафик крАсите?

ZAC
просите размер очереди увеличить.
а для voip - приоретизацию трафика

предположу, что размер очереди по дефолту на циске больше чем на другой железке.

а че странного? вы денег жалеете на расширение каналов, а провайдер должен еще и оборудование подороже ставить.

Это сообщение отредактировал camlost - 2.09.2010 - 08:08

Продвинутые клиенты в договоре требуют
Real-time -15%
Business-critical -20%
Best-effort -65%

spike

происходит повторная передача потерянных пакетов

Мы с вами на брудершафт не пили, так что прошу либо быть адекватнее, либо покинуть эту тему. Ваши сообщения в дальнейшем будут мной игнорированы.

__Андрей__
Оператора не назову по этическим соображениям. Интернет по радио, 60м в прямой видимости тарелками, до тарелок у них оптика.

camlost
Нет нужды в расширени каналов. Провайдер обещанное должен давать и так. Приоритезации трафика у них нет, тоже подумал об этом. Своими силами - доп. затраты...

Tokar
Ага, тут обещали что после 4х часов простоя день в подарок, и что любая заявка в течении 4х часов в рабочее время будет принята в работу, а на деле всё саавсем не так А договр уже есть, и в данном месте у них монополия.

Для воипа рекомендуется чтобы параметры были не хуже следующих:

Задержка <= 150 мс
Джиттер <= 30 мс
Потери <= 1%.

По поводу потерь spike прав - лучше уж потери, чем задержки.

P.S.
По поводу tcp:
замедление происходит за счет уменьшения window size при возникновении потерь. а не из-за ретрансмитов.
уменьшая window size tcp снижает наоборот это кол-во ретрансмитов и минимизирует задержки.