atshellnick

Спасибо!

Ктсати, а как самому клиенту speedtest.net mini который, указать чтобы он использовал этот OoklaServer? Или это не про него?

Че-то не успел скачать. Можно повторить раздачу? =) Хорошо бы на html5 более менее приличный найти. Я заметил на флэшовой версии Oakla на слабых машиных скорость показаний существенно зависит от загрузки CPU клиентской машины и даже от размера самого апплета на экране. Интересно сам этот Окл собирается что-то релизить на html5.

Спасибо за отклики! А на HTML5 не приходилось встречать что-нибудь?

А клиент не будет ругаться на обновления?

Добрый день/вечер! Хочу встроить апплет с тестом скорости, но только не speedtest.net - он задолбал обновлениями. Никто не знает приличных аналогов?

Со всех братских народов рассматриваем.

Хорошо. По просьбе трудящихся исправляю допущенные ошибки - ЗП от 60.000 до 100.000, т.е.по итогам собеседования. Сеть очень простая. Кол-во узлов не более 30-ти. Ключевых менее 10-ти. Вендоры: Cisco, Dlink, Eltex, Mikrotik. Таскать виланы пачками нет необходимости. Талантливый следует воспринимать - перспективный. Готовый расти вместе с компанией. За которым не надо бегать с вопросами: это было сделано? или когда это сделаем? или почему это нельзя сделать? Нужен человек нацеленный на результат.

Разыскивается талантливый сетевой инженер в небольшую, развивающуюся телеком. компанию. Основные функциональные обязанности: • обслуживание сети передачи данных; • сопровождение основных услуг - телефония, интернет; • запуск IPTV; Требования к кандидату: • высшее образование; • наличие опыта работы от 5 лет; • наличие сертификатов или реализованных проектов; Условия: • Трудоустройство согласно ТК РФ. • Карьерный рост. • Заработная плата: по итогам собеседования. • Компенсация мобильной связи и транспортных расходов. • Наличие необходимого для работы оборудования. • Дружный коллектив. • Офис в тихом переулке, в центре Москвы. • Компания открыта для развития различного рода перспективных проектов. Тип занятости • Рабочее время с (9)10 до (18)19 часов. 5 дней в неделю. e-mail: av@nwtel.ru

культурно! зарегался и попросил себе такой сенсор. посмотрим насколько жизненно.

Да мне больше не для фетишизма а для исследований и проверок. За argus - спасибо - попробую!

Цель не мониторинг внешних ресурсов (хотя как смотреть на это дело). Цель смотреть за тем как они видны со своей сети для обнаружения проблем у себя и у других. Речь как раз о вспомогательных данных, на которые можно ориентироваться. Например если пользователь сообщил - у меня лагает. Мы говорим - ОК, начинаем разбираться - смотрим текущие данные телеметрии свичей/роутеров/брасов - ошибки на портах, графы загрузки аплинков/процессоров/памяти/таблиц трансляций и прочих интересных моментов. Но ничего не находим, далее смотрим на то как видел "интернет" наш сенсор-резидент с узла до заявки пользователя и после заявки пользователя - пытаемся понять как коррелирует. Думаю полезно при поиске проблем ранее не известных, либо исскуственно созданных своими кривыми/шаловливыми руками. Набрав за пару месяцев данные наблюдения за внешними целями можно уже делать некие выводы о том, как ведут себя внешние цели. Если например у 6-7 целей расположенных на разных материках были одинаковые отколнения от средней условной нормы, то можно уже что-то предполагать. Кроме этого, иногда народ жалуется на конкретные ресурсы. Также, есть возможность разместить такие сенсоры у "дружественных" сетей и сопоставлять свои данные с ними. Идеи были такие (не берусь отстаивать плюсы и минусы): 1. Заббикс агент. 2. Найти что-то что анализирует нетфлоу и выборочно копать данные оттуда. 3. D-ITG PS: интересно также оценить стабильность внешних ресурсов и их видимость со своей сети при своих аплинках (вообщем из своей деревни). Примерные цели. 1. Ближайший Google Cache у апстрима. 2. CDN Akamai 3. Yandex 4. Mail.ru 5. VK.COM 6. Одноклассники 7. Транзитные задержки между узлами связи: Москва, Германия, Голладния, Лондон, Нью-Йорк и т.д. А при том что ответ на вопрос "пачиму у меня саед ццц.порно.кг лагаед" лежит в большинстве случаев то за пределами конечного оператора. Если порты не в полке, цпу на роутерах/брасах (если они софтовые) не в полке, то исправлять и нечего. "Последнюю милю" еще надо уметь сделать плохо (речь об архитектуре а не о плохо обжатом кабеле). Ну тогда надо дождаться ТС и узнать, что он имел ввиду

Добрый день! Кто знает, подскажите пожалуйста практику измерения качества доступа в интернет. Нужен некий системный подход + решение, позволяющее выборчно отслеживать качество доступа в сеть Интернет с узлов сети оператора на заранее выбранные цели. Понятно, что интернет это best effort и выбранные цели могут давать не гарантированные показатели во времени. Но все же такой подход способен дать данные для некоторых выводов. Первое что приходит в голову, это взять openwrt установить его на SOHO роутер, а сам роутер разместить на узле. Но тут встает вопрос выбора/поиска ПО и параметров за хочется наблюдать. Среди таких параметров, на которые можно оперется, думаются такие - время отклика на HTTP запрос от крупных серверов, скачивание файла с паблик FTP, возможно еще ICMP echo.

Поставщиков чего? Каких услуг? Если услуг МгМн-связи, то вы как оператор местной телефонной связи не имеете права самостоятельно разруливать направления вызовов типа "на Москву - через Ростелеком, а на Питер - через МТТ" (направления и операторы приведены условно). Вы обязаны пропустить трафик на того оператора, которого выбрал абонент preselect-ом или hotchoice-ом (тут уж как в договоре прописано). Ну и а если все же речь о voip-е, то там все по-другому. Вы уж определитесь о чем речь. Ну вот например БИЛАЙН и РОСТЕЛЕК - как знатные войперы =) присылают обновление почти каждый месяц и каждый в разных форматах.

вот насчет того что она прокоммутирует двойной тег как классический 802.1q по S-VLAN я почти не сомневаюсь. мне нужно именно собирать и разбирать кадры прямо на порту, а именно добавить и удалить, т.е. у меня например порт в транке на него скинут VLAN ID 5, на встречном свиче такая же настройка. Теперь я беру VLAN ID 5 добавляю к нему второй тег скажем 15 и отправляю его на встречный коммутатор как S-VLAN ID = 5, C-VLAN ID=15, TPID ставлю 8100, чтобы не смущать встречный свич и далее он мне делает транзит такого кадра на удаленную сторону, где я также разбираю и собираю двойной тег. спасибо, мне кажется так и есть. я просто очень слабо разбираюсь в фичах циски - из всего что я нашел как раз терминация вроде как подходила под эту задачу, насколько я понял она вроде как поддерживается только на ES сериях.