alcool Опубликовано 12 декабря, 2008 · Жалоба Часто бывает необходимость оценить качество канала в интернет. Понятно что беглую оценку можно сделать пингом. Но как оценить качество\скорость работы днс сервера? Как оценить собрать статистику за лень\неделю по доступности? Ну и как по этим данным оценить возможность использования voip. В общем хочу услышать умные мысли. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 12 декабря, 2008 · Жалоба Часто бывает необходимость оценить качество канала в интернет. Так не бывает, либо качество, либо интырнет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boykov Опубликовано 12 декабря, 2008 · Жалоба Часто бывает необходимость оценить качество канала в интернет.Понятно что беглую оценку можно сделать пингом. Но как оценить качество\скорость работы днс сервера? Как оценить собрать статистику за лень\неделю по доступности? Ну и как по этим данным оценить возможность использования 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 . Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Прохожий Опубликовано 12 декабря, 2008 · Жалоба Часто бывает необходимость оценить качество канала в интернет. Как только сможете придумать способ ОБЪЕКТИВНОЙ оценки - сможете заработать огромные деньги. Реально, очень большие. Некоторые считают доказанным, что это невозможно в принципе... Некоторые (Fluke, Brix, Cisco и иже с ними) считают, что они такие средства уже создали. Проблема в том, что IP-канал - как финансовый рынок, качество его в рестроспективе никак не связано с будущим качеством :) Хотя баловаться техническим анализом на финансовом рынке это никому не мешает :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ugluck Опубликовано 12 декабря, 2008 · Жалоба каналы меряем чариотом. получается очень похоже на правду. если в долгосрочном плане, то, конечно, мртг и т.п. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 12 декабря, 2008 · Жалоба Когда я изучал эту тему выяснил что чариот единственная адекватная тулза. На магистрали наилучший способ мерить джитер и дропы статистическим способом. У циско иос есть специальная фича с пробником. Вобще задачу некооректно поставили. Это похоже на вопрос о том как проверяют электрические лампочки. Самый лучший способ проверить лампочку, это разбить ее. 100% проверка качества приводит к 100% уничтожению лампочек. Сформулируйте задачу, но не в терминах технологического ппоцеса, а в терминах достижения конечного результата. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alcool Опубликовано 12 декабря, 2008 · Жалоба ну логично что задачу стоит разделить: - долгосрочный анализ (статистический) - тестирование возможностей. (с загрузкой канала) по первому пункту - можно задержку раз в минуту до определенного узла мониторить, загрузку канала и тд. Симпатичные графики нарисовать. по второму пункту сложнее. Нужно попробовать сгенерировать различные варианты загрузки канала. Эмулировать разные ситуации: работу под торрентами, работу с большим количеством соединений, проверку производительности днс.. Правильно я обрисовал ситуацию? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ugluck Опубликовано 13 декабря, 2008 (изменено) · Жалоба по первому пункту мртг. по второму есть рфц какие-то, а в кратце просто мегабитная производительность и ппс. кстати, что за канал? если в интернет (аплинк), то эмулировать нагрузку на нем представляется затруднительно. Изменено 13 декабря, 2008 пользователем ugluck Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 13 декабря, 2008 · Жалоба Вот для таких хитрозадых измерителей каналов ICMP в обход шейперов и пускают, меряй - не хочу. :-) А уж пресловутая полочка на mrtg - вообще недоказуема, это порносервера тормозят, с ними и разбирайтесь. ;-) Показания торрентов - это вообще пальцем в небо. Там просто технологически скорость скачет постоянно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ugluck Опубликовано 14 декабря, 2008 · Жалоба у нас результаты измерений в основном применяются для внутренних разборок, или для демонстрации клиенту, что все работает. насколько я в курсе, по нашим нормативным актам нет внятных характеристик качества пакетных сетей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Beast Опубликовано 14 декабря, 2008 · Жалоба ну почему нет. есть. лет пять назад в разборках доходило дело до РД номер не помню. там было обнаружено что-то типа не более 5% процентов потерь и не более 1секунды задержки ;) Джаб! вообще-то трейс имеет отличный от пингового механизм получения ответного пакета. а icmp мы в РТкКОме всегда из-под шейперов выводили. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ugluck Опубликовано 14 декабря, 2008 · Жалоба <...> трейс имеет отличный от пингового механизм получения ответного пакета <...> не всегда.. сам удивился, когда узнал. оказывается, винда трассирует по icmp а цыска и линух - по udp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 14 декабря, 2008 · Жалоба ну почему нет. есть. лет пять назад в разборках доходило дело до РД номер не помню.там было обнаружено что-то типа не более 5% процентов потерь и не более 1секунды задержки ;) Оно там до сих пор такое. Можно спокойно давать 100 мегабитный анлимит, с 5% packet loss rate и 950ms delay. :-) Джаб! вообще-то трейс имеет отличный от пингового механизм получения ответного пакета.а icmp мы в РТкКОме всегда из-под шейперов выводили. Обычно невиндовый трэйс дает запрос по UDP или TCP на случайный порт, с инкрементом TTL. Ответом будет ICMP: TTL exceeded in transit. Но при большом буффере шейпера, весь этот трэйс пролетит до того, как труба начнет работать, так что это не существенно. Тут визуально будет больше ругани на DNS. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Прохожий Опубликовано 15 декабря, 2008 · Жалоба ну почему нет. есть. лет пять назад в разборках доходило дело до РД номер не помню.РД.45.128-2000 "Сети и службы передачи данных"Параметры качества там взяты с МСЭ-Т Y.1541 там было обнаружено что-то типа не более 5% процентов потерь и не более 1секунды задержки ;)Все намного круче! . Кроме того, предварительно рекомендуются следующие нормы для всех классов обслуживания, кроме «приемлемого»: - время доступа: не более 5 с; - коэффициент потери IP-пакетов: не более 1х10-3; - коэффициент ошибок в IP-пакетах: не более 1х10-4; - критерий отказа: отказом считается ситуация, при которой коэффициент потери IP-пакетов превышает 0,75. Для "приемлемого" класса ничего не нормируется, т.е. если дроп 74%, то это - нифига не отказ :) А задержка может быть любой. Нету нормативки по сути, нету, можно успокоиться. Закон на стороне провайдера ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
m.egorov Опубликовано 15 декабря, 2008 · Жалоба Да не так всё плохо: http://www.garant.ru/prime/20071030/92047.htm Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...