Перейти до

speedtest.net + ubiquiti + mikrotik


Рекомендованные сообщения

да нет, и в торренте 5 мбит, и в ютубе если смотртит тоже видно что шейпер жмёт на 5 мбит

а на спидтесте - нет( может действительно из-за пингов или потерь какихнить

Ссылка на сообщение
Поделиться на других сайтах

Спидтест измеряет скорость TCP трафиком .  Трафик торрента - может быть TCP/IP,  а чаще , если загружен канал, он автоматом переключается на  короткие пакеты UDP ( вплоть  до 100 хвостиком байт).

Если Вы поставите у клиента  за  СПЕ  в езере МТ  и протестируете Bтестом скорость между МТ в езере за базой и МТ в езере  за клиентом пакетами TCP и UDP, то можете получить разные результаты . В Вашем случае скорость на TCP и UDP трафике будет отличаться в два раза.

Причина этому - потери TCP пакетов в канале  в силу того,  что канал в Вашем случае плохого качества. Когда TCP пакеты теряются, уменьшается так называемое окно стека протоколаTCP и понижается скорость потока TCP   ( TCP /IP), что и наблюдается в Вашем случае.

Корень проблемы в оборудовании UBNT.  Очевидно, у Вас в сети либо помехи, либо NearLOS, с чем  UBNT плохо уживается. Если NearLOS, то может помочь переход в один чейн, скорость  снизится, но будет стабильней.

Відредаговано wimaxx
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Если Вы поставите у клиента  за  СПЕ  в езере МТ  и протестируете Bтестом скорость между МТ в езере за базой и МТ в езере  за клиентом пакетами TCP и UDP, то можете получить разные результаты . В Вашем случае скорость на TCP и UDP трафике будет отличаться в два раза.

 

это понятно, но я больше чем уверен если я включу МТ в езер за СПЕ то я получу свои 5мбит в tcp

 

я уже думал может внешнии провайдеры мои и УТК имеют доступ на разной скорости к конкретному спидтест-серверу

Відредаговано SuperSonic
Ссылка на сообщение
Поделиться на других сайтах

 

Если Вы поставите у клиента  за  СПЕ  в езере МТ  и протестируете Bтестом скорость между МТ в езере за базой и МТ в езере  за клиентом пакетами TCP и UDP, то можете получить разные результаты . В Вашем случае скорость на TCP и UDP трафике будет отличаться в два раза.

 

это понятно, но я больше чем уверен если я включу МТ в езер за СПЕ то я получу свои 5мбит в tcp

 

я уже думал может внешнии провайдеры мои и УТК имеют доступ на разной скорости к конкретному спидтест-серверу

 

Возможно TCP пакеты теряются дальше за базой. Проверьте тестами TCP. Но то что проблема именно в этом -90%,  вопрос только где проблема, скорее всего - в Вашей сети.

Ссылка на сообщение
Поделиться на других сайтах

На мт порты гигабитные? Если да - попробуйте поменять дефолтную очередь на интерфейсах wan и lan на pcq с размером 2000

 

спасибо попробую, там 2 рб 433 со 100 мбит портами и 1 рб800 с гигабитными

щас стоит only-hardware-queue, Kind: none на всех

Ссылка на сообщение
Поделиться на других сайтах

элементарная команда пинг мне не поможет в этом?

Пинг каk не поможет понять в чем есть проблема. Поможет FTP сессия ( TCP/IP) либо прямой TCP тест. И вообще у Вас же на многих линках (судя по вашим постам здесь на форуме) есть проблема с заниженными показаниями скорости на TCP . Поэтому у Вас удобный случай ( за базой есть установленный МТ) проверить в чем проблема.Поставтьте за клиентом МТ и протестируйте UDP и TCP. Если есть разница - значит дело в потерях TCP.  

Відредаговано wimaxx
Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

и в чём же принципиальная разница ограничения на антенне а на мтике?

 

элементарная команда пинг мне не поможет в этом?

 вообще у Вас же на многих линках (судя по вашим постам здесь на форуме) есть проблема с заниженными показаниями скорости на TCP . Поэтому у Вас удобный случай ( за базой есть установленный МТ) проверить в чем проблема.Поставтьте за клиентом МТ и протестируйте UDP и TCP. Если есть разница - значит дело в потерях TCP.  

 

 

ну там где были проблемы там вроде порешал, при сигнале -60 на 16км и ccq 90-95% получил 120 мбит тсп в одну сторону, это мало?

Ссылка на сообщение
Поделиться на других сайтах

 

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

и в чём же принципиальная разница ограничения на антенне а на мтике?

 

элементарная команда пинг мне не поможет в этом?

 вообще у Вас же на многих линках (судя по вашим постам здесь на форуме) есть проблема с заниженными показаниями скорости на TCP . Поэтому у Вас удобный случай ( за базой есть установленный МТ) проверить в чем проблема.Поставтьте за клиентом МТ и протестируйте UDP и TCP. Если есть разница - значит дело в потерях TCP.  

 

 

ну там где были проблемы там вроде порешал, при сигнале -60 на 16км и ccq 90-95% получил 120 мбит тсп в одну сторону, это мало?

 

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

Відредаговано Gotsa
Ссылка на сообщение
Поделиться на других сайтах

 

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

и в чём же принципиальная разница ограничения на антенне а на мтике?

 

элементарная команда пинг мне не поможет в этом?

 вообще у Вас же на многих линках (судя по вашим постам здесь на форуме) есть проблема с заниженными показаниями скорости на TCP . Поэтому у Вас удобный случай ( за базой есть установленный МТ) проверить в чем проблема.Поставтьте за клиентом МТ и протестируйте UDP и TCP. Если есть разница - значит дело в потерях TCP.  

 

 

ну там где были проблемы там вроде порешал, при сигнале -60 на 16км и ccq 90-95% получил 120 мбит тсп в одну сторону, это мало?

 

Для ubnt может и нормально. Но тут главное разница между результатами тестов на UDP и TCP. Если есть значительная разница ( скажем больше 10-15%), то есть потери TCP пакетов и скорость на реальном трафике будет значительно ниже, чем в тестах.    

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

 

Для ubnt может и нормально. Но тут главное разница между результатами тестов на UDP и TCP. Если есть значительная разница ( скажем больше 10-15%), то есть потери TCP пакетов и скорость на реальном трафике будет значительно ниже, чем в тестах.    

 

 

 

микротик это, разница есть 120 в tcp, и 180 в udp, но проблема как минимум может заключаться в процесорре микротика, а именно в генерации тсп пакетов а потом уже в самом радио-канале

Відредаговано SuperSonic
Ссылка на сообщение
Поделиться на других сайтах

 

 

Для ubnt может и нормально. Но тут главное разница между результатами тестов на UDP и TCP. Если есть значительная разница ( скажем больше 10-15%), то есть потери TCP пакетов и скорость на реальном трафике будет значительно ниже, чем в тестах.    

 

 

 

микротик это, разница есть 120 в tcp, и 180 в udp, но проблема как минимум может заключаться в процесорре микротика, а именно в генерации тсп пакетов а потом уже в самом радио-канале

 

Перегруз проца может влиять на генерацию трафика-так посмотрите загрузку CPU и отключите  при тестах опцию random.

Разница 120М TCP и 160М UDP говорит о ненадежности канала. На реальном трафике TCP/IP пропускная способность канала будет не выше 120мбит/с. И если запустить спидтест, то он тоже покажет не выше 120 Мбит/c.

Ссылка на сообщение
Поделиться на других сайтах

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

 

 

Client Isolation не помогает ?)

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

×
×
  • Створити нове...