Ответить
  • Артёмка Senior MemberАвтор темы
    офлайн
    Артёмка Senior Member Автор темы

    22047

    23 года на сайте
    пользователь #6766

    Профиль
    Написать сообщение

    22047
    # 13 июня 2010 22:58 Редактировалось Артёмка, 64 раз(а).

    Архив.
    ************************************************

    Новый кабинет -> http://my.beltelecom.by/

    ByFly. Обсуждение. - тема-чат. Обсуждения, эмоции и тп. и тд.

    Техническая помощь пользователей пользователям ByFly. Техническая помощь. Настройка.

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

    Для тех, кто ругается на "кривые" маршруты, т.е. например почему трафик на Россию идет через Европу, рекомендую прочитать эту статью:
    Сети для самых маленьких. Часть восьмая. BGP и IP SLA

    WI-FI: неочевидные нюансы

    Файл помощи для настройки интернета byfly и телевидения zala

    Вторичные параметры линии:
    Затухание сигнала (Line Attenuation):

    до 20 dB — отличная линия
    от 20 dB до 40 dB — рабочая линия
    от 40 dB до 50 dB — возможны сбои
    от 50 dB до 60 dB — периодически пропадает синхронизация
    от 60 dB и выше — оборудование работать не будет

    Уровень шума (дБ относительно 1 мВт при сопротивлении нагрузки 600 Ом):

    от −65 dBm до −51 dBm — линия отличная
    от −50 dBm до −36 dBm — хорошая линия
    от −35 dBm до −20 dBm — работа с периодическими сбоями
    от −19 dBm и выше — работа оборудования невозможна

    Отношение сигнал/шум (Signal-to-Noise Ratio (SNR)):

    до 7 dB — плохая линия, присутствуют проблемы синхронизации
    от 7 dB до 10 dB — возможны сбои
    от 10 dB до 20 dB — хорошая линия, без проблем с синхронизацией
    от 20 dB до 29 dB — очень хорошая линия
    от 29 dB — отличная линия

    Трассировка является очень грубым способом выявления неполадок в сети, т.к. запросы до сервера могут идти одним маршрутом, а icmp запросы - другим. Может быть и так, что запрос идет по нормальному маршруту, а ответ - нет. Также ICMP часто режется или обрабатывается с наименьшим приоритетом. Трассировка не предназначена для выявления потерь пакетов, а всего лишь для показа маршрута прохождения (icmp - это пинги и трассировка).

    С википедии:
    Здесь хочется отметить, что программа работает только в направлении от источника пакетов и является весьма грубым инструментом для выявления неполадок в сети. В силу особенностей работы протоколов маршрутизации в сети Интернет, обратные маршруты часто не совпадают с прямыми, причем это справедливо для всех промежуточных узлов в трейсе. Поэтому ICMP ответ от каждого промежуточного узла может идти своим собственным маршрутом, затеряться или прийти с большой задержкой, хотя в реальности с пакетами, которые адресованы конечному узлу, этого не происходит. Кроме того, на промежуточных маршрутизаторах часто стоит ограничение числа ответов ICMP в единицу времени, что приводит к появлению ложных потерь.

    Уважаемые форумчане. Проблемы с неработающим гуглом обсуждайте пожалуйста в соответствующей ветке: Проблемы с гуглом. Спасибо за внимание.

    Куратор ветки _maksim_

    При жалобе на низкую скорость на ютубе не надо делать замеры скорости веб-сервера ютуб!!! У ютуба много кэшей в разных странах, включаете видео, запускаете снифер трафика и смотрите с какого айпи адреса идут пакеты. Его и проверяете.

    Поделись улыбкою своей - и тебе её не раз ещё припомнят...
  • 75219 Linux Team
    офлайн
    75219 Linux Team

    1767

    19 лет на сайте
    пользователь #75219

    Профиль
    Написать сообщение

    1767
    # 1 марта 2026 18:49
    dmiple:

    Я конечно не очень большой знаток DNS, но по-моему вы что-то не то делаете. Не может домен заресолвиться за 0.463 миллисекунды. Как раз 50 мс - нормальное время обращения к корневому DNS-серверу.
    А все остальные 0.5 мс - обращение к локальному кэшу.

    Согласен, но выводов в целом это не меняет. Сделал дополнительную проверку по резолвингу уникального несуществующего домена при каждом запросе:

    for server in 82.209.243.241 82.209.240.241 8.8.8.8 1.1.1.1 86.57.255.147 86.57.255.149; do
    echo "test $server"
    for i in {1..20}; do
    dig @"$server" $(date +%s%N).com +stats | grep "Query time"
    done
    done

    82.209.243.241 и 82.209.240.241 стабильно отвечает за 2-3мс
    8.8.8.8 - за 27-30мс
    1.1.1.1 - за 11-15мс
    86.57.255.147 и 86.57.255.149 примерно за 27-35
    Так что 82.209.243.241 и 82.209.240.241 на порядок быстрее отвечают чем другие сервера в моем случае. Ну и 1.1.1.1 оказался тоже весьма быстрым.

  • yuradeni Senior Member
    офлайн
    yuradeni Senior Member

    14613

    14 лет на сайте
    пользователь #406345

    Профиль
    Написать сообщение

    14613
  • dmiple Senior Member
    офлайн
    dmiple Senior Member

    1240

    11 лет на сайте
    пользователь #1212257

    Профиль
    Написать сообщение

    1240
    # 1 марта 2026 22:40
    75219:

    82.209.243.241 и 82.209.240.241 стабильно отвечает за 2-3мс

    Все равно как-то мало. До серверов только пинг 2-3 мс. А им еще нужно сходить на корневые сервера за пределы РБ.
    В любом случае почувствовать разницу в 40 мс физически невозможно и тем более она не попадает под определение "что-то интернет тормозит".

  • Vitalik8800 Senior Member
    офлайн
    Vitalik8800 Senior Member

    4291

    11 лет на сайте
    пользователь #1276205

    Профиль
    Написать сообщение

    4291
    # 1 марта 2026 22:58
    dmiple:

    А им еще нужно сходить на корневые сервера за пределы РБ.

    Что-то есть в кэше, а потом еще и роутер закеширует. Я так вообще провайдерские dns не использую.

  • dmiple Senior Member
    офлайн
    dmiple Senior Member

    1240

    11 лет на сайте
    пользователь #1212257

    Профиль
    Написать сообщение

    1240
    # 1 марта 2026 23:16
    Vitalik8800:

    Что-то есть в кэше

    Вы точно исходное сообщение на прошлой странице читали?