Jump to content
Калькуляторы

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites
Часто бывает необходимость оценить качество канала в интернет.

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

Share this post


Link to post
Share on other sites
Часто бывает необходимость оценить качество канала в интернет.

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

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

Ну и как по этим данным оценить возможность использования 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 .

Share this post


Link to post
Share on other sites
Часто бывает необходимость оценить качество канала в интернет.

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Edited by ugluck

Share this post


Link to post
Share on other sites

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
ну почему нет. есть. лет пять назад в разборках доходило дело до РД номер не помню.

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

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

 

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

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

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

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

Share this post


Link to post
Share on other sites
ну почему нет. есть. лет пять назад в разборках доходило дело до РД номер не помню.
РД.45.128-2000 "Сети и службы передачи данных"

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

 

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

 

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

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

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

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this