Объявление

Свернуть
Пока нет объявлений.

Встроенный тест врет?

Свернуть
X
 
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

    Встроенный тест врет?

    Сообщение от unicorp99 Посмотреть сообщение
    Доверяем измерять скорость по встроенному тесту, который врёт как историки, потом удивляемся, почему убивают на украине...
    Уважаемые, поясните, будьте добры, что именно меряет встроенный в AirOS тест? Абсолютно бесполезен и вреден, или все-таки для чего-то пригоден?

    Как я понимаю, вера в сабдж - типичные новичковые грабли..
    Последний раз редактировалось chukcha; 09.07.2014, 17:08.

    #2
    Сообщение от chukcha Посмотреть сообщение
    Уважаемые, поясните, будьте добры, что именно меряет встроенный в AirOS тест? Абсолютно бесполезен и вреден, или все-таки для чего-то пригоден?

    Как я понимаю, вера в сабдж - типичные новичковые грабли..
    Отличный вопрос!

    Тест меряет видимо скорость прокачки минус загрузку процессора именно на этот тест (для старых устройств разница существенна)

    На NS2 после теста прокачано в эфире:
    Test Results
    Rx: 13.23 Mbps (тут обозначение Mbps не относится ни к WiFi - ибо безбочно врёт, может быть это всё же Mbit/sec - но мало) Так что нужно понимать этот показатель за условный..
    Tx: 13.12 Mbps
    По статистике WiFi - приём 24Mbyte данных и 20000 пакетов
    передача 17Mbyte и 19000 пакетов - пакеты около килобайта?

    На сети ethernet 100 Mbit/sec (не в эфире WiFi) тест между двумя NS2 показал скорость
    Rx: 27.32 Mbps
    Tx: 24.59 Mbps
    Что можно трактовать как намного более высокая загрузка проца и есс-но более сильные потери прокачки - примерно 100 Mbit/s /4 = 24, а на 54 Mbps это примерно 27Mbit/s /2 = 13
    так как 4 сильно отличается от 2 - в формуле зависимости будет Экспонента, да и ну её нафиг..

    ---

    Отношение скорости в эфире (допустим 54Mbps WiFi) к максимальной прокачке на этой скорости - это отношение примерно два к одному и меньше - то бишь через 54Mbps символьной скорости Wifi эфира можно прокачать около 27Mbit/s траффика ethernet (в одну сторону)
    Нужно понимать, что по протоколу передачи файлов между виндовыми компьютерами smb (самба) можно прокачать максимально 2.5 Mbyte/sec - это 2.5*8= 20Mbit/s плюс 1MBit/s обратно, и в эфире полудуплекс, и займётся 27 Mbit/s - умножаем на два примерно 54Mbps WiFi
    На самом деле временные процессы сложнее и часть времени тратится на ожидание передачи..

    -----

    Назревает вопрос: Чем правильно и однозначно мерять?

    В разных случаях по-разному. Кому-то достаточно будет speedtest.net - минусы - нужно иметь купленную скорость с нета больше скорости линка для непосредственно измерения (а так только станет ясно - падает скорость или нет, если выше то не ясно)
    Кто-то запустит торрент и замеряет скорость закачки во много потоков популярного фильма с инета..
    Кому-то нужно два виндовых компа с расшаренными папками и через тотал коммандер покажет скорость передачи файлов по сети. (Но этож надо минимум ДВА компа..) И два новых компа через линк 1Gbit/s покажут 60 Mbyte/s - а два старых 13 Mbyte/s (загрузка проца!)
    Программа для прошивки 5210G в NanoStation 2 - http://wa5210g.blogspot.com
    Предупреждение: По всем коммерческим вопросам - только личка

    Комментарий


      #3
      Благодарю от лица народов Камчатки!
      Предлагаю прилепить или включить в ФАК.

      Комментарий


        #4
        Если б тест действительно мерял.... он измеряет скорость на стандартных пакетах, отсюда такая нелюбовь к торренту у эфирных провайдеров.

        Комментарий


          #5
          А в чем нестандартность пакетов торрента, и как связана с нелюбовью радио-провайдеров?

          Комментарий


            #6
            Сообщение от chukcha Посмотреть сообщение
            А в чем нестандартность пакетов торрента, и как связана с нелюбовью радио-провайдеров?
            При передаче торрента много мелких пакетов подтверждения передачи..

            Так как в эфире достаточно большое время молчания перед передачей каждого пакета, то когда идёт скачивание торрента - то намного большее количество мелких пакетов занимает намного большее время в эфире, падает прокачка, поэтому для передачи множества мелких пакетов нужно что-то типа агрегации.

            Как агрегация в старших моделях Ubiquiti M2 и M5 помогает - вопрос. Я видел статью, где описывалось применение агрегация на роутерах микротик, с которой не справлялся мост из двух Ubiquiti, скорость прокачки без агрегации? (или с агрегацией Ubiquiti) была намного меньше, чем с агрегацией микротик.. Что было важно для провайдера и потока в 100Mbit/s full-duplex

            http://www.lanmart.ru/blogs/test-ubi...anostation-m6/ - вроде Ubiquiti на свежей прошивке..

            Как грица, в статье всё со скринами, но в дупель не вкуривается, что именно в родной агрегации Ubiquiti не то и не так?

            Может хто прояснит сей вопрос?
            Программа для прошивки 5210G в NanoStation 2 - http://wa5210g.blogspot.com
            Предупреждение: По всем коммерческим вопросам - только личка

            Комментарий


              #7
              Несколько не так, торрент используют UDP пакеты, это в обычных условиях пакет без подтверждения, торрент собирает эти пакеты... склеивает, проверяет контрольную сумму, если сумма не соответствует, то куча пакетов передаётся снова, вроде как всё на стандартном IP протоколе... только одно но.... UDP пакеты идут вне очереди, просто изначально UDP под телефонию затачивался, пропала пара пакетов... ну хрюкнула трубка... мозг восстанавливает без проблем.
              WI-FI по своей сути обязан подтверждать каждый переданный пакет, а торрент чтоб быстрей просочится мелкими пакетами долбит.
              Выход из этой ситуации только один, либо радиоканал использовать такой который умеет мелкие пакеты клеить, либо перед радиоканалом ставить оборудование которое это делает .
              Как то так.... на пальцах Впрочем у Чапаева на кортохах наглядней получалось.

              Комментарий


                #8
                Имхо уважаемый arcad не вполне прав.

                "Изначально UDP под телефонию затачивался" -- имхо, некорректно. Сейчас -- да, широко применяется для телефонии, но не только для нее.


                "UDP пакеты идут вне очереди" -- имхо, некорректно. Есть приоритеты и типы сервисов, но это другая песня. Немаркированный пакет UDP перед пакетами других протоколов обычно приоритета не имеет.

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

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

                Да, и уже обсуждаем совсем другой вопрос, хотя не менее интересный. Предлагаю тему поделить.

                Комментарий


                  #9
                  [QUOTE=chukcha;114384]Имхо уважаемый arcad не вполне прав.

                  Тогда представте своё своё виденье.... почему разработчики торрента использовали именно UDP протокол.

                  P.S. учтите я древний как дерьмо мамонта, и помню что такое ONC RPC и что такое NFS , что такое уровни... "прикладной", "дейтаграммный","интернет","сетевой интерфейс"

                  Комментарий


                    #10
                    Сообщение от chukcha Посмотреть сообщение
                    Уважаемые, поясните, будьте добры, что именно меряет встроенный в AirOS тест? Абсолютно бесполезен и вреден, или все-таки для чего-то пригоден?

                    Как я понимаю, вера в сабдж - типичные новичковые грабли..
                    Встроенный тест меряет канальную скорость, ту, на которую договорились оба устройства. Остальные проверки, типа закачать фильм в N гб за N секунд и значит скорость такая то и т.д. это уже бред. Есть накладные расходы других уровней, всякие инкапсуляции и т.д. У Винды если память не изменяет около 20-30 процентов, но опять же, какие данные будете тягать, если голос или торрент, скорость будет меньше из-за количества передаваемых пакетов.
                    Я меряю скорость iperf`ом, по udp. Будут более-менее приближенные данные к реалиям использования и восприятию обычного мозга, который знаком с сетевыми технологиями поверхностно.

                    Комментарий


                      #11
                      Вообще-то изначально Torrent использовал TCP. Переход на UDP происходил в 2008-2009 годах.

                      Глубоко я не копал, найдя минимум две причины перехода на UDP, которых лично мне хватило бы; но, возможно, есть и еще.

                      (1) UDP позволяет связывать два торрент-клиента, оба находящихся за NATами, с помощью UDP hole punching; с TCP этот фокус в норме не проходит.

                      (2) TCP использует несовершенный congestion protocol, основанный на потерях пакетов. Разработчики BitTorrent написали свой протокол uTP, работающий поверх UDP. uTP регулирует скорость передачи на основании времени передачи пакетов, а не факта их потери. Это улучшает как пропускную способность собственно торрент-протокола по сравнению с TCP-версией, так и совместное использование канала с другими видами трафика (от других приложений).

                      Ссылки:
                      http://www.dslreports.com/shownews/U...nterwebs-99400
                      http://arstechnica.com/uncategorized...-isnt-falling/

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

                      Комментарий


                        #12
                        Сообщение от KpblcuK Посмотреть сообщение
                        Я меряю скорость iperf`ом, по udp.
                        А iperf прямо на точках запускаете, или на хостах за ними?

                        Комментарий


                          #13
                          Сообщение от chukcha Посмотреть сообщение
                          А iperf прямо на точках запускаете, или на хостах за ними?
                          В аирконтроле сделали возможность мерять непосредственно iperfом. На точках даже и не заморачивался смотреть, есть ли он. Всегда меряю на хостах за ними, ставлю же не только точки доступа но и совсем разное железо.

                          Комментарий


                            #14
                            KpblcuK, а чисто из академического интереса не можете сравнить на нескольких линках показания iperf и встроенного в AirOS теста?

                            Комментарий


                              #15
                              Сообщение от chukcha Посмотреть сообщение
                              KpblcuK, а чисто из академического интереса не можете сравнить на нескольких линках показания iperf и встроенного в AirOS теста?
                              В данный момент к сожалению нет, на больничном, через несколько дней смогу. Скажите какие протоколы, нагрузку, или стандартно?

                              Комментарий

                              Обработка...
                              X