Об'ективная оценка качества канала

[alcool]

Часто бывает необходимость оценить качество канала в интернет.

Понятно что беглую оценку можно сделать пингом. Но как оценить качество\скорость работы днс сервера?

Как оценить собрать статистику за лень\неделю по доступности?

Ну и как по этим данным оценить возможность использования voip.

 

В общем хочу услышать умные мысли.

[jab]

Часто бывает необходимость оценить качество канала в интернет.

Так не бывает, либо качество, либо интырнет.

[boykov]

Часто бывает необходимость оценить качество канала в интернет.

Понятно что беглую оценку можно сделать пингом. Но как оценить качество\скорость работы днс сервера?

Как оценить собрать статистику за лень\неделю по доступности?

Ну и как по этим данным оценить возможность использования voip.

 

В общем хочу услышать умные мысли.

Для voip?

Берем девочку, фри паскаль и скайп.

Делаем так:

{Beware of bugs in the above code; I have only proved it correct, not tried.}
var
i, j: integer;
const
  MinRate = 3;
  MaxRate = 10;
begin
randomize;
for i:= 1 to 30 do
   begin
    writeln(i);
    for j:= 1 to random(MaxRate-MinRate)+MinRate do
         writeln(Random(24),':',Random(60), 
                         'hrukov -                    ', 
                         'vzdragivaniy -            ', 
                         'ocenka - ');
    writeln;
end.

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

Девочка по расписанию звонит кому-нибудь и оценивает качество связи, считает количество хрюков и вздрагиваний. На высказывания "это не интеллектуальная работа, я программистка" честно заявляем, что это именно программистская работа -- сортировка внутри групп. Предлагаем вспомнить, кто такой Шелл.

Тридцатого числа тетрадочка с пополненными записями изымается и анализируется.

 

А вообще давно придумали ping, mtr, mrtg и cacti .

[Прохожий]

Часто бывает необходимость оценить качество канала в интернет.

Как только сможете придумать способ ОБЪЕКТИВНОЙ оценки - сможете заработать огромные деньги. Реально, очень большие. Некоторые считают доказанным, что это невозможно в принципе... Некоторые (Fluke, Brix, Cisco и иже с ними) считают, что они такие средства уже создали.

 

Проблема в том, что IP-канал - как финансовый рынок, качество его в рестроспективе никак не связано с будущим качеством :) Хотя баловаться техническим анализом на финансовом рынке это никому не мешает :)

[ugluck]

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

[Sonne]

Когда я изучал эту тему выяснил что чариот единственная адекватная тулза.

 

На магистрали наилучший способ мерить джитер и дропы статистическим способом.

У циско иос есть специальная фича с пробником.

 

Вобще задачу некооректно поставили. Это похоже на вопрос о том как проверяют электрические лампочки. Самый лучший способ проверить лампочку, это разбить ее.

100% проверка качества приводит к 100% уничтожению лампочек.

 

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

[alcool]

ну логично что задачу стоит разделить:

- долгосрочный анализ (статистический)

- тестирование возможностей. (с загрузкой канала)

 

по первому пункту - можно задержку раз в минуту до определенного узла мониторить, загрузку канала и тд. Симпатичные графики нарисовать.

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

 

Правильно я обрисовал ситуацию?

[ugluck]

по первому пункту мртг.

по второму есть рфц какие-то, а в кратце просто мегабитная производительность и ппс. кстати, что за канал? если в интернет (аплинк), то эмулировать нагрузку на нем представляется затруднительно.

Edited December 13, 2008 by ugluck

[jab]

 

Вот для таких хитрозадых измерителей каналов ICMP в обход шейперов и пускают, меряй - не хочу. :-) А уж пресловутая полочка на mrtg - вообще недоказуема, это порносервера тормозят, с ними и разбирайтесь. ;-) Показания торрентов - это вообще пальцем в небо. Там просто

технологически скорость скачет постоянно.

[ugluck]

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

[Beast]

ну почему нет. есть. лет пять назад в разборках доходило дело до РД номер не помню.

там было обнаружено что-то типа не более 5% процентов потерь и не более 1секунды задержки ;)

 

Джаб! вообще-то трейс имеет отличный от пингового механизм получения ответного пакета.

а icmp мы в РТкКОме всегда из-под шейперов выводили.

[ugluck]

<...> трейс имеет отличный от пингового механизм получения ответного пакета <...>

не всегда.. сам удивился, когда узнал. оказывается, винда трассирует по icmp а цыска и линух - по udp

[jab]

ну почему нет. есть. лет пять назад в разборках доходило дело до РД номер не помню.

там было обнаружено что-то типа не более 5% процентов потерь и не более 1секунды задержки ;)

Оно там до сих пор такое. Можно спокойно давать 100 мегабитный анлимит, с 5% packet loss rate и 950ms delay. :-)

 

Джаб! вообще-то трейс имеет отличный от пингового механизм получения ответного пакета.

а icmp мы в РТкКОме всегда из-под шейперов выводили.

Обычно невиндовый трэйс дает запрос по UDP или TCP на случайный порт, с инкрементом TTL. Ответом будет ICMP: TTL exceeded in transit. Но при большом буффере шейпера, весь этот трэйс пролетит до того,

как труба начнет работать, так что это не существенно. Тут визуально будет больше ругани на DNS.

[Прохожий]

ну почему нет. есть. лет пять назад в разборках доходило дело до РД номер не помню.

РД.45.128-2000 "Сети и службы передачи данных"

Параметры качества там взяты с МСЭ-Т Y.1541

 

там было обнаружено что-то типа не более 5% процентов потерь и не более 1секунды задержки ;)

Все намного круче!

 

. Кроме того, предварительно рекомендуются следующие нормы для всех классов обслуживания, кроме «приемлемого»:

- время доступа: не более 5 с;

- коэффициент потери IP-пакетов: не более 1х10-3;

- коэффициент ошибок в IP-пакетах: не более 1х10-4;

- критерий отказа: отказом считается ситуация, при которой коэффициент потери IP-пакетов превышает 0,75.

 

Для "приемлемого" класса ничего не нормируется, т.е. если дроп 74%, то это - нифига не отказ :) А задержка может быть любой.

 

Нету нормативки по сути, нету, можно успокоиться. Закон на стороне провайдера ;)

[m.egorov]

Да не так всё плохо:

http://www.garant.ru/prime/20071030/92047.htm