Скорость передачи данных, заявленная в описаниях тарифов интернет-провайдеров, редко соответствует реальности. Агентство iKS-Consulting опубликовало результаты исследования скорости домашнего широкополосного доступа в Интернет, предоставляемого крупнейшими операторами Москвы. По данным аналитиков, потери в скорости варьируются от 6% до 18% от заявленной в тарифе.
Эксперты сделали акцент на соответствии реальной скорости доступа заявленной в тарифных планах. Исследовалась скорость доступа, предоставляемого пятеркой крупнейших интернет-провайдеров. Скорость доступа измерялась в пиковые часы нагрузки для абонентов безлимитных тарифных планов крупнейших столичных провайдеров в различных районах города.
В целом результаты всех тестируемых операторов оказались на довольно высоком уровне. В среднем по пяти лидерам рынка скорость домашнего широкополосного доступа составила 88% от предусмотренной тарифным планом.
При этом данный показатель не зависит от тарифного плана.
Наиболее хороший показатель соответствия фактической скорости скорости, заявленной в описании тарифа – у универсального оператора связи «Корбина Телеком» (94%). Далее идет оператор «Комкор ТВ» со своим брендом «Акадо», показавший результат в 92%.
Бренд «дочки» Центрального телеграфа ЗАО «Центел» QWERTY показал 86% от заявленной скорости. Такой же показатель у холдинга NetByNet (86%). Соответствие скорости услуг «Комстар Директа» (торговая марка «Стрим») оказалась на уровне 82%.
Участники рынка ставят под сомнение методику проведения исследования. В пресс-службе Центрального телеграфа газете ВЗГЛЯД отметили, что не согласны с приведенными результатами замеров, так как «методика проведения данного тестирования остается неясной».
«Для того чтобы получить объективные оценки соответствия скорости доступа в Интернет на сетях различных операторов, необходимо, чтобы равное количество респондентов, использующих тарифные планы с равными скоростями доступа, проводя замер, обращались к одному и тому же независимому ресурсу в одно и то же время», – говорят в компании.
Кроме того, по словам представителей «Центела», провайдер, предоставляющий услуги доступа, ответственен лишь за обеспечение соответствующей скорости доступа на участке от «абонента до шлюза, на котором заканчивается его зона ответственности и начинается сеть другого оператора».
По словам представителя Центрального телеграфа, скорость доступа в Интернет в сетях QWERTY и к локальным ресурсам сети предоставляется в соответствии со скоростью, заявленной в тарифном плане, при этом все возможные отклонения не связаны с работой сети. Однако тот факт, что потеря скорости происходит в основном вне сети операторов, отмечается и в самом отчете агентства. Также аналитики зафиксировали, что в отдельных случаях реальная скорость иногда превышала скорость, обещанную тарифом, это наблюдалось, например, в сетях «Стрим», «Корбина» и QWERTY.
Таким образом, операторы предоставляют пользователям каналы с немного большей пропускной способностью, чем указано в тарифных планах.
В целом, по оценке iKS-Consulting, реальная скорость широкополосного доступа в Москве вполне удовлетворительна, при этом обещанная скорость обеспечивается вне зависимости от тарифного плана, выбранного абонентом. Отклонения от скорости, заявленной в тарифном плане, «в большинстве случаев не связаны напрямую с сетью провайдера».
Имхо подтверждаю: среднее время скачки на Open.128 меньше на 12%, т.е. составляет 14 КБайт/Сек.
Все правильно ... вам выделяют _канал_ 128 Килобит ... те гарантируют передачу сырых данных на канальном уровне (PPP over Ethernet) со скоростью 16 килобайт в секунду ... к примеру при скачке с WEB сайта по протоколу TCP
сырые данные = (заголовок IP (заголовок TCP (реальные данные)))
а все 'качалки' показывают скорость скачивания _рельных данных_ без учета избыточной инкапсуляции протокола IP ... поэтому то и скорость скачивания всегда меньше скорости канала ...
кстати на Open.64 тоже скорость в среднем 7,4 килобайт в секунду ...
Сообщение отредактировал DiGGeR - Feb 27 2007, 10:30
!dx, тем не менее - предоставляется канал - а уж какой там протокол обмена - сугубоинтимное дело клиента. Ещё бы про HTTP-хидеры вспомнили...
Цитата(!dx)
у других то провайдеров Уверенно держит 16Кбайт
Ну давай ещё вспомним, что у некоторых провайдеров в килобайте 1000 байт, а заявленная скорость определяет сумму входящей и исходящей скорости. Нету, блин, никаких нормативных документов, где было бы расписано, что и как должно считаться с точки зрения закона (найдёшь - покажи - самому интересно) - иначе можно было бы по судам затаскать.
сырые данные = (заголовок IP (заголовок TCP (заголовок HTTP(реальные данные))))
не совсем правильно ... при передаче файла HTTP заголовок (порядка 300-500 байт) добавляется только один раз в начале, а не в каждый пакет ... далее данные файла идут в чистом виде ... К примеру при MTU=1480 байт принимаемые данные будут так кодироваться:
(при размере файла в 50 кб влияние HTTP заголовка на скорость передачи менее 1% а при мегабайте можно вообще не учитывать ) а вот IP+TCP отъедает постоянно по 40 байт те ~2,7% входяшего траффика
И вы в самом деле верите, что мегабайтный поток данных посылается вслед за одним HTTP-заголовком ? Сказки это ... Файл разбивается на куски и кусками Вам отсылается ...
И вы в самом деле верите, что мегабайтный поток данных посылается вслед за одним HTTP-заголовком ? Сказки это ... Файл разбивается на куски и кусками Вам отсылается ...
Ну если качать всякими там FleshGet-ами в несколько потоков тогда файл и будет отсылатся кусками тк сама качалка этого будет требовать от сервера через Range: bytes xxxx-yyyy в GET запросе ... и в каждый кусок добавится свой 'HTTP/1.1 206 Partial content' заголовок с указанием размера куска файла в Content-Range: bytes xxxx-yyyy/zzzz те получается многопоточная скачка наоборот отъедает траффик лишними HTTP заголовками
а при обычном скачивании файла (c начала до конца) в один поток сервер дает обычный ответ 'HTTP/1.1 200 OK' и файл будет передаватся одним куском