Здравствуйте. Задался вопросом, почему по кабелю при заявленом тарифе 100, в спидтест выдает скорость не выше 95.
Почему данная особенность пропадает при наличии гигового порта со стороны провайдера, линии в 8мь жил и гигового роутера? Чем это вообще обусловлено? И опять же, почему при несоблюдении одного из трёх пунктов, скорость упирается в 95?
Почему-то толкового ответа на данный вопрос в инете найти не получается. Хотя бы дайте подсказку, куда смотреть, чтобы понять причину происходящего.
как тестировал скорость? до какого сервера speedtest? это сервер твоего провайдера? при тестировании 100мб и 1000мб тарифа оборудование оставалось то же самое?
rPman, условия одинаковые. Вопрос именно в том, что физически скорость упирается в 95, если что-то не соответствует условию: Гиговый порт провайдера, линия 8мь жил + гиговый роутер.
Совпадают все 3, скорость 100 при тарифе 100. И опять же, не совпадает что-то одно - потолок в 95.
У меня по вай-фаю спидтест показывает 525/511 при тарифе 500Мб/c
А вам просто провайдер не отдает 100 (что вообще-то странно, т.к. провайдеры специально именно для спидтест профилируют трафик чтобы не подкопаться).
В идеальных условиях на 100 мегабитах мне не удавалось получить более 11.8 мегабайт в секунду интегральной передачи, что соответствует 94.4 мегабита трансфера данных, остальное съедают служебные биты в канале передачи.
А вот если порт гигабитный, а ограничение установлено шейпингом канала, то эти служебные биты не откусывают от заявленных 100, а проскакивают в остатке пропускной способности канала, то есть в оставшихся не у дел 900 мегабитах.
Погрешность тестирования.
Потери на служебный трафик.
Это нормально.
Так и должно быть.
100 мегабитный канал никогда не даст 100 мегабит полезного трафика.
Так же как и 1000 мегабитный никогда не даст ровно 1000, часть уйдет на служебный трафик и потери пакетов.
А вот из 1000 сделать или 100 или 200 или 500 полезных легко, есть пространство для служебных пакетов.
Скорее всего так делает провайдер. в Казахстане есть такой оператор Beeline, 100 мбит тоже дают, по факту 90-95 максимум по проводу(4 жилы в квартиру заходит), ТП всегда отвечает и у вас до 100 мбит. Перешел на другого оператора где до 500 мбит оптика, теперь скорость как заявляют 500, бывает даже 510 по проводу.
Refguser, в любом случае, нельзя так людей смешить! Еле до кухни добрался... Петровский, Т. е. когда ping пишет, что потеряно n пакетов, их надо в воздухе искать или где там, куда тепло ушло?
Основная причина нагрева проводов и кабелей – природные свойства электрического тока. Движение заряженных электронов по проводу происходит под воздействием электрического поля. К тому же, движение электронов характеризуется необходимостью преодолеть кристаллическую решетку используемых металлов.
И ни в какое тепло эти 5% не переходят (на Земле по крайней мере, а то вы похоже на Марсе живёте, где линуксы на ноуты не ставятся)
когда у вас жёсткий греется, данные с него тоже в тепло переходят что ли?
Вы будете смеяться, но таки да - правда, хотя и с точностью до наоборот. Это тепло переходит в данные - правда, в данные совершенно случайные по причине абсолютной хаотичности и непредсказуемости направлений движения отдельных кусочков тепла. Если взять пластину диска с данными и положить её на хранение - то когда-нибудь она перейдёт в состояние абсолютного армагеддона данных. И чем выше температура пластины, тем раньше это произойдёт. Ну а поскольку действие равно противодействию, можно говорить, что это данные переходят в тепло - беды большой не будет.
Петровский, Как ответивший на вопрос про подсветку у Synaptic в линуксе, дополню в контексте этого диалога: то, что реализовали они эту фичу в "драйвере" для Windows, на самом деле работает в виде службы. Исторически свои драйвера они дорабатывают по принципу "лебедь раком щуку" в обеих ОС, так что возможно они и сами когда-нибудь реализуют подобный функционал (за историей я слежу т.к. вопрос Как переключать рабочие столы Windows 10 тачпадом? породил ответ и здесь, и на Stack Overflow).
chupasaurus, между "службой" и "модулем ядра" есть принципиальная разница: служба будет работать и на Windows 7, и на Windows 11.000001, и на Windows 11.000006.
То, что работает на Windows "в драйвере", является мостом (видимо, с двумя участниками) между юзерлендом и кернеллендом. Написать это производителю под Windows "просто" и единожды, написать это производителю под Linux нереально
Видимо, именно поэтому и "служба", что она запускается с привилегиями, необходимыми для того, чтобы и передавать данные драйверу, и получать события от оборудования. Под Linux такой фантастики и представить себе нельзя
> они и сами когда-нибудь реализуют подобный функционал
функционала, который необходимо реализовать, слишком много, и он не будет реализован никогда, за весь срок жизни потребительского оборудования. фактически, нужно реализовать демон huawei_daemon с драйверами, которые будут работать вместе и передавать в нужных направлениях события оборудования, по-разному их обрабатывать и передавать разным драйверам
> на самом деле работает в виде службы
удивительно, как вы манипулируете
Петровский, Т. е. когда ping пишет, что потеряно n пакетов, их надо в воздухе искать или где там, куда тепло ушло?
Ну частично то точно в тепло уходят, хех
Оно, впрочем, и без потерь в конечном итоге в тепло уходит. Электроника наша вообще преимущественно нагревательные приборы, кпд прямого их функционала довольно низкий
Oleg, по оптике физически всё равно потолок 1 Гб/с за минусом техно трафика 2-5%, а шейпером режут до 500 посему и нет разницы,
на 100 Мб/с упираешься в физический потолок интерфейса с теми же 2-5% технотрафика. и плевать на шейпер.
Если мы говорим о 4 жилах - то говорим о скорости по ethernet 100 мегабит.
По ethetnet информация передаётся в пакетах. В пакете есть информация от кого, кому и прочие поля. Это и называют служебной информацией.
Так-же и с пакетами tcp и udp, которые упаковываются в ethernet пакеты.
У ip пакетов тоже есть "служебные" поля)данные (от кого пакет, кому пакет, порт назначения, порт получателя,контрольная сумма)
А есть http , который упаковывается в ip , который упаковывается в ethernet. И там так-же есть заголовок, теги и прочая "служебная" информация.
Если замерять скорость ethernet , то она будет соответствовать 100 мегабитам.
Потому что 100 мегабит у вас на канальном уровне. С учётом размера заголовков пакетов и прочих технических накладных расходов в 100мб линк как раз можно впихнуть в районе 94-95мб реальной полезной нагрузки
И всё же, КМК, простейшие и чаще всего применяемые спидтесты показывают не одну только полезную нагрузку, а весь трафик (в т.ч. и служебный) - это проще сосчитать.
А что касается разницы 100/95 - дык ведь наполнение Сети рандомное. Это примерно как с погодой: допустим, прогноз утверждает, что скорость ветра 5 м/сек, а стрелка анемометра болтается от 4 до 6, а то даже меняется от затишья 1...2 до порывов 7...10 и наоборот.
wrstnwrld, можно почитать протоколы TCP, IP(IPv4), Ethernet для общего понятия их работы.
посмотреть каков номинальный размер MSS/MTU и сколько заголовков на TCP сегмент навешиваются при передаче их до физического уровня.
и тогда можно определить какой процент канала отбирают технические данные :)
но это для скорости TCP канала.
плюс задержки провайдеров, сетей, межсетевых переходов и т.д.
согласен что показывает спидтест еще не известно, там еще куча гиганстких HTTP заголовков может влезать :)
к примеру вот некоторые наглядные теор.выкладки процент технических данных при разных размерах пакетов
имхо "более правильные" данные даст iperf3 он проще/ниже.
wrstnwrld, Заголовки и "пр" входят в измеряемую скорость (технические же затраты ничтожны и не влияют на скорость от слова "совсем"). А вот чем ЕЩЁ занят канал - это в браузере не померяешь. Но можно померять на порту сетевой карты.
Кроме того - обещать не значит жениться. Это я про провайдера. Читай ответ Drno.
Refguser, неправда. Спидтест заголовки не учитывает. На стамегабитном линке он вот прям вообще никак не может показать больше 95мб/сек. Только если из-за тормознутости ПК анимация заглючит. Проверено не одной сотней тестов всегда с одним результатом: на соточном линке с ОТКЛЮЧЕННЫМ шейпингом 94-95Мб/сек, на гиговом линке с шейпером на 100 - 100Мб/сек, как в аптеке
ElxkoT, правда. И она в том что заголовки бывают разные. Спидест учитывает ВСЁ, что идёт в http. Включая http-заголовки. А технические заголовки (между роутелром и устройством например) он конечно не видит, но они ничтожно малы и не влияют на показания.
на соточном линке с ОТКЛЮЧЕННЫМ шейпингом 94-95Мб/сек, на гиговом линке с шейпером на 100 - 100Мб/сек, как в аптеке
Refguser, понял. Ethernet + IP + TCP заголовки, кстати, как раз в идеальных условиях занимают 5%, а при меньшем размере пакета и того больше.
Значит это то, что значит: Speedtest ничего не знает про технологию подключения клиента и не учитывает её особенностей. Так лёгким движением руки 100 по Ethernet и превращаются в 95, а 72 По WI-FI N 1x1 20 МГц в 45 - там размер полезной нагрузки ещё меньше.
Проверить всё элементарно: на одном и том же ПК через один и тот же роутер с одним и тем же гигабитным аплинком и тарифом в 100 провести тест вначале подключив ПК с линком в автоматическом режиме, потом повторить, указав в настройках сетевой карты принудительно режим 100/FullDuplex - результат внезапно будет полностью идентичен тому, о чем спрашивает автор вопроса, и будет повторяться со 100% точностью.
В ответе, на который вы ссылаетесь, есть замечательные комментарии с более подробным расчётом.
ElxkoT, оох... хочется надеяться, что ты понимаешь разницу в передаче одного 100мб-тного файла и 100 000шт 1кб-тного, а так же способен открыть консоль браузера и посмотреть что передаётся в браузере между ним и серверами спидтеста.
Refguser, многоуважаемый пользователь, консоль браузера - это, конечно крутой хакерско-диагностический инструмент, но я всё же рекомендую внимательно прочитать вопрос автора, потом чуть-чуть почитать про устройство сетей, модель OSI, структуру Ethernet-фрейма и TCP/IP в нём. 95мбит/сек от соточного линка (Ethernet-линка, не тарифа - это не одно и то же!) у вас остаётся ещё до того, как туда будет положен HTTP в виде полезной нагрузки
но я всё же рекомендую внимательно прочитать вопрос автора
Сам не справился?
потом чуть-чуть почитать про устройство сетей, модель OSI, структуру Ethernet-фрейма и TCP/IP в нём. 95мбит/сек от соточного линка (Ethernet-линка, не тарифа - это не одно и то же!) у вас остаётся ещё до того, как туда будет положен HTTP в виде полезной нагрузки
Refguser, я из вежливости и веры в человечество уже раз 10 перечитал вопрос в надежде, что это действительно я что-то не так понял, но нет, результат не меняется. Может быть мне перефразировать для не сетевиков? Ладно.
Почему при установке физического соединения между мной и провайдером в режим FastEthernet (ограниченного ста мегабитами на физическом уровне), я не могу получить сто мегабит в секунду на уровне приложения?
Надеюсь, ответ так же для самых маленьких расписывать не надо? А то это уже просто какой-то троллинг напоминает
Почему данная особенность пропадает при наличии гигового порта со стороны провайдера, линии в 8мь жил и гигового роутера? Чем это вообще обусловлено? И опять же, почему при несоблюдении одного из трёх пунктов, скорость упирается в 95?
Потому что при несоблюдении любого из трёх пунктов скорость линка (НЕ ТАРИФ! ФИЗИЧЕСКИЙ ЛИНК МЕЖДУ РОУТЕРОМ АБОНЕНТА И КОММУТАТОРОМ ПРОВАЙДЕРА) устанавливается в режим FastEthernet и скорость соединения упирается именно в скорость линка, а не в шейпер по тарифу. Дальше смотрим структуру Ethernet-фрейма и всё, что уже было неоднократно описано в этой теме.
ElxkoT, да ты реально упоротый! Пробую последний раз: вопрос ТСа О ПОКАЗАНИЯХ СПИДТЕСТА,
Специально для хакеров-сетиков: это сервис такой. Он проводит "измерения" в браузере. Путём скачивания файлов, внезапно (ах да, ты же консоль браузера не осисил, хакер :) ).
А что ещё при этом происходит в канале и на порту - неведомо (может у него в это время винда обновляется или смартфоны что-то тянут). Как неведомы и настройки шейпера у прова.
Это ВСЁ, что ему нужно занять, умник-грузило, блин.
Refguser, понял. Вы просто игнорируете большую часть вопроса и отвечаете на то, о чем не спрашивали. Да, данные передаются в браузере. Только браузер ничего про инфраструктуру сети абонента не знает и эти свои данные передаёт операционной системе, которая передаёт их в драйвер сетевой карты, который формирует Ethernet-фрейм и выплёвывает его в сетевую карту.
Как работает HTTP, я не знаю, за ненадобностью не разбирался в этом вопросе, но я знаю, что этот протокол работает на уровне абстракции выше, чем Ethernet, IP и TCP, а заголовки этих протоколов есть в КАЖДОМ проходящем от абонента до веб-сервера пакете. Вот прям вообще в каждом. Соответственно и накладные расходы от четырёх уровней уже влияют на эффективную скорость канала ещё до того, как в пакет был заскнут HTTP в качестве полезной нагрузки.
Я как бы понимаю, почему вселенная веб-разработчика заканчивается на HTTP, но чего уж тогда лезть в непрофильный топик и вводить людей в заблуждение? Если хотите разобраться, я выше описал метод, которым вы можете повторить опыт ТС и убедиться во всём наглядно, причём на своем собственном компьютере в максимально контролируемых условиях без лишнего фантомного паразитного трафика - wireshark вам в руки.
потому что у Вас тариф не 100мб\с, а ДО 100мб\с
а вообще - зависит от сервера, кабеля, роутера, пк, загруженности линии провайдера и его шейпера(ограничителя скорости)
в данном случае я бы поставил на то, что у прова просто так настроен шейпер - на 95мб\с
wrstnwrld, 5-8% трафика - служебный. Разбиение на пакеты, синхронизация, пересылка контрольных сумм.
В общем, не будет у вас макс. математически вымеренной скорости, есть определенные издержки на передачу данных, они сильно зависят от технологии каналов связи.
ПС: Вы еще wifi не тестировали на пределах возможности. Там потери x2 от паспортных характеристик - это норма.
alexalexes, не, для служебного это многовато. Я бы таки на физику ставил, но всё-таки нужно знать условия. Если у него неэкранированный кабель с первого этажа идёт на чердак 16-этажки по желобу с электрикой, то и и больше могут быть потери, вкупе со служебным трафиком, конечно. Ну или сегментация лишняя идёт, но это сомнительно.
alexalexes, Можете пожалуйста дать ссылку на какую-нибудь статью, где можно почитать про служебный трафик. Это как раз то, что я искал. На этом тему можно будет закрыть. Всем спасибо за предоставленные ответы!
>где можно почитать про служебный трафик
можно почитать про модель OSI. на каждом переходе от уровня к уровню служебная информация отъедает часть полезной нагрузки
Петровский, wrstnwrld, применительно к этому случаю стандартный ethernet кадр 1518 байт, 8 преамбула, отправное значение 1518+8, минус 14 заголовок, минус 4 crc, получаем mtu 1500 байт, минус ip header - 32 байта, минус tcp header - 20 байт, остальное полезная нагрузка, затраты на https хендшейки незначительны; и если я нигде не ошибся, то получаем.... ммм... ну и получаем те самые 5% от фрейма на служебные данные.
Ziptar, 5% в идеальнейших условиях :)
без распиловки пакетов на более мелкий или зарезки MTU гденить в интернете и т.д. неучтенных расходов может до фига.
ну еще куча камешков будет на пути потока данных...
иэх, помнится игрался с джумбо-фреймами. скорость ускорял - потом забил.
Ziptar, на мой взгляд большая проблема в джумбо-фреймах что 1,5кб мту захаркожено в куче устройств и "умов" :)
а так, средний поток одних только видосиков на население в несколько сот тыщ человек давно уже превышают пресловутые "пару террабайтов" :)
Предыдущий комментатор верно написал - потому что 100М у вас на канальном уровне. Отнимите размер заголовков и прочие накладные расходы и получите 95М. Расширьте канал до 1000М и получите свои 100М полезной загрузки.
Потому что от вас до сервера спидтеста есть ещё 2-20 коммутаторов, на которых настроено 1-5% резервации, чтобы 100мбит траффик не положил порт :)
Это если очень грубо..
Ну и оверхед, как писали выше.
И вообще, провайдер рассчитывает что вы не будете 100% времени выкачивать 100мбит/с. Иначе тарифы были бы как для бизнеса (где такое возможно).
Так что зачем вы упёрлись в эти 3-5мбит на верхушке? Пользуйтесь и радуйтесь жизни. Надо больше - возьмите гигабит. Там будет 950мбит/с :)
Средний
